ASP.NET 会员资格和基于角色的安全性
我正在使用 ASP.NET & 开发一个博客引擎。 C#。主要解决方案由下面列出的几个项目组成
DomainModel：存储库的域实体和接口AppService：应用程序服务、视图模型映射器、消息等。Repositories< /code> : EF Repository, XML Repository, Stub RepositoryPresentation: 实现 MVP 模式（视图、演示者、接口）
用户端项目是一个WebForms Web 应用程序目前为止，该项目即将完成。最后一件事是将整个系统与ASP.NET Membership集成。有两件事需要考虑。
首先，只需要博客数据库中的会员数据库中的用户帐户ID。 最后，基于角色的安全性必须在 UI 项目中实现。因为我对分布式应用程序开发、DDD 等东西相当陌生，所以我想知道基于角色的安全性的实现是否仅仅只是 UI 应用程序的责任，或者还有其他事情需要在其他方面处理溶液层。据我目前所知，只有视图（网页）必须实现基于角色的安全性并根据当前会话呈现不同的内容并提供不同的功能。但这就是全部吗？
我知道这可能是一个普遍问题，当然，实施和设计会根据项目需求而有所不同。但是，如果在分布式/分层应用程序中实现基于角色的安全性和表单身份验证时需要遵循一般经验规则，那么事先了解它们会很棒。例如：
- 安全实施只是 UI 应用程序的责任吗？
- 我可以调整/更改我的域模型和/或其他层的设计，以便基于角色的安全性的实现会更容易，而不是完全落在 UI 应用程序上。
- 在其他层考虑安全性是不是一个好主意，这样 UI 层就只是数据的表示以及用户和系统之间的媒介。
I'm developing a blogging engine with ASP.NET & C#. the main solution consists of several projects as listed below
DomainModel: domain entities and interfaces for repositoriesAppService: application services, view model mappers, messages, etc.Repositories: EF Repository, XML Repository, Stub RepositoryPresentation: implements the MVP pattern (views, presenters, interfaces)
The user-end project is a WebForms web application for now, and the project is almost finished. the final thing is to integrate the whole system with ASP.NET Membership. there are two things to consider.
First off, only a user account ID is needed from the membership database in the blog database.
And finally the role-based security has to be implemented in the UI project. since I'm fairly new to distributed application development, DDD and stuff, i wanted to know if the implementation of role-based security is merely just the responsibility of the UI app, or there are other things to be taken care of in the other layers of the solution. as far as i know for now, only the views (web pages) have to implement role-based security and render different content and offer different functionality based on the current session. but is that all?
I know this might be a generic question, of course the implementation and design would vary based on project needs. but if there are general rules of thumb to follow when implementing role-based security and forms authentication in a distributed/layered application it would be great to know them before hand. for example:
- Is security implementation just a responsibility of the UI app?
- Can I tweak/change the design of my domain model and/or other layers, so that the implementation of role-based security would be easier, and not fall on the UI app entirely.
- Is it a good idea to take security into account in other layers, so that the UI layer would be just a representation of data and a medium between the user and the system.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
安全性是一个跨领域的问题：涉及 UI、应用程序和域层。我的理解是，您处理诸如“只有作者可以编辑博客”或“只有注册用户可以发表评论”之类的规则。在这种情况下，UI 应该了解这些规则来决定是否呈现“编辑”或“评论”链接。域对象应该能够强制执行这些规则。
据我所知，ASP.NET Membership 做了很多事情，包括用户存储、身份验证、授权和角色管理。但是它不知道您的域。它不知道博客是什么。它知道 ASP 页是什么。因此，如果您不想将域规则表示为页面访问规则，您可能需要在应用程序和 ASP.NET 成员资格之间划一条粗线。您可能希望将用户存储和身份验证委托给 ASP.NET，但您自己完成其余的工作。在域模块中不要直接依赖 ASP.NET 也可能是个好主意。您还需要考虑如果您以后决定从 Web 窗体切换到 MVC 或者您的博客引擎将使用 Web API，则 ASP.NET 成员资格将如何工作。
Security is a cross-cutting concern: UI, application and domain layers are involved. My understanding is that you deal with rules like "Only Author can edit Blog" or "Only registered Users can comment". In this case UI should be aware of these rules to decide whether to render 'Edit' or 'Comment' links. Domain objects should be able to enforce these rules.
As far as I know ASP.NET Membership does a lot of things including user storage, authentication, authorization and roles management. However it is not aware of your domain. It does not know what Blog is. It knows what ASP Page is. So if you don't want to express your domain rules as page access rules you may want to draw a thick line between your app and ASP.NET Membership. You may want to delegate user storage and authentication to ASP.NET but do the rest yourself. It may also be a good idea to not have direct dependency on ASP.NET in your domain module. You also want to consider how ASP.NET Membership will work if you later decide to switch from Web Forms to MVC or if you will have a web API for your blogging engine.
不确定您到底想要什么，但值得注意的是标准 PrincipalPermissionAttribute Class 与使用此提供程序技术实现的 ASP.NET 角色配合得很好。
这意味着您可以使用代码访问安全性和声明性属性来确保您的 API/域/方法只能由特定角色的用户访问。所以，是的，您可以使用 ASP.NET 成员资格在 UI 层之外强制实施安全性。
Not sure what your exactly after, but it's worth to note the standard PrincipalPermissionAttribute Class works fine with ASP.NET roles implemented with this provider technology.
It means you can use Code Access Security, and declarative attributes to ensure your API/Domain/Methods can only be access by users in a specific role. So yes, you can enforce security beyond UI layers using ASP.NET Membership.
安全性应该是所有应用程序的责任。这实际上取决于您的应用程序的结构。
我的观点是，所有层级都应该有所参与。安全性应该是其他服务可以使用的另一项服务。这样您就可以访问各个级别的安全模型。如果未经授权，管理 UI 可以立即阻止用户，但数据检索服务可以检查其检索的对象对当前用户是否有效。
如果您想以其他方式（例如通过 Web 服务或其他应用程序（例如 Silverlight）使用数据模型），您也可以通过这种方式获得好处。
更新
所有层确实需要注意安全性，因为所有层都需要在某个时刻接触它。 UI 需要它才能打开和关闭 UI 元素。服务需要意识到这一点，以确保它们正在执行的操作对当前用户和用户有效。很快。
安全确实不应该是您在项目结束时才考虑的事情。只需打开即可。它应该被设计到各个级别的应用程序中。
如何实现它取决于您如何编写应用程序。我想说最好的方法是在你的应用程序和应用程序之间有一个抽象层。 ASP 会员资格。您可以获得您已经知道的所有好处，例如测试、重新架构等。
您可能需要考虑的事情之一是权利或权限的概念。 ASP 没有用于处理此问题的本机库，因此您必须推出自己的库。每当你想做某事时，你都会检查用户是否有权利。这些权限可以分为角色，而角色又可以分配给用户或用户组。您可以对用户可以执行的操作进行精细控制。它使得将来添加新角色变得容易。
Security should be the responsibility of all of the app. It really depends on how your app is structured.
My view is that all tiers should have some involvement. Security should be another service, that the other services can use. That way you can access the security model at all levels. The admin UI can block the user immediately if they're not authorised, but say the data retrieval service can check the objects it's retrieving are valid for the current user.
You also get benefits this way if you want to use your data model in other ways, say via web services or from some other app, eg Silverlight.
Update
All tiers really need to be aware of security, as all tiers need to touch it at some point. The UI needs it so it can switch UI elements on and off. Services need to be aware of it to ensure they actions they are executing are valid for the current user & so on.
Security really shouldn't be something you think of at the end of the project & just switch on. it should be something designed into the application at all levels.
How you implement it will depend on how you've written your application. I would say the best way is to have an abstraction layer between your app & asp membership. You get all the benefits you already know, eg testing, re-architecting, etc
One of the thing you might want to think about is the concept of rights or permissions. ASP has no native libraries for dealing with this, so you'd have to roll your own. Anytime you want to do something, you check the user has the right. These rights can be rolled into roles which in turn can be assigned users or groups of users. You get fine-grained control over what users can do & it makes it easy to add new roles in the future.
在解决这个问题一段时间后，我得出了以下结论。
在用户体验层中实现
身份验证、基于角色的安全、授权等安全性并不是一个好主意主要有两个原因：WinForms或SilverlightUI，那么您必须全部实现此安全性重新从头开始。因此，解决方案是在嵌入域模型本身且不依赖于用户体验层 (UI) 的另一层中实现这种安全性。
现在，您可以采取一些不同的方式来解决此问题。假设我们有一个名为 AppService 的层，它是整个系统的入口点。该层由消息（类似于请求-响应模式的消息传递模式）、域实体的扁平化视图视图模型以及用于检索和操作数据的方法组成 等。这里我们可以借助
PrincipalPermission对象来实现此类安全措施。我们可以将安全规则应用于类和方法。这是一个简单的示例：通过为此方法定义的属性，代码要求调用者进行身份验证。身份验证模型可以是任何形式，包括 Windows 身份验证、表单身份验证等。现在效果很好，因为现在我们已经将 UI 与服务层中定义的安全规则松散耦合了。但仍然有一个问题。
只要服务层确实是系统的主要入口点，这种设计就会很好地工作。这意味着，如果您仍然可以实例化（例如存储库），而无需获取 AppService 的实例，您仍然可以覆盖安全规则。话虽这么说，要么您必须以这样的方式设计域模型，即使用系统的组件/层需要 AppService 的实例。
在这种情况下，系统中提供的任何功能都只能通过应用服务层访问。另一方面，如果这是不可能的，或者目前不关心，那么您还必须在其他层中定义安全规则。这意味着您还必须在存储库中定义安全规则。因此，如果有人实例化存储库并尝试操作数据，而不通过
UI或AppService层执行他的命令，您仍然会强制执行安全措施。另一件事是，在类和方法上使用
PrincipalPermission规则并不依赖于特定的身份验证/授权模型。因此您可以在具有Forms Authentication的 Web 应用程序中使用此类安全规则，或者在具有Windows/AcctiveDirectory Authentication的 Windows 应用程序中使用此类安全规则。您还记得我正在
ASP.NET中开发一个简单的博客引擎，并且该模型目前运行良好。如果有更详细、深入的优点和缺点，或者可以在本主题中提供帮助的示例和博客文章，请务必发布您的评论和答案 [：After working around this problem for a while I've come to this conclusion that follows.
Implementing security like
Authentication,Role-based security,Authorizationetc. in the User-experience Layer is not a good idea mainly for two reasons:WinFormsorSilverlightUI, then you're gonna have to implement this security all over again from scratch.Repositories). then you can instantiate a repository and manipulate data. in which case you've successfully overridden any security.So the solution is to implement this kind of security in another layer that is embedded in the domain-model itself and is not tied to the user experience layer (UI).
Now there are some variations on how you might go about this. let's say we have a layer called
AppServicewhich is the entry point to the whole system. this layer consists of messages (a messaging pattern like theRequest-Responsepattern),ViewModelswhich are flattened-views of domain entities andMethods for retrieving and manipulating dataetc. here we can implement such security measures with the help ofPrincipalPermissionobjects. we can apply security rules to classes and methods. here's a simple example:With the attribute defined for this method, the code demands the caller to be authenticated. the authentication model can be anything including
Windows Authentication,Forms Authenticationand so on. now this works fine, because now we have loosely coupled the UI from the security rules defined in the service layer. however there's still a catch.This design will work fine, as far as the service layer is truly the main entry point to the system. meaning that if you still can instantiate, say a repository, without the need to obtain an instance of your AppService, you can still override the security rules. that being said either you have to design your domain model in such a way, that working with components/layers of your system would need an instance of the AppService.
In which case, any function provided in the system is only accessible through the application service layer. on the other hand, if this is not possible, or not of concern at the moment, you're gonna have to define your security rules in other layers as well. meaning that you would have to define the security rules in your repositories too. so that if someone instantiates a repository and tries to manipulate data, without executing his commands through the
UIor theAppServicelayer, you still enforce security measures.Another things is that using
PrincipalPermissionrules on your classes and methods is not tied to a specific authentication/authorization model. so you can use such security rules in web applications withForms Authentication, or windows applications withWindows/AcctiveDirectory Authenticationand so on.As you recall I'm developing a simple blogging engine in
ASP.NETand this model is working fine for the moment. If there are more detailed in-depth pros and cons, or samples and blog posts that can help in this topic please make sure to post your comments and answers [: