软件开发人员没有将授权外化吗？

Question

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

是缺乏意识还是别的原因？您如何期望了解基于XACML的软件开发方法？

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

Answer 1

我认为外部化授权的前景比外在的身份验证（OpenID的，CardSpace的，等等），一个更加困难的事情。这主要是因为授权更多的是特定于应用程序的事实。 A在我的应用程序中被授权执行的操作，他可能无法在您的应用程序中执行，甚至认为我的应用程序和您的应用程序之间存在一些共同的平行关系，而这很可能不会发生。

我不想说外部授权将从来没有被完成，但我真的有一个艰难的时间来与你为什么真的想这样做的原因。也许对于一组并行工作的应用程序来说，但同样，这很可能在内部得到支持，而不是在外部得到支持。

Answer 2

我认为这取决于你的工作类型。如果客户想要存储授权，则无法使用OpenID ...我使用谷歌应用程序引擎开发一个小项目，因此我使用谷歌来执行授权。所以它强烈依赖于项目类型。

Answer 3

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

我们不希望用户必须做我们的网站涉及到另一个网站的第一件事。

Answer 4

，我已经做了大部分项目已使用的专有应用大公司内，在这些情况下外部认证服务很少是一种选择，但身份验证，而不是通过一些内部服务（如Active Directory）来处理。

我应该正好成为将建立一个公共网站我肯定会尝试使用类似的OpenID，而不是托管我自己的认证项目的一部分。

Answer 5

另外，记住授权！==认证。仅仅因为用户被认证并不意味着你已经解决了你网站的授权部分。你仍然需要确定谁可以做什么，什么时候做什么。

Answer 6

一个问题是没有发明这里和（甚至pseudonomous）身份外化主管部门的不信任某种组合。一个好的写了是在这里：

• Do You Trust your Identity Provider?

而且，我认为这可能是惯性。如果没有杀手级应用程序，人们迁移速度会变慢。鉴于我最近看到的Facebook集成数量的增长，我认为我们正处于陡峭坡度的顶端，即将进入这个世界。

Answer 7

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

以下是我对OpenID作为认证服务的评论。

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

2）我找不到链接，但OpenID向中级/网络钓鱼攻击的社交工程/主要开放。提供商试图防止这种情况（身份证件图像，浏览器证书，回拨验证等），但是当黑帽子网站弹出一个对话框/页面显示“输入您的OpenID用户名和密码”和天才用户遵守。

3）联邦ID的每个提供者都有能力（并且有些人会说责任）来跟踪他们用户的所有活动，而不管他们使用哪个站点的ID。这就是为什么谷歌和雅虎都是耿皓给提供联合身份证，但并不那么兴奋，他们消费。

4）与上面的评论相反，通常情况下，使用OpenID减少了注册障碍，特别是当有用户界面指出新用户可能已经拥有OpenID时。当您使用诸如RPX的组合OpenID/OAuth解决方案时，情况更是如此。

所以，从我的角度来看，使用OpenID的风险在用户而不是网站上。我无法通过让用户尝试记住另一个用户ID为&的密码来阻止用户被钓鱼。此外，黑帽并不需要做任何更为恶毒的事情，以纯文本形式存储用户密码以访问用户的其他帐户。有多少人在登录每个网站时使用不同的密码？

Answer 8

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

现在谷歌搜索..

Answer 9

作为另一的海报所示，授权通常是专用的。你可以在一个应用程序中做什么，与另一个应用程序可以做什么有很大不同。特别是在客户现成的应用程序中，授权通常更自然地由应用程序处理。

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

但是，我认为一些有前途的领域是围绕法规遵从性。有些授权不会因应用程序而异。例如，转让专有或机密信息或材料。在这些情况下，可以对每个应用程序中存在的相同控件进行强有力的处理，因为反面是非常糟糕的。对于相同的访问控制有任何数量的实现和规则是管理上的噩梦。从XACML这样的控制框架开始，一个简单的地方可能是从某人可以看到的东西开始，然后找出某人可以做什么。