WCF Security之RoleProvider
最近在弄WCF Security(Authentication,Authorization)方面的解决方案,我想把各种验证及授权的解决方案分别写出来,一当做自己学习的总结,另外也与各位童鞋们探讨、分享。今天先看看如何用RoleProvider来实现授权。
RoleProvider,最初目的是用于满足ASP.NET的授权要求,对于一般ASP.NET的应用,如果是Website,那么这个客户端认证信息的类型(ClientCredentialType)是没有(None)的。如果是Web Application,启用Forms authentication,相当于ClientCredentialType=UserName,登陆页面提交到服务端,通过配置的MembershipProvider来做验证,然后通过配置的RoleProvider来做授权。
当然了,RoleProvider也可以用于WCF,只是和Web Application的实现有所不同。WCF使用RoleProvider做服务端授权,客户端认证信息的类型可以是Windows,UserName,甚至是Certificate,只要principalPermissionMode设置为UseAspNetRoles,即保证服务线程的CurrentPrincipal的类型为RoleProviderPrincipal,而Web Application则不需要像WCF一样显示指定(,关于Web Application的验证,不在此文讨论的范围)。
RoleProvider依赖于服务线程的RoleProviderPrincipal,而这个IPrincipal,服务端需要在接收到客户端请求时,根据客户端的认证信息及类型写入的。其大致的流程是这样的:
首先,客户端需要提供用户名和密码,到了服务端,WCF会将RoleProviderPrincipal放到所有服务线程中去(System.Threading.Thread.CurrentPrincipal)。那么在服务端代码中,就可以使用System.Threading.Thread.CurrentPrincipal.IsInRole,PrincipalPermissionAttribute或者PrincipalPermission来判断当前用户是否具有某个角色的权限,从而来决定是否执行下面的程序。在这里,角色是个抽象的概念,你可以认为它是用户组,也可以认为它相当于用户的功能组合,都没关系。此外,你可以使用自带的RoleProvider(AspNetSqlRoleProvider,AspNetWindowsTokenRoleProvider)来实现权限判断,也可以自己实现RoleProvider来实现权限控制。由于权限判断的代码使用了统一的形式(唯一产生耦合的地方就是roleName),因为RoleProvider可以在服务端任意设定,这就意味着,权限控制的数据来源可以是windows用户及组、域用户及组、来自sql server的权限数据,等等。换句话说,实现RBAC的方式可以根据自己的实际需要来做选择,除了在具体的方法里指定角色名之外,权限控制的实现,被放到了RoleProvider中,这样就很容易实现权限系统的切换及变动(代码中与权限相关的代码,即便在权限控制的方式发生改变后,也可以最大程度的保持稳定)。而产生耦合的roleName也可以通过配置的方式来解耦。
在使用RoleProvider时,它支持三种权限控制方式:
1)PrincipalPermissionAttribute - Declarative方式。
只需要在指定的方法上使用该特性,[PrincipalPermission(SecurityAction.Demand, Role = "createSalesOrder")],就可以实现无侵入式的权限控制,这种方式越来越流行,可以基于系统中的任意方法,我想这也是未来系统权限控制的一种不错的选择。
在使用这种方式的时候,需要注意一点,如果一个方法所支持的角色或组有多个,需要分清楚是当前用户需要具有所有的组的权限呢?还是只有拥有任意一个组的权限即可执行该方法。如果是后者,方法上的PrincipalPermissionAttribute支持多个,这些role之间的关系就是OR的关系,而如果是AND的关系,你可以考虑建立嵌套组(nesting group)来处理,或者你是自己实现RoleProvider,可以考虑在IsUserInRole方法的RoleName参数上做些扩展,支持一定的语义支持,例如,[PrincipalPermission(SecurityAction.Demand, Role = "createSalesOrder&&printSalesOrder&auditSalesOrder")]。
2)PrincipalPermission - Assertion方式。
通过在方法的开始处插入如下代码段来控制权限,我称之为断言方式。
IPermission createSalesOrderPerm = new PrincipalPermission(null, "createSalesOrder");
createSalesOrderPerm.Demand();
createSalesOrderPerm.Demand();
3)System.Threading.Thread.CurrentPrincipal.IsInRole - Imperative方式。
这种方式叫做祈使方式,就是根据是否拥有权限来写相应的操作控制。
这三种方式可有优缺点及使用场景,我比较倾向于Declarative方式,因为这样对代码的侵入性要小,而且方式比较干净。
下面提供一个示例,加以说明。
在服务端的配置中,只要做如下配置:
<serviceAuthorization principalPermissionMode="UseAspNetRoles" roleProviderName="MyProvider" />
这就表明服务端将采用RoleProvider的方式进行授权检查。
由于授权依赖于客户端传入用户名及密码,所以,ClientCredentialType可以选择Windows和UserName两种方式,其中,UserName可以支持其他的数据格式,例如你们产品的权限验证不仅仅依赖于用户名和密码,还有公司名,那么你可以把公司名和用户名都放在UserName中,在服务端再做拆解。而且UserName还支持MembershipProvider方式的验证以及其他自定义方式的验证,因此,在这里你可以选择UserName的方式。由于UserName的方式依赖于安全的消息传输,所以安全模式可以选择TransportWithMessageCredential。
这种方式的配置分别如下:
Binding:
<binding name="wsHttp1"> <security mode="TransportWithMessageCredential"> <transport clientCredentialType="None" realm="" /> <message clientCredentialType="UserName" /> </security> </binding>
Service behavior:
<behavior name="securityBehavior"> <serviceCredentials> <userNameAuthentication userNamePasswordValidationMode="MembershipProvider" membershipProviderName="MyMembershipProvider"/> </serviceCredentials> <serviceAuthorization principalPermissionMode="UseAspNetRoles" roleProviderName="MyProvider" /> </behavior>
(验证部分可以忽略)
Service:
<service name="TestService5.TestService" behaviorConfiguration="securityBehavior"> <endpoint address="" binding="wsHttpBinding" bindingConfiguration ="wsHttp1" contract ="TestBase.ITestService2" name ="testService5" /> <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" /> </service>
接下来在服务的接口方法中,直接通过获取当前线程的RoleProviderPrincipal,来判断其是否拥有某角色权限,来确定当前用户是否具有当前方法的操作权限:
bool canReadData = System.Threading.Thread.CurrentPrincipal.IsInRole("createSalesOrder"); // CurrentPrincipal is RoleProviderPrincipal.
如上面所言,推荐使用下面这种方式:
[OperationContract] [PrincipalPermission(SecurityAction.Demand, Role = "createSalesOrder")] int CreateSalesOrder(ISalesOrder order);
这种方式就不推荐了:
IPermission createSalesOrderPerm= new PrincipalPermission(null, "createSalesOrder"); createSalesOrderPerm.Demand();
此外,我在上面的例子中使用的是MyRoleProvider,这个类继承自RoleProvider,只重写了我需要用到的几个方法:
namespace TestBase { public class MyRoleProvider : RoleProvider { public override string[] GetAllRoles() { //get all groups return CapabilityLoader.GetCapabilities(); } public override string[] GetRolesForUser(string username) { //get all groups for a user string companyName; string userName; string[] items = username.Split('~'); companyName = items[1]; userName = items[0]; return ADCapabilities.GetUserCapabilities(companyName, userName).EnabledCapabilityList; } public override bool IsUserInRole(string username, string roleName) { //check if a user is in the group string companyName; string userName; string[] items = username.Split('~'); companyName = items[1]; userName = items[0]; return ADCapabilities.IsUserInAllGroups(companyName, userName, new string[] { roleName }); } } }
一般在ASP.NET的安全方案中,RoleProvider和MembershipProvider成对出现,而在我的WCF安全方案中,验证部分同样使用自定义MembershipProvider,下篇文章介绍MembershipProvider。
(部分文字根据Artech的指正做了修改)
作者: Bright Zhang 发表于 2011-05-25 03:14 原文链接
推荐.NET配套的通用数据层ORM框架:CYQ.Data 通用数据层框架
发表评论
迅速な対応して頂ける良いお店です。
又、機会があれば利用させて頂きます。
ありがとうございました。
★ルイヴィトン★モノグラム★パピヨン30(大)★ハンドバッグ★ポーチ付★M51365★旧型タイプ★
ありがとうございました。
商品届きました、とても迅速な対応ありがとうございました。
思った通りのカバンで嬉しい限りです。
又、購入の際は、宜しくお願い致します。