I’ve talked to many customers who were looking to make the various applications in their organizations behave as a single system to their end users. This is a great goal as it leads to many benefits from higher user productivity to lower training costs. However, the discussion invariably comes around to the question of how users will interact with the various applications. Because the login is the first part of a user’s interaction with a system, the discussion begins to focus on identity and access management (IdM or IdAM).
I’ve found that the discussion quickly becomes very confused and muddied. In retrospect, most of the confusion seems to stem from a lack of understanding of all of the moving parts involved in identifying a user or in giving that user access to a resource. I find that rather than talking about IdM as a whole first and drilling down into greater detail later, it is better to start with a clearly defined list of the components involved in IdM and then see how they fit together.
This post is not intended to go into great detail about IdM. There are many other online resources that go into very great detail about each aspect of IdM. Instead the goal of this post is to the provide an overview of the components involved in IdM and to provide an example of how these components work together to provide users with access to a system. Ideally, a semi-technical person would be able to read this post and get the big-picture about IdM.
System
A system is a collection of 1 or more computing devices that have a consistent notion user identity. The more computers and devices that we can include in this collection, the better the experience will be for the user when accessing those computing devices.
Examples:
- A desktop computer
- A server
- A video game console
- A smart phone
- A group of servers and desktops tied to an organization’s user directory
- All computers and devices on the Internet
- All computers and devices in the world
Credential
A credential is a piece of information that a user supplies to a system to prove the user is who he/she claims to be. This information is often composed of a publicly known component, such as a username, and a private component, such as a password. A single credential (such as a client certificate) may be associated with multiple user accounts in multiple systems. This principal is often used by systems implementers in adding user single sign-on capabilities across multiple systems.
Examples:
- Username and password
- Client certificate
- Smart card and pin
- Biometrics
Authentication Token
An authentication token is a passkey (usually temporary) to one or more systems that is independent of the credentials and authentication mechanism. Depending on the system and the form of the authentication token, the authentication token may be encoded, digitally signed, and encrypted. One of the most important characteristics of an authentication token for suitability with single sign-on (SSO) is the transportability of the token. Many types of tokens are not transportable from the computing device to which they were issued, leading to what is referred to as “the double hop issue.”
Examples:
- Windows logon token
- Kerberos ticket
- SSO cookie
- Session ID
Authentication Mechanism
The authentication mechanism is the protocol that a client uses to transmit credentials to a service and the service uses to transmit an authentication token back to the client. Different authentication mechanisms have differing characteristics, such as their encryption strength and network protocol requirements.
Examples:
- NTLM
- Kerberos
- HTTP Basic
- HTTP Digest
- OpenID
- Windows Live ID
Security Principal
A security principal is an entity that is able to have permissions within a system. It is important to note that while many systems have a one-to-one correlation between user accounts and security principals, systems are not required to treat user accounts as security principals. In fact, some systems make explicit distinctions between user accounts and security principals. Users of these systems must explicitly select a security principal in whose context they will use the system after login, and can often switch their security principal context as they use a system.
Examples:
- User account
- Group
- Role
User Account
A user account is an entity within a system through which the user interacts with the system and to which the system can link one or more credentials, security principals, and authentication tokens. All other user properties not used to enable user logon are part of the user profile.
Examples:
- User account
- Service account
- Computer account
User Profile
A collection of properties representing a person within a system. A user profile may have 0, 1, or more user accounts associated with the profile. Most systems however, associate a single user profile with each user account. The user account and user profile information may be stored in the same physical store or in different physical stores. Systems generally use user profiles to provide users with a more personalized usage experience. User profile information is generally not used to log users into a system.
Examples:
- Name
- Street address
- Email address
- Tax identification number
Securable Object
Any resource to which the system can restrict access using access control lists.
Examples:
- Network file share, folder, or file
- Document
- Site, page
- Mailbox
Permission
The right to perform a particular action on a securable object. The types of available permissions will vary depending on the type of the securable object.
Examples:
- Create
- Read
- Update
- Delete
- Delegate
- Take ownership
Access Control List (ACL)
A list of three-tuples in the form of [securable object, permission, security principal]. Most systems store and retrieve ACLs using the securable object as the key value for storage and retrieval. This allows the systems to easily answer questions like, “Who has what type of access to this securable object?” However, it makes it much more difficult for the systems to answer the questions like, “What are all of the securable objects to which this security principal has access,” or “What are all the security principals that have this permission to any securable object within the system?”
Examples:
- Access permissions for a security principal on a network file share, folder, or file
- Access permissions for a security principal on a site or page
- Access permissions for a security principal on a mailbox
User Identity
All of the knowledge that a system has about a real person across all actions the user takes within the system. User identity is not the same as a user account. Just as a person (a user identity) may have multiple bank accounts, a person may also have multiple user accounts. Unfortunately, most systems do not support associating multiple user accounts with a single user identity.
Examples:
- Eugene Rosenfeld
- List of user accounts
- List of user profiles
- List of security principals
- List of access control lists
- Outlook associates multiple email addresses and instant messaging address with a single contact (user identity)
- Palm Web OS associates multiple user accounts with a single contact (user identity) in its contact application
- Trillian instant messaging client associates multiple instant messaging service accounts (MSN, Yahoo, AIM, ICQ, etc…) with a single instant messaging contact (user identity)
Single Sign-On (SSO)
There are many definitions for single sign-on (SSO). SSO is not really a core component of identity and access management. Rather, SSO is the very desirable goal of a system’s IdM implementation that a user has to provide only one set of credentials to gain access to all system resources and all systems to which the user has access. SSO does not necessarily ensure that the user has a single identity across all systems, only that the user only has to provide only one set of credentials to access the systems. SSO typically does not control permissions. SSO is there to ensure that a user can get to another application within a system or to another system. Once at the other application or system, it is up to that application or system to determine what privileges the user has, and to which resources the user has access, if any.
Examples:
- Multiple web sites using OpenID or Windows Live ID (formerly Microsoft Passport) to authenticate a user.In this case the user has one set of credentials (the OpenID or Windows Live ID) but multiple identities, one per web site. The sites do not communicate with each other so there is no cohesive system.
- Multiple web sites using OpenID to authenticate a user and correlate the user’s activities across the web sites. In this case the user has one set of credentials and one identity. The sites share information about the user’s activities on the other sites and act as one system. The user may have multiple user accounts (to which the single credential is mapped) and multiple user profiles, one per site.
Stay tuned for part 2
In part 2 I will provide an example or two of how a system would combine the various components described in this post to authenticate and authorize users, and to establish their identities within the system..
This is my first crack at this type of post. I welcome constructive comments and corrections.
One thing you may want to mention is that SSO while accepting a userid and password does not typically control privileges within the systems that are under its umbrella; but insteads passess mapped credentials to those systems and relegates authorization to those systems unless otherwise designed.
Agreed with the first part. I'll add it to the post. But SSO does not authorize. SSO as a goal simply ensures that the user only has to worry about one set of credentials. There are many ways to implement the goal. The Microsoft way of doing this is as you say, by mapping the user's credentials in one application to another set of credentials for another application.
I think we said the same thing – SSO Authenticates… and leaves authorization to application content up to the application. However, like you mention it depends on the implementation Netegrity Siteminder can do both but it requires a much greater integration.
SSO can authorize too. Example: access to resource /foo is only available to employees on internal network. That rule can be implemented in the SSO infrastructure.
You're absolutely right. Many "SSO applications", like Microsoft's SSO do incorporate an authorization mechanism. Most SSO applications allow multiple user accounts in a source application to map to a group or service account in a target application. So the SSO application has to do its own authorization because the target application can no longer distinguish between the multiple users sharing the same account and hence can not do its own authorization.
However, strictly speaking authorization is not really part of SSO. Getting an authorization component with an SSO application is like buying a toaster and getting a butter knife with the package, not strictly needed to toast bread but still very useful.
Great blog, by the way.