Authorisation
(note to self, don't start writing a series of posts unless you have them all ready to publish otherwise they seem to go on forever!)
Federation for Government Overview
Do you need strong authentication?
Another post in the “eID for Governments” and we need to cover off what happens when a user bearing a SAML token arrives back on the site they want to access.
The process the site needs to go through is simple:
- Is the token from an STS I trust
- Is the signature in the SAML token valid
- Does the user have the claims I want.
As long as we pass those test we can then allow the user in and give them the roles, determined by their claims.
This is again why I like federation, we now have a consistent authorisation model. Instead of writing new code for every new way of authenticating we just need to add in that we trust a new STS and make sure the claims they are sending can be linked up to something that we understand.
Even if your site has its own authentication, but architecturally splitting the authentication into an STS means that you have a structured way of authorising users. When you need to change it and add other provides or methods, you just have to configure new STS’s rather than changing the code in your site.
Kim Cameron explains this very clearly in his PDC session Identity Roadmap for Software + Services (i cannot get the embedded video to play, if you cannot then you can get to the recording here and the slides are here). As he says, the first two lines of every connected application (actually these tend to be large and complex blocks of code) is:
- Who are you?
- What are you allowed to do?
We need to have a consistent architecture for dealing with authentication and authorisation, developers have spent too much time writing complex logic into their application to deal with it. All the major vendors are coming together and working on the same standards, hopefully one day soon authentication and authorisation can be handled by the platform rather than in code.