The need of claim based security model and identity federation

The last couple of days I have been working on Windows Identity Foundation. In order to take advantage of this framework, you should start writing claim based application. Forget the old fashion role based and start demanding claims! Why to convert to claim based application you may wonder... There are many reasons why you should do that but the most appealing ones I can think of are the following:

1. Security granularity. You can demand specific claims from a user in order to do a specific action in your application. For example, imagine that you have a simple calendar application. You may demand a “read calendar” claim from the users in order to view the contents and request another “edit calendar entries” claim in order to edit the contents. By demanding claims, you don’t have to know the application’s roles a priory. You define the claims the user must have in order to access the specified code and when you finish, you may optionally associate the application roles to specific claims, thus enabling the role “managers” to have both the “read calendar” and “edit calendar entries” claims. You may specify as many claims as you like, thus enabling you to have total control on the access levels you may offer on your application.
2. No need to write the authentication mechanism and maintain user’s database. Although with the asp.net membership providers you may automatically create the users table in your database and not bother with the authentication mechanism, Federation provides you with the tools to trust others to authenticate users for you. You don’t even have to have a user’s table in your database. Someone else (an STS) will do the authentication for you and sent you the user’s security claims. This may not seem as a benefit in the beginning but if you see the bigger problem you will understand the importance of this feature. There are two benefits from authentication federation. 
   • It’s very common to have an intranet and have a couple of applications running inside it. These applications authenticate their users based on their own authentication mechanism, which means a lot of user tables on different databases. Having a single Security Token Service, you may have all your applications ask this STS for the user authentication which will centralize the users in one database, thus decreasing drastically your user administration efforts. In the best case scenario the intranet applications use windows authentication if there is an Active Directory (or another Kerberos authentication mechanism) in the domain. In this case, the Security Token Service comes as an intermediate security layer which abstracts the authentication mechanism by authenticating the users and providing the relying parties (your applications) an authenticated identity that has some claims. Thus your application doesn’t have to be tied up with an Active Directory and you may change the authentication method at any time (let’s say have smart card installed or issue certificates) without breaking your applications. The only thing you’ll have to do is reconfigure the STS to accept the new authentication method.
   • The second benefit comes when you want to externalize an intranet application. In this case, you’ll be authenticating both your intranet users and some external users from another company (let’s name this other company Contoso). If you have a custom authentication, you’ll have to add the new users and send them their new credentials which mean that the users will have to remember a new set of credentials and you’ll have to keep track of the new users and remove them in case they leave Contoso. One think is for granted. The Contoso’s HR department will not call you if they fire a person and you’ll have to manually call and find the current employment status. If on the other hand you had simply trusted Contoso’s authentication mechanism and simply allow the specific users to access your externalized application, then all problems are solved. This is called identity federation (http://en.wikipedia.org/wiki/Federated_identity). Whenever a user from Contoso comes to your application, you ask the trusted Contoso’s STS to authenticate the user and have your STS to simply transform the claims to the ones that are recognized by your applications (if there claims mapping is needed).

Fill free to add as a comment any other reason you may think of...