Tuesday, August 11, 2009

Can you have Authentication without Authorization?

I hear this question a lot in large enterprise environments. First let me try to define authentication and authorization.
Authentication is the process of verifying the existence of a subject in a user store. This process is most commonly performed with a username/password combination. The combination of the data is the complete key used to look up the identity in the userstore. A username or a password by itself is not sufficient to verify an identity. Authentication is not limited to two pieces of data. Authentication should be something only you know if it is based on a password. Adding more pieces it becomes stronger because it is something you know and something you have, or something you are if biometrics is added to the mix. A completed authentication process then creates a security session but by definition it has not given you access it only proved you exist in the user directory.

Authorization is not the process of finding you in the user directory. Authorization is the process of determining if you are allowed to see the content or fulfill the request. Authorization rules can be based off of account balances, user profiles, time of day, ip addresses, etc. Any piece of data can really be used to make an authorization decision on a request.

Back to my original question can you have one without the other?
I think the easiest to prove is the authorization can not exist without authentication. Every request in a secure system should be validated that a security session based on authentication exists. The authentication has to happen every time before authorization can occur.

Authentication even if it is the only check that is required before access is granted is going to authorize the request. I like to call this a one step authentication/authorization combination. This is common for a lot websites. They only care to know that you have an account. After that you are allowed to view and request any other actions on the website.

Seems like a simple enough point; however, when you consider these differences in a large environment where multiple applications exist with multiple user stores single sign-on becomes very difficult. Now the different application create various sets of rules for timeouts, and resources. Sometimes the idea that comes out of this is a line of demarcation. I see the security team then becomes responsible for only authentication. Applications will handle authorizations. Sounds like a great idea. Not so fast my friend! It all depends on the goals. If you are trying to build a security layer where a base level of rules apply accross the board then you don't want to make this decree. You have to fight to keep authorizations in the same system that provides authentications. I also think this is also the most efficient way to process a request.
If a request comes into one system for authentication validation then why not take step two and perform the authorization. The other scenario is to allow the request and then the application performs the authorization.
Allowing the authorization at the application level could be a good idea. If the authorization rules are complex then they probably belong in the application. What do I mean by complex? Thanks for asking. I mean if the rules depend on contacting multiple other systems, making real time calculations, or authorizing multiple pieces of information for one request. Then there is probably no way this should be removed from the application decisions. The complexity will constantly be in flux with new rules and trying to make it a more generic decision that is good for everyone probably will never work.

Now what if you have both situations? Figure it out, but don't make it any more complex than it has to be. This is the toughest part of building a secure environment for multiple applications. Make the best decisions based on the goals of the company and the business requirements for that industry.

No comments: