我的任务是为现有/传统的wcf服务提供授权策略。目前系统中没有授权。基于Basichttp的自定义绑定正用于处理安全性。 (客户端以加密形式发送username / pwd,在服务器端,在接收请求时执行数据库检查。此时,生成一个可过期的令牌并将其放入服务器内存以进行进一步的安全检查)故事的道德,一切以自定义方式实现(不使用框架的安全功能,如STS,证书等)在服务层中,不根据客户端身份进行身份验证检查。从理论上讲,只要他/她拥有有效的用户名/密码对,每个客户都可以执行每项操作。
正如我所说,我的任务是在这个遗留系统上实施授权策略。
我对wcf相对较新,我的感觉是认证和授权在wcf中非常紧密地联系在一起。
似乎有各种替代方案(http://msdn.microsoft.com/en-us/library/ff648151.aspx),如:
*使用ASP.NET角色管理器进行角色授权,
*使用SQL Server角色提供程序进行角色授权, 等等。
我觉得自定义授权政策对我来说是最合适的选择,但是自定义样本 http://msdn.microsoft.com/en-us/library/ms731774(v=vs.110).aspx似乎也将身份验证策略与授权策略混合在一起。在没有任何特殊身份验证策略的情况下,我找不到实现自定义授权的正常工作示例。正如您所猜测的那样,在当前的遗留系统中,安全性是以自定义方式处理的,我无法改变它,即我不能使用任何ws- *绑定。
我认为可能的解决方案是:
1)创建一个实现ParameterInspector或MessageInspector
的自定义属性2)使用这个新的自定义属性
装饰所有现有的操作合同3)在BeforeCall或AfterReceiveRequest方法中,应用自定义身份验证逻辑(此自定义逻辑很可能是具有允许操作的角色和角色的关联用户)。
拒绝请求将是抛出异常并在客户端正确显示消息。
我的问题是,这种方法有多优雅?考虑到遗留系统的其他限制是否有更优雅的替代方案?我是否遗漏了一些部分,或者认证和授权是否真的非常紧密地耦合在wcf中?
答案 0 :(得分:2)
在过去,基本上你可以使用声明性编程来使用带有角色名的PrincipalPermissionAttribute来装饰每个操作实现,然后在Web.config中插入ASP.NET MembershipProvider和RoleProvider等。如果你想要更精细的策略控制,您可以编写一些IAuthorizationPolicy实现,因为您已经在问题的MSDN引用中找到了它们。
因此,即使您的目标设计可能有效,您也会期待更多优雅的替代品。优雅:
这篇文章" Authentication and Authorization with ASP.NET Identity 2.0 for WCF Services"可能会给你一些启发。
有很多关于使用Identity 2.0的原因的文章。
答案 1 :(得分:1)
我会完全使用外部授权框架,然后应用MessageInspector。外化授权架构如下:
外化授权管理是将业务逻辑与授权逻辑分离。在高效构建新应用程序时非常棒,在更新旧版应用程序时非常棒 - 尤其是可以轻松拦截流量的Web服务。看看Gartner's report on externalized authorization。
对于您的问题,我建议您使用可扩展访问控制标记语言XACML。它是OASIS标准,为您提供:
这是一个勾勒出您想要系统的方式的图表:
如果您需要.NET PDP,可以从Axiomatics获取一个(免责声明:这是我工作的公司)。
HTH