For some applications, working with user identity is simple. Consider a Windows application that is accessed only by users in a single organization, and doesn’t need to know much about those users. This application can simply rely on Kerberos, part of Active Directory Domain Services (AD DS), to authenticate its users and convey basic information about them. Or consider an application that is accessed only by Internet users. This application can simply require each user to supply a username and password, and store this user information in a database.

However, for most applications, working with user identity is more complex. Consider an application that needs more information about each user than is provided by either Kerberos or a simple username and password. The application has to acquire this information from some other source, such as AD DS, or store the information itself. Or consider an application that must be accessed both by employees inside the organization and by Internet users. The application must support both Kerberos and username and password based logins. Finally, suppose the application must be accessed by a different organization without requiring a separate login. This identity federation can’t be accomplished very well with either Kerberos or username and password logins.

The following diagram shows the problem of identity silos in a typical organization. As you can see, the user is forced to sign in separately just to access different applications in the user’s own domain, to say nothing of applications in other domains.

Claims-based identity provides one approach to identity that works in all of these scenarios. It is based on widely recognized industry standards that work across both platform and organizational boundaries. It is also widely implemented in products from multiple vendors, and simple for developers to use.