软件开发人员没有外部授权的原因吗？

Question

外部化身份的价值主张开始增加，许多网站现在接受OpenID，CardSpace或联合身份。但是，许多开发人员尚未采取下一步措施来外部化基于XACML的授权和使用方法。

缺乏意识或其他原因的原因是什么？您希望如何了解基于XACML的软件开发方法？

请注意，我询问的是授权，而不是身份验证。

Answer 1

我认为外化授权的前景比外化认证（OpenID，CardSpace等）要困难得多。这主要是因为授权更具针对性。在我的申请中，A人​​有权做什么，他可能无法在你的申请中做，甚至假设我的申请和你的申请之间有一些共同的平行，这很可能不存在。

我不想说外部授权将永远不会完成，但老实说，我很难想出你真正想要这样做的原因。也许对于一系列并排工作的应用程序而言，这很可能是内部支持，而不是外部支持。

Answer 2

另外，请记住授权！==身份验证。仅仅因为用户通过身份验证并不意味着您已经解决了站点的授权部分。您仍然需要确定谁可以做什么以及何时做。

Answer 3

我们继续推出自己的主要原因是像openid et al这样的选项似乎只是技术网站支持。我们是一个较小的玩家，因此我们不会开始使用外部提供商，直到用户接受度更高。

我们不希望用户在我们的网站上做的第一件事就是涉及到另一个网站。

Answer 4

我所做的大多数项目都是在大公司中使用的专有应用程序，在这种情况下，外部身份验证服务很少是一种选择，但身份验证由某些内部服务（如Active Directory）处理。

如果我碰巧成为构建公共网站的项目的一部分，我肯定会尝试使用像OpenID这样的东西，而不是托管我自己的身份验证。

Answer 5

我似乎陷入了其他人的误解 - 问题是关于外部授权。就个人而言，我只信任本地网络上的分布式授权，我可以控制身份验证和授权服务器。我永远不会在网站上使用外部授权。

以下是我对OpenID作为身份验证服务的评论。

1）正如所指出的，授权！=认证。 OpenID处理身份验证，但Web应用程序所有者仍可完全控制分配给该登录的权限。这是积极的，但对此的困惑是消极的。

2）我找不到链接，但OpenID对中间/网络钓鱼攻击中的社会工程/主要开放。提供商试图阻止这种情况（ID图像，浏览器证书，回拨验证等），但当黑帽网站弹出一个显示“输入您的OpenID用户名和密码”的对话框/页面时，它无济于事用户遵守。

3）联盟身份证的每个提供者都有能力（有些人会说是责任）来跟踪其用户的所有活动，无论他们使用该ID的站点是什么。这就是为什么谷歌和雅虎都要提供提供联合身份证的原因，但对消费他们并不感到兴奋。

4）与上述评论相反，通常情况下使用OpenID会降低注册的障碍，尤其是当有用的UI指出新用户可能已经拥有OpenID时。当您使用组合的OpenID / OAuth解决方案（如RPX）时更是如此。

因此，从我的角度来看，使用OpenID的风险在于用户，而不是网站。我无法通过让用户尝试记住另一个用户ID＆amp;来阻止用户被钓鱼。密码。此外，Black Hats不需要做任何比以纯文本存储其站点的用户密码以访问用户的其他帐户更邪恶的事情。有多少人在登录的每个网站上使用不同的密码？

Answer 6

一个问题是“未发明在这里”的某种组合以及外部权威对（甚至是伪）身份的不信任。这里写的很好：

• Do You Trust your Identity Provider?

另外，我认为这可能是惯性。没有一个杀手级的应用程序来驱动它，人们迁移的速度很慢。鉴于我最近看到的Facebook集成数量有所增加，我认为我们处于陡坡的顶端，即将进入那个世界。

Answer 7

正如另一张海报所示，授权通常是特定于应用程序的。您在一个应用程序中可以做的事情与您在另一个应用程序中的操作有很大不同特别是在客户现成的应用程序中，授权通常由应用程序自然处理。

表现是另一个问题。这可以通过获取Sun的XACML实现并使用它来外部化某些授权来看出。您在请求的两端产生网络成本（取决于您的架构请求/响应的方式等）可能远远超过授权决策的实际成本。将其构建到COTS应用程序中，您可以减少性能优化的自由度，事情会变得更糟。

但是，我认为一些有希望的领域是遵守法规。有些授权不会因应用程序而异。例如，转让专有或机密信息或材料。在这些情况下，可以对每个应用程序中存在的相同控件进行强有力的处理，因为反之亦然。拥有相同访问控制的任意数量的实现和规则是管理的噩梦。从像XACML这样的控制框架开始的一个简单的地方可能是从某人可以看到的东西开始，然后确定某人可以做什么。

Answer 8

我认为这取决于您所从事的项目类型。如果客户希望存储授权，则无法使用OpenID ...我使用谷歌应用引擎开发了一个小项目，因此我使用谷歌进行授权。所以它在很大程度上取决于项目的类型。

Answer 9

就我个人而言，这是我听过外部授权的第一件事。 所以可能只是缺乏意识。

现在谷歌搜索..

Answer 10

有几个原因：

1. 正如一些评论所表明的那样，人们普遍认为“授权是本地的”，这意味着重新使用所需的昂贵到维持在高质量的“主题属性”的可能性很小。重要的访问决策。 （我认为有很高的重用潜力，因为一些法律/注册表广泛适用，但对于这种格式，对此的全面讨论太长了。）
2. 缺乏数据基础架构：在组织之间应用基于策略的访问控制（我使用/信任其他组织授权（“AuthZ”）数据来解锁对我的数据的访问）至少需要我理解语义属性（什么是“执法官”？什么是“美国公民”。）之后，如果有易于理解的属性质量标准和相同的第三方认证将是很好的。 （有些人可能会发现这些要求类似于PKI互操作性的要求：它是如何产生的？这只是一个数据，加上支持的东西。）
3. 对角色/职责的影响：外部授权，无论是“角色”还是“属性”还是“具有数字政策的属性”，都意味着本地“数据所有者”失去对资源的控制权。他还卸载了维护用户列表的大量工作和责任。这种变化将外部AuthZ的实施从技术问题提升到具有政治一面的组织事务。
4. 大多数组织都不知道并且没有写下他们的政策。访问可能是“谁问”或“谁问我喜欢”或“谁可以给我一些东西，比如访问他们的数据”。当通过用策略语言表达它们时，实际应用的规则可能会非常难看。将书面政策良好地转化为数字政策的技能也不会在树上增长。事实上，技能组合是商业分析师或律师，而不是IT人员，并且这些人的工具很少是不存在的。
5. 当你有一个可靠的策略规则时，你可能会发现处理它所需的属性不存在 - 它们通常不是你在AD中找到的那种东西。电话号码作为AuthZ属性并不实用，甚至“组织”也可能不适合大多数法律或您可以实际记录的注册表。这甚至没有提到你必须实施（并获得批准）表达诸如“可能原因”等政策要求的解决方法和近似值。
6. 相对容易处理，但仍然是真实的，许多非常普遍的COTS应用程序不支持外部授权，并且许多应用程序开发人员不习惯进行外部化，因此（a）会尝试与您讨论;或者（b）在你的角钱里学习它，并且做得很糟糕。

---

听起来很糟糕，对吧？所以，最后我要说的是，尽管如此，我仍然认为这场比赛是值得的。潜在利益清单是另一个职位的另一个职位。

祝你好运！

Answer 11

同意约瑟夫的观点，即授权是高度针对特定应用的。

但是，除此之外，外包授权还带来了一个主要的风险问题：由于授权是高度针对特定应用程序的，而且粒度很细，一旦将授权外部化到服务提供商，迁移或替换该提供商就几乎是不可能的任务。您将不可避免地陷入困境。

因此，在评估您的风险和收益时，业务推理会促使您避免受到如此严格的依赖。