使用ADFS和WIF基于角色的权限的存储 [英] Storage of Role-based Permissions using ADFS and WIF

查看:259
本文介绍了使用ADFS和WIF基于角色的权限的存储的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在其使用用户信息的Active Directory中的项目,ADFS验证和SSO和几个自定义应用程序的所有内置的ASP.NET MVC。

I'm working on a project which uses Active Directory for user information, ADFS for Authentication and SSO, and several custom applications all built with ASP.NET MVC.

授权模式是索赔和基于角色的;也就是说,用户的角色是作为债权的相关应用程序访问,通过由ADFS(使用WIF)。

The authorization model is claims and role-based; that is, a user's roles are accessible as claims to the relevant application, via tokens issued by ADFS (using WIF).

每个角色都有一个定义对应用程序的各种资源的权限列表(即管理员角色具有抗资源X写权限)。我们有基本的授权模型有一些硬codeD权限,运作良好。

Each role has a defined list of permissions against the applications' various resources (i.e. the role Admin has WRITE permission against resource X). We have the basic authorization model working well with some hardcoded permissions.

我的问题是:什么是最好的方法/地方来存储各种角色的实际权限?可以这样ADFS内完成,或将需要一个单独的存储(我猜是后者)?权限遵循同样的模式作为XACML(用户/角色:资源:行动)和XACML的解决方案可能会是很容易合并,但XACML(XACML.NET)最流行的.NET实现似乎使用XML作为唯一这不会是可行的存储机制(我们有很多的资源来存储权限反对 - 可能数以千计)

My question is: what is the best way / place to store the actual permissions for the various roles? Can this be done within ADFS or will a separate store be needed (I'm guessing the latter)? The permissions follow the same broad pattern as XACML (user/role:resource:action) and a XACML solution would probably be easy to incorporate, but the most popular .NET implementation of XACML (XACML.NET) seems to use XML as the only storage mechanism which isn't going to be viable (we have a lot of resources to store permissions against - potentially thousands).

什么人使用呢?最明显的解决方案似乎是只存储在SQL Server,但考虑到所有用于身份验证的准备构建的解决方案(特别是在使用ADFS和WIF)三胞胎这似乎有点奇怪,有一个为实际执行授权和权限,使小(明显)的信息。我在网上找到的所有例子停在很短的权限级别解释的事情。

What do people use for this? The most obvious solution seems to be to just store the triplets in SQL Server but considering all the ready-built solutions for authentication (especially using ADFS and WIF) it seems odd that there's so little (obvious) information for actually implementing authorization and permissions. All the examples I've found online stop short of explaining things at the permissions level.

推荐答案

ADFS经常是一个共享的基础架构组件。与移动应用的具体知识,它(如应用程序特定的权限)的问题是,可能随着时间的推移管理员瓶颈。问问你自己:谁去随着时间的推移管理这些权限?将你的提交人批准一种形式?这很可能是一个问题。它会工作,但它会是一个麻烦。

ADFS is frequently a shared infrastructure component. The problem with moving app specific knowledge to it (like app specific permissions) is that in could become an admin bottleneck over time. Ask yourself: who is going to to manage those permissions over time? will you have to submit a form for somebody to approve? That is likely to be a problem. It would work, but it will be a hassle.

在一般情况下,ADFS应该提供跨应用的属性,每个人都可以从中受益(例如,所有基于AD属性,企业范围的属性,人力资源相关的信息,都是很好的例子)。

In general, ADFS should supply cross app attributes that everybody can benefit from (e.g. all AD based attributes, corporate wide attributes, HR related information, are good examples).

当然你可以有ADFS从在一个分布式的方式管理的数据库中提取数据。

Of course you could have ADFS pull data from a database that is managed in a distributed way.

在某些情况下,人们部署应用程序的特定STS(通常称为RP-STS)的转换令牌到的东西应用程序(或应用程序组)的期望。的SharePoint做这行的例子。

In some cases, people deploy an app specific STS (often called an "RP-STS") that transforms the token into something the app (or group of app) expects. SharePoint does this for example.

这篇关于使用ADFS和WIF基于角色的权限的存储的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