软件开发人员不将授权外部化有什么原因吗？
外部化身份的价值主张开始增加，许多站点现在接受 OpenID、CardSpace 或联合身份。 然而，许多开发人员尚未采取下一步行动来外部化基于 XACML 的授权和使用方法。
原因是缺乏认识还是其他原因？ 您希望如何了解基于XACML的软件开发方法？
请注意，我询问的是授权，而不是身份验证。
The value proposition of externalizing identity is starting to increase where many sites now accept OpenID, CardSpace or federated identity. However, many developers haven't yet taken the next step to externalize authorization and use approaches based on XACML.
Is the reason lack of awareness or something else? How would you expect to learn about XACML-based approaches to software development?
Please note that I am asking about authorization, not authentication.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我认为外部化授权的前景比外部化身份验证（OpenID、CardSpace 等）困难得多。 这主要是因为授权更加特定于应用程序。 A 被授权在我的应用程序中执行的操作可能无法在您的应用程序中执行，甚至假设我的应用程序和您的应用程序之间存在一些共同的相似之处，但很可能不会存在。
我不想说外部化授权永远会被完成，但说实话，我很难想出为什么你真的想这样做。 也许对于一组并行工作的应用程序来说，但同样，这很可能是内部支持，而不是外部支持。
I think the prospect of externalize authorization is a much more difficult thing than externalizing authentication (OpenID, CardSpace, etc.). This is mainly due to the fact that authorization is much more application specific. What Person A is authorized to do in my application he may not be able to do in your application, and that's even assuming there's some common parrallel between my application and your's, which most likely there won't be.
I don't want to say that externalizing authorization will never be done, but I honestly have a tough time coming up with reasons why you'd really want to do that. Maybe for a suite of applications that work side by side, but again, that would most likely be supported internally, rather than externally.
另外，请记住授权！==身份验证。 仅仅因为用户经过身份验证并不意味着您已经解决了站点的授权部分。 您仍然需要确定谁可以在何时做什么。
Also, remember that authorization !== authentication. Just because a user is authenticated doesn't mean you have solved the authorization part of your site. You still need to determine who gets to do what and when.
我们继续推出自己的主要原因是像 openid 等选项似乎只受到技术网站的支持。 我们是一个规模较小的参与者，因此在用户接受度更高之前我们不会开始使用外部提供商。
我们不希望用户在我们网站上要做的第一件事就是访问另一个网站。
The main reason we continue to roll our own is that the options like openid et al are only seemingly supported by tech sites. We're a smaller player, so we won't start using an external provider until such a time that there is a much greater user acceptance.
We don't want the first thing a user has to do on our site to involve going to another site.
我似乎陷入了其他人的误解 - 问题是关于外部授权的。 就我个人而言，我只信任本地网络上的分布式授权，在本地网络上我可以控制身份验证和授权服务器。 我永远不会在网站上使用外部授权。
以下是我对 OpenID 作为身份验证服务的评论。
1）正如所指出的，授权！=身份验证。 OpenID 处理身份验证，但 Web 应用程序所有者仍然可以完全控制分配给该登录的权限。 这是积极的一面，但对此的困惑是消极的。
2）我找不到链接，但OpenID对社会工程/中间主要/网络钓鱼攻击开放。 提供商试图阻止这种情况（ID 图像、浏览器证书、回调验证等），但当黑帽网站弹出一个对话框/页面显示“输入您的 OpenID 用户名和密码”并且天才时，这并没有帮助。用户遵守。
3) 联合 ID 的每个提供商都有能力（有些人会说有责任）跟踪其用户的所有活动，无论他们将该 ID 用于哪个网站。 这就是为什么 Google 和 Yahoo 热衷于提供联合 ID，但对使用它们却不太感兴趣。
4) 与上述评论相反，通常的情况是使用 OpenID 减少了注册障碍，特别是当有用的 UI 指出新用户可能已经拥有 OpenID 时。 当您使用组合的 OpenID / OAuth 解决方案（例如 RPX）时，情况更是如此。
因此，从我的角度来看，使用 OpenID 的风险在于用户，而不是网站。 我无法通过让用户尝试记住另一个用户 ID 和密码来防止用户被钓鱼。 密码。 此外，黑帽不需要做任何比以纯文本形式存储其网站的用户密码更邪恶的事情来访问用户的其他帐户。 有多少人在登录的每个网站上使用不同的密码？
I seem to have fallen into the misunderstanding that the others have - the question was about external authorization. Personally, I would only trust distributed authorization on a local network where I have control over the authentication and authorization servers. I would never use external authorization on a web site.
Below are my comments on OpenID as a authentication service.
1) As was pointed out, authorization != authentication. OpenID handles authentication, but the web app owner still has full control over the rights assigned to that login. This is a positive, but the confusion about this is a negative.
2) I can't find the link, but OpenID is open to social engineering / main in the middle / phishing attacks. The providers try to prevent this (ID images, browser certificates, call back verification, etc) but it doesn't help when the black hat site pops up a dialog / page that says "enter your OpenID user name and password" and the genius user complies.
3) Each provider of a federated ID has the ability (and some would say responsibility) to track all the activities of their users, regardless of what site they use the ID for. This is why Google and Yahoo are gung-ho to provide federated IDs, but not so excited about consuming them.
4) Contrary to an above comment, it is commonly the case that using OpenID reduces the barrier to registration, especially when a helpful UI points out that a new user probably already has an OpenID. This is even more true when you use a combined OpenID / OAuth solution such as RPX.
So, from my point of view, the risks of using OpenID are on the user, not the web site. I can't prevent the user from being phished by making them try to remember yet another user ID & password. Further, Black Hats don't need to do anything more nefarious than store user passwords for their site in plain text to get access to a user's other accounts. How many people use a different password for every web site the log into?
我所做的大多数项目都是在大公司内使用的专有应用程序，在这些情况下，外部身份验证服务很少是一种选择，而是由某些内部服务（例如 Active Directory）处理身份验证。
如果我碰巧成为一个构建公共网站的项目的一部分，我肯定会尝试使用 OpenID 之类的东西，而不是托管我自己的身份验证。
Most projects that I have done have been proprietary applications for use within large companies, and in those cases external authentication services are rarely an option, but authentication is instead handled by some internal service (such as Active Directory).
Should I happen to become part of a project that would build a public web site I would definately try to make use of something like OpenID instead of hosting my own authentication.
一个问题是“Not Invented Here”和对外部权威（甚至是假名）身份的不信任的某种结合。 一篇很好的文章在这里：
另外，我认为这可能是惯性。 如果没有杀手级应用程序为其提供支持，人们的迁移速度就会很慢。 鉴于我最近看到的 Facebook 集成数量的增加，我认为我们正处于陡峭斜坡的顶部，即将进入那个世界。
One problem is some combination of Not Invented Here and mistrust of externalized authorities for (even pseudonomous) identity. A good write-up is here:
Also, I think it may be inertia. Without a killer app to power it, people are slow to migrate. Given the rise in the number of Facebook-integrations I've seen lately I think we're on the top of a steep slope, about to enter that world.
正如另一位发帖者所指出的，授权通常是特定于应用程序的。 您在一个应用程序中可以执行的操作与在另一个应用程序中可以执行的操作有很大不同。 特别是在客户现成的应用程序中，授权通常更自然地由应用程序处理。
性能是另一个问题。 这可以通过获取 Sun 的 XACML 实现并使用它来外部化一些授权来看出。 您在请求双方产生的网络成本（取决于您构建请求/响应等的方式）可能远远超过授权决策的实际成本。 将其构建到 COTS 应用程序中，在其中性能优化的自由度较小，情况会变得更糟。
然而，我认为一些有前途的领域是围绕监管合规性的。 有些授权不会因应用程序而异。 例如，专有或机密信息或材料的传输。 在这些情况下，可以为每个应用程序中存在的相同控件提供强有力的理由，因为相反的情况非常糟糕。 对于相同的访问控制拥有任意数量的实现和规则是管理的噩梦。 使用 XACML 等控制框架的一个简单方法可能是从某人可以看到的内容开始，然后确定某人可以做什么。
As another poster indicated, authorization is generally application-specific. What you can DO in one application varies significantly from what you can DO in another. Especially in customer off-the-shelf applications, authorization is generally more naturally handled by the application.
Performance is another concern. This can be seen by obtaining Sun's XACML implementation, and using it to externalize some authorization. You incur network costs on both sides of the request that (depending on the way you architect request/response, etc.) can far exceed the actual cost of the authorization decision. Build that into a COTS application, where you have less freedom for performance optimization and things get even worse.
However, I think some of the promising areas are around regulatory compliance. There are some authorizations that do not vary by application. Transfer of proprietary or classified information or materials, for example. In these cases, a strong case can be made for the same control existing in each application, because the converse is so bad. Having any number of implementations and rules for the same access control is a management nightmare. An easy place to start with a control framework like XACML may be to start with what someone can see, and then work out to what someone can do.
我认为这取决于您从事的项目类型。 如果客户想要存储授权，则无法使用 OpenID...我使用 google apps 引擎开发一个小项目，因此我使用 google 进行授权。 因此，这在很大程度上取决于项目的类型。
I think it depends on the type of project you work on. If the customer wants store the authorization there is no way to use OpenID... I develop a small project using google apps engine and therefor I use google to do the authorization. So it strongly depends on the type of project.
有几个原因：
听起来很糟糕，对吧？ 所以，最后我想说的是，尽管如此，我认为这款游戏还是得不偿失的。 潜在好处的清单将在其他时间发布另一篇文章。
祝你好运！
Several reasons:
Sounds pretty bad, right? So, let me end by saying I think the game is worth the candle despite all this. The list of potential benefits is for another post at another time.
Good luck!
同意约瑟夫关于授权高度针对应用程序的观点。
但除此之外，外包授权还带来了一个重大风险问题：由于授权具有高度的应用特定性和粒度，一旦将授权外部化给服务提供商，迁移或替换该提供商几乎是不可能的任务。 你已经无可挽回地陷入困境了。
因此，在评估您的风险和收益时，商业推理会促使您避免如此严重的依赖。
Agree with Joseph's point on authorization being highly application specific.
But besides that, outsourcing authorization also brings in a major risk concern: since authorization is highly application specific and granular, once you externalize authorization to a service provider, migrating away or replacing that provider becomes a nearly impossible task. You are on the hook irrevocably.
So in evaluation of your risks and benefits, business reasoning drives you to avoid going with such a hard dependency.
对于我个人来说，这是我第一次听说外部授权。
所以可能只是缺乏意识。
现在谷歌搜索..
For me personally, this is the first thing I have ever heard about external Authorization..
So it might just be lack of awareness.
Googling now..