很抱歉问了这么长的问题,试图把我所有的观点都讲清楚!
我花了相当多的时间研究如何将我们现有的身份和访问管理方案更新为更现代的平台,以解决我们的许多业务和合规性要求,特别是从ISO27001的角度。
我有两个主要目标要实现: 1)能够报告用户可以执行哪些业务操作/任务? 2)能够实时或通过历史报告监视用户正在做什么/已经做了什么?
我们目前混合使用自定义身份验证和授权(使用SQL后端进行两者)和AD域服务来进行身份验证和AD组成员身份/角色要求的授权。
我建议我们在所有软件中使用AD域服务进行身份验证,但从基于声明的角度来看,使用ADFS 2.0作为我们的STS服务器。然后,我们可以开始在我们的应用程序中利用声明,对于那些使用角色需求的人,它们仍然会继续工作。
我对上面的所有内容都很满意,但是我们希望使用更细粒度的授权管理/授权方案,因此我希望使用ClaimsAuthorizationManager作为决策和执行点。
问题是WIF没有实现一个具体的版本,开发人员完全由他们自己选择,没有任何指导。我找不到任何接近适合业务的东西的例子。
因此,我正在寻求关于如何构建一个工作方式类似于AzMan或NetSqlAzMan的企业级授权方案的建议。我建议每个应用程序都可以使用一个通用的简单ClaimsAuthorizationManager类。这个类调用一个共享的WCF服务,该服务使用一个SQL后端来存储业务操作/任务以及用户对这些操作/任务的授权。用户对象将从AD同步,以便AD提供身份验证和声明,而我的自定义系统提供授权规则。这种服务的集中化和单一性有助于实现我的第一个目标。
这个系统将记录每个请求,这将有助于我的第二个初始目标。
任何建议,例子或帮助非常感谢。
发布于 2013-02-08 19:20:37
你是对的-因为AuthZ是如此特定于应用程序-微软没有提供任何具体的实现。
你似乎已经有了非常具体的想法,应该如何工作。为什么你不构建一个这样的样本并将其开源-这样你就可以收集反馈并在此基础上进行改进呢?
发布于 2013-02-12 04:57:02
一些想法。
角色是一种很好理解的模式,例如Universal Data Models。
ADFS可以将组作为roles - ADFS : Sending groups as claims传递。然后,您可以使用IsInRole或位置标记。这对你来说可能过于简单化了?
ADFS可以记录成功或失败的审核-“联合服务属性”-事件。
https://stackoverflow.com/questions/14770446
复制相似问题