ASP.NET会员和基于角色的安全

我发展与ASP.NET & C#一个博客引擎。主要解决方案包括几个项目的下面所列ASP.NET会员和基于角色的安全

DomainModel：域实体和接口库
AppService：应用服务，视图模型映射器，消息等
Repositories：EF库，XML库，存根库
Presentation：实现MVP模式（视图，主持人，接口）

现在，用户端项目是一个WebForms Web应用程序，并且该项目即将完成。最后一件事是整个系统与ASP.NET Membership。有两件事情需要考虑。

首先，只有一个用户帐户ID从在博客数据库中的成员数据库所需。最后，基于角色的安全性必须在UI项目中实施。因为即时通讯还挺新的分布式应用程序的开发，DDD之类的东西，我想知道如果基于角色的安全性的实现是UI的应用程序仅仅只是责任，或有在其他层以照顾其他的事情解决方案。据我所知，只有视图（网页）必须实现基于角色的安全性并呈现不同的内容，并根据当前会话提供不同的功能。但是，这一切？

我知道这可能是一个通用的问题，会有所不同根据项目需求的过程中，实现和设计。但是如果在分布式/分层应用程序中实现基于角色的安全性和表单身份验证时遵循一般的经验规则，那么事先了解它们将非常棒。例如：

安全性实现仅仅是UI应用程序的责任。
我可以调整/更改我的域模型和/或其他图层的设计，以便基于角色的安全性的实现更容易，而不会完全落在UI应用程序上。
是否采取安全考虑其他层，从而使UI层将数据只是一种表象，并在用户和系统之间的媒介是一个好主意。

这三个问题似乎是相同的（杜）。

如果这是一个重复或偏离主题的问题，那么生病会被链接，引用和评论帮助。但如果没有，我想这是一个彻底的话题。 TNX

来源

2011-08-25 Nexus

安全应该是所有应用程序的责任。这真的取决于您的应用程序的结构。

我认为所有层级都应该有一些参与。安全应该是其他服务可以使用的另一种服务。这样你就可以在各个级别访问安全模型。如果用户未被授权，管理用户界面可以立即阻止用户，但可以说数据检索服务可以检查它检索的对象对当前用户有效。

如果您想以其他方式使用您的数据模型，例如通过Web服务或其他应用程序（例如Silverlight），您也可以获得优势。

更新

所有层级真的需要知道安全的，因为所有层需要在某一时刻去触摸它。用户界面需要它，因此它可以切换UI元素的开启和关闭。服务需要注意它，以确保它们正在执行的操作对当前用户有效等等。

安全真的不应该是你想到的项目结束&只是打开。它应该是各级应用程序设计的东西。

你如何实现它取决于你如何编写你的应用程序。我会说最好的方法是在你的应用程序的asp成员资格之间建立一个抽象层。您可以获得所有您已知的好处，例如测试，重新设计等。

您可能想要考虑的一件事是权限或权限的概念。 ASP没有处理这个问题的本地库，所以你不得不推出自己的。任何时候你想做点什么，都要检查用户是否有权利。这些权限可以分配给角色，而角色又可以分配给用户或用户组。您可以对用户可以执行的操作进行细化控制，这使得将来可以轻松添加新角色。

来源

2011-08-25 14:27:44

只是为了确保我明白这个权利，如果安全可以另一个服务，那么只有我的'AppService'层需要引用和使用这个服务层，对吧？还可以提供样本/链接或者多谈一些关于如何编写这样的安全服务以便其他层可以使用它的内容。最后，如果安全性要在另一个服务层实现，那么MVP模式和我的Web表单应该如何与此服务层集成？ – Nexus

安全是一个贯穿始终的问题：涉及到UI，应用程序和领域层。我的理解是，你处理像“只有作者可以编辑博客”或“只有注册用户可以评论”的规则。在这种情况下，用户界面应该了解这些规则，以决定是渲染“编辑”还是“评论”链接。域对象应该能够执行这些规则。

据我所知，ASP.NET Membership做了很多事情，包括用户存储，认证，授权和角色管理。但它不知道你的域名。它不知道博客是什么。它知道ASP页面是什么。因此，如果您不想将域规则表达为页面访问规则，则可能需要在应用程序和ASP.NET成员资格之间划一条粗线。您可能希望将用户存储和身份验证委派给ASP.NET，但您自己完成其他任务。在您的域模块中不要直接依赖ASP.NET也可能是一个好主意。如果您稍后决定从Web窗体切换到MVC，或者您的博客引擎将具有Web API，则还需要考虑ASP.NET Membership如何工作。

