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.
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.
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.
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.
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.
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.
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.
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?
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..
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.