在许多网站现在接受 OpenID、CardSpace 或联合身份的情况下，外部化身份的价值主张开始增加。但是，许多开发人员尚未采取下一步将授权和使用基于 XACML 的方法外部化。
是意识不强还是其他原因？您希望如何了解基于XACML的软件开发方法？
请注意，我问的是授权，而不是身份验证。
问问题
1185 次
11 回答
15
我认为外部化授权的前景比外部化身份验证（OpenID、CardSpace 等）要困难得多。这主要是因为授权更加特定于应用程序。A 在我的应用程序中被授权执行的操作他可能无法在您的应用程序中执行，甚至假设我的应用程序和您的应用程序之间存在一些共同的并行性，但很可能不会存在。
我不想说永远不会进行外部化授权，但老实说，我很难想出你真正想要这样做的原因。也许对于一组并排工作的应用程序，但同样，这很可能在内部而不是外部得到支持。
于 2009-06-05T11:55:59.977 回答
5
另外，请记住授权！== 身份验证。仅仅因为用户经过身份验证并不意味着您已经解决了站点的授权部分。您仍然需要确定谁可以做什么以及什么时候做。
于 2009-06-05T11:49:59.847 回答
3
我们继续推出自己的产品的主要原因是，像 openid 等这样的选项似乎只得到科技网站的支持。我们是一个较小的参与者，所以在用户接受度更高之前，我们不会开始使用外部提供商。
我们不希望用户在我们网站上做的第一件事就涉及到另一个网站。
于 2009-06-05T11:28:56.177 回答
2
我所做的大多数项目都是在大公司内使用的专有应用程序，在这些情况下，外部身份验证服务很少是一种选择，而是由一些内部服务（例如 Active Directory）处理身份验证。
如果我碰巧成为构建公共网站的项目的一部分，我肯定会尝试使用 OpenID 之类的东西，而不是托管我自己的身份验证。
于 2009-06-05T11:31:17.327 回答
2
我似乎陷入了其他人的误解——问题是关于外部授权。就个人而言，我只信任本地网络上的分布式授权，我可以控制身份验证和授权服务器。我永远不会在网站上使用外部授权。
以下是我对 OpenID 作为身份验证服务的评论。
1）正如所指出的，授权！=身份验证。OpenID 处理身份验证，但 Web 应用程序所有者仍然可以完全控制分配给该登录的权限。这是积极的，但对此的困惑是消极的。
2) 我找不到链接，但 OpenID 对社会工程/中间主要/网络钓鱼攻击开放。提供者试图阻止这种情况（ID 图像、浏览器证书、回调验证等），但当黑帽网站弹出一个对话框/页面显示“输入您的 OpenID 用户名和密码”并且天才用户遵守。
3) 联合 ID 的每个提供者都有能力（有些人会说有责任）跟踪其用户的所有活动，而不管他们使用该 ID 的站点是什么。这就是为什么谷歌和雅虎热衷于提供联合 ID，但对使用它们并不那么兴奋。
4) 与上述评论相反，通常情况下使用 OpenID 会降低注册障碍，尤其是当有用的 UI 指出新用户可能已经拥有 OpenID 时。当您使用组合的 OpenID / OAuth 解决方案（例如 RPX）时，情况更是如此。
所以，在我看来，使用 OpenID 的风险在于用户，而不是网站。我无法通过让用户尝试记住另一个用户 ID 和密码来防止用户被钓鱼。此外，Black Hats 不需要做任何比以纯文本形式存储其站点的用户密码来访问用户的其他帐户更邪恶的事情。有多少人为登录的每个网站使用不同的密码？
于 2009-06-05T12:57:20.383 回答
1
一个问题是此处未发明和对外部化权威（甚至是假名）身份的不信任的某种结合。这里有一篇好文案：
另外，我认为这可能是惯性。如果没有杀手级应用程序来支持它，人们迁移速度很慢。鉴于我最近看到的 Facebook 集成数量的增加，我认为我们正处于陡峭斜坡的顶部，即将进入那个世界。
于 2009-06-05T12:56:09.480 回答
1
正如另一张海报所指出的，授权通常是特定于应用程序的。您可以在一个应用程序中执行的操作与您在另一个应用程序中可以执行的操作有很大不同。尤其是在客户现成的应用程序中，授权通常更自然地由应用程序处理。
性能是另一个问题。这可以通过获取 Sun 的 XACML 实现并使用它来外部化一些授权来看到。您在请求的双方产生的网络成本（取决于您构建请求/响应的方式等）可能远远超过授权决策的实际成本。将其构建到 COTS 应用程序中，您在性能优化方面的自由度较低，情况会变得更糟。
但是，我认为一些有前途的领域是合规性的。有些授权不会因应用程序而异。例如，转让专有或机密信息或材料。在这些情况下，可以为每个应用程序中存在的相同控件建立一个强有力的案例，因为反过来太糟糕了。为相同的访问控制拥有任意数量的实现和规则是一场管理噩梦。开始使用 XACML 等控制框架的一个简单的地方可能是从某人可以看到的内容开始，然后研究出某人可以做的事情。
于 2009-12-20T01:04:54.460 回答
0
我认为这取决于您从事的项目类型。如果客户想要存储授权，则无法使用 OpenID ......我使用谷歌应用程序引擎开发了一个小项目，因此我使用谷歌进行授权。所以它很大程度上取决于项目的类型。
于 2009-06-05T11:27:31.017 回答
0
几个原因：
- 正如一些评论所表明的那样，人们普遍认为“授权是本地的”，这意味着重用重要访问决策所需的昂贵且高质量的“主题属性”几乎没有潜力. （我相信有很高的重用潜力，因为一些法律/法规被广泛适用，但对这种格式的全面讨论太长了。）
- 缺乏数据基础设施：在组织之间应用基于策略的访问控制（我使用/信任其他组织的授权（“AuthZ”）数据来解锁对我的数据的访问）至少需要我理解属性的语义（什么是“执法人员”？什么是“美国公民”。）在这之后，最好有易于理解的属性质量标准和第三方认证。（有些人可能会注意到这些要求类似于 PKI 互操作性的要求：这是怎么回事？这只是针对一个数据，加上支持的东西。）
- 对角色/职责的影响：外部化授权，无论是“角色”、“属性”还是“具有数字策略的属性”，都意味着本地“数据所有者”失去对资源的控制。他还卸下了维护用户列表的大量工作和责任。这种变化将外部 AuthZ 的实施从技术问题提升为带有政治色彩的组织问题。
- 大多数组织不知道也没有写下他们的政策是什么。访问权限可能是“谁提出要求”或“谁提出要求，我喜欢”或“谁可以给我一些东西，比如访问他们的数据”。当通过用策略语言表达它们被迫公开时，应用的真正规则可能会非常难看。而且，将书面政策良好地转化为数字政策的技能也不是在树上生长的。事实上，技能组合是业务分析师或律师，而不是 IT 人员，而且这些人的工具很少甚至不存在。
- 当您确实拥有可靠的策略规则时，您可能会发现处理它所需的属性并不存在——它们通常不是您在 AD 中已经找到的那种东西。电话号码作为 AuthZ 属性没有用，甚至“组织”也可能不适合您实际记录的大多数法律或法规。这甚至没有提到您必须实施（并获得批准）以表达“可能原因”等政策要求的变通办法和近似值。
- 相对容易处理但仍然真实的是，许多非常普遍的 COTS 应用程序不支持外部授权，并且许多应用程序开发人员不习惯进行外部化，因此会 (a) 试图说服你放弃它；或（b）一分钱一分货地学习它，并且做得不好。
听起来很糟糕，对吧？所以，让我最后说我认为尽管这一切，这场比赛还是得不偿失。潜在好处列表将在另一个时间发布。
祝你好运！
于 2014-08-23T00:41:07.020 回答
0
同意 Joseph 关于授权高度特定于应用程序的观点。
但除此之外，外包授权还带来了一个重大风险问题：由于授权是高度特定于应用程序和细粒度的，一旦您将授权外部化到服务提供商，迁移或替换该提供商几乎是不可能完成的任务。你已经无可挽回地陷入困境。
因此，在评估您的风险和收益时，业务推理会驱使您避免使用这种硬依赖。
于 2019-07-02T23:06:46.597 回答
-1
就我个人而言，这是我听说过的关于外部授权的第一件事。所以这可能只是缺乏意识。
现在谷歌搜索..
于 2009-08-05T06:59:52.550 回答