Is there a reason why software developers aren't externalizing authorization?

StackOverflow https://stackoverflow.com/questions/955399

Question

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.

Was it helpful?

Solution

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.

OTHER TIPS

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.

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.

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?

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.

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.

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.

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:

  1. As some of the comments demonstrated, there is a general perception that "authorization is local" which implies that there's little potential from re-use of the expensive-to-maintain-at-high-quality "subject attributes" needed for important access decisions. (I believe that there is high reuse potential since some laws/regs are widely applicable, but full discussion of this is too long for this format.)
  2. Lack of data infrastructure: to apply policy-based access control between organizations (me using/trusting some other org's authorization ("AuthZ") data to unlock access to my data) requires, at a minimum, that I understand the semantics of the attribute (what is a "law-enforcemment officer"? What is a "US Citizen".) After that, it would be nice to have easy to understand attribute quality standards and third-party certification of same. (Some may observe that these requirements are analogous to the requirements for PKI interoperability: how's that coming along? And that's just for one piece of data, plus supporting stuff.)
  3. Impact on roles/responsibilities: externalizing authorization, whether to "roles" or to "attributes" or to "attributes with digital policy", means that the local "data owner" loses control of the resource. He also offloads considerable work and responsibility for maintaining user lists. This kind of change elevates implementation of external AuthZ from a technical problem to an organizational matter with a side of politics.
  4. Most organizations don't know and haven't written down what their policies are. Access may be "whoever asks" or "whoever asks and I like" or "whoever can give me something, like access to their data." The real rules applied can be pretty ugly when they are forced into the open by expressing them in a policy language. And the skill set for good rendition of written policies into digital policies doesn't grow on trees, either. In fact, the skill set is business analyst or lawyer, not IT guy, and tools for those folks are rare to non-existent.
  5. When you do have a solid policy rule, you will likely discover that the attributes needed to process it do not exist--they are not typically the kind of thing you find already in AD. Phone number is NOT useful as an AuthZ attribute, and even "Organization" is probably not appropriate for most law or regs you can actually document. That's not even mentioning the work-arounds and approximations you have to implement (and get approved) to express policy requirements like "probable cause."
  6. Relatively tractable, but still real, is that many very widespread COTS apps don't support external authorization, and many app-developers are not used to doing externalization, and so will (a) try to talk you out of it; or (b) learn it on your dime, and do it badly.

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top