来源

2011-08-25 15:23:51 Dmitry

不确定你到底在干什么，但值得注意的是，标准PrincipalPermissionAttribute Class可以很好地适用于使用此提供者技术实现的ASP.NET角色。

这意味着您可以使用代码访问安全性和声明性属性来确保您的API /域/方法只能由特定角色的用户访问。所以是的，你可以使用ASP.NET Membership强制UI层以外的安全性。

来源

2011-08-25 16:28:17

在UI应用程序中实现安全性会不会更容易，所以未经授权的调用将无法达到其他层？我的理解是，它应该更容易这样，但如果这种类型的安全可以在UI应用程序被覆盖然后是，其他层就必须了解一些安全规则以及 – Nexus

@Nexus [？] - 其实，你可以做两个。您可以在您的域/业务层添加属性，也可以在UI层中使用它。这取决于您需要的安全级别。在“容易”这个词通常不适合以“更安全” :-) –

这样的'域对象和其他层的方法代码访问安全attributes'组合，并呈现在用户界面层不同的内容，将工作的能力精细。顺便说一句西蒙，是否是一个好主意，检查当前会话是否在每个方法/服务的“AppService”层中是“authenticated/authorized”？这可以在另一个服务层的帮助下完成。毕竟，AppService层是整个系统的入口点，用户只会与这个层进行交互。 – Nexus

解决这个问题一段时间后，我得出了下面的结论。

执行安全性如Authentication,Role-based security,Authorization等在用户体验层不是主要有两个原因一个好主意：

如果你想为你的应用程序创建其他UI，说WinForms或Silverlight UI，那么你就要有落实这种安全从头开始。
您可以随时使用系统的其他组件/图层而无需创建UI应用程序。假设您创建了一个引用系统中其他图层的简单控制台应用程序（即Repositories）。那么你可以实例化一个存储库并处理数据。在这种情况下，您已成功覆盖任何安全性。

因此，解决方案是在另一个嵌入域模型本身的层中实现这种有点安全性，而不是绑定到用户体验层（UI）。

现在有一些变化，你可能会如何去做这件事。假设我们有一个名为AppService的层，它是整个系统的入口点。该层由消息（消息模式如Request-Response模式），ViewModels组成，这些消息是域实体的扁平视图，以及Methods for retrieving and manipulating data等。在此，我们可以在PrincipalPermission对象的帮助下实施此类安全措施。我们可以将安全规则应用于类和方法。这里有一个简单的例子：

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)] 
public void DoSomething() 
{ }

随着对这种方法定义的属性，代码要求要认证的呼叫者。认证模型可以是任何东西，包括Windows Authentication,Forms Authentication等等。现在这个工作正常，因为现在我们已经从服务层中定义的安全规则松散地耦合了UI。但是仍然有一个问题。

只要服务层确实是主入口点到系统，此设计将工作正常。这意味着如果您仍然可以实例化一个存储库，例如而不需要需要获取AppService的实例，那么您仍可以覆盖安全规则。即要么你必须以这种方式设计你的领域模型，与你的系统的组件/层一起工作将需要一个AppService的实例。在这种情况下，系统中提供的任何功能只能通过应用程序服务层访问。另一方面，如果这是不可能的，或者目前没有担心，那么您还必须在其他层中定义安全规则。这意味着你将不得不在存储库中定义安全规则。因此如果有人实例化存储库并试图操纵数据，而不通过UI或AppService层执行他的命令，则仍然执行安全措施。

另一件事是在您的类和方法上使用PrincipalPermission规则不会绑定到特定的认证/授权模型。所以你可以在带有Forms Authentication的web应用程序中使用这样的安全规则，或者使用带有Windows/AcctiveDirectory Authentication等的windows应用程序。

正如你还记得我正在开发一个简单的博客引擎ASP.NET和这个模型工作正常。如果有更详细的深入优点和缺点，或样本和博客文章，可以帮助这个主题，请务必发表您的意见和答案[：

来源

2011-09-02 15:30:00 Nexus

ASP.NET会员和基于角色的安全

回答

相关问题