Identity Management

Identity management, also known as identity and access management (IAM) is, in computer security, the security and business discipline that "enables the right individuals to access the right resources at the right times and for the right reasons". It addresses the need to ensure appropriate access to resources across increasingly heterogeneous technology environments and to meet increasingly rigorous compliance requirements.

The terms "identity management" (IdM) and "identity and access management" are used interchangeably in the area of Identity access management. "Identity management" comes under the umbrella of IT security.
Identity-management systems, products, applications and platforms manage identifying and ancillary data about entities that include individuals, computer-related hardware, and software applications.
IdM covers issues such as how users gain an identity, the protection of that identity and the technologies supporting that protection (e.g., network protocols, digital certificates, passwords, etc.).

Function
In the real-world context of engineering online systems, identity management can involve four basic functions:

The pure identity function: Creation, management and deletion of identities without regard to access or entitlements;
The user access (log-on) function: For example: a smart card and its associated data used by a customer to log on to a service or services (a traditional view);
The service function: A system that delivers personalized, role-based, online, on-demand, multimedia (content), presence-based services to users and their devices.
Identity Federation: A system that relies on federated identity to authenticate a user without knowing his or her password.

Pure identity
A general model of identity can be constructed from a small set of axioms, for example that all identities in a given namespace are unique, or that such identities bear a specific relationship to corresponding entities in the real world. Such an axiomatic model expresses "pure identity" in the sense that the model is not constrained by a specific application context.

In general, an entity (real or virtual) can have multiple identities and each identity can encompass multiple attributes, some of which are unique within a given name space. The diagram below illustrates the conceptual relationship between identities and entities, as well as between identities and their attributes.

In most theoretical and all practical models of digital identity, a given identity object consists of a finite set of properties (attribute values). These properties record information about the object, either for purposes external to the model or to operate the model, for example in classification and retrieval. A "pure identity" model is strictly not concerned with the external semantics of these properties.

The most common departure from "pure identity" in practice occurs with properties intended to assure some aspect of identity, for example a digital signature or software token which the model may use internally to verify some aspect of the identity in satisfaction of an external purpose. To the extent that the model expresses such semantics internally, it is not a pure model.

Contrast this situation with properties that might be externally used for purposes of information security such as managing access or entitlement, but which are simply stored, maintained and retrieved, without special treatment by the model. The absence of external semantics within the model qualifies it as a "pure identity" model.

Identity management, then, can be defined as a set of operations on a given identity model, or more generally as a set of capabilities with reference to it.
In practice, identity management often expands to express how model contents is to be provisioned and reconciled among multiple identity models.

How Shibboleth Works: Basic Concepts

At its core Shibboleth works the same as every other web-based Single Sign-on (SSO) system. What distinguishes Shibboleth from other products in this field is its adherence to standards and its ability to provide SSO support to services outside of a user's organisation while still protecting their privacy.

The main elements of a web-based SSO system are:
Web Browser - represents the user within the SSO process
Resource - contains restricted access content that the user wants
Identity Provider (IdP) - authenticates the user
Service Provider (SP) - performs the SSO process for the resource

Single Sign-on Steps
Step 1: User accesses the Resource
The user starts by attempting to access the protected resource. The resource monitor determines if the user has an active session and, discovering that they do not, directs them to the service provider in order to start the SSO process.

Step 2: Service Provider issues Authentication Request
The user arrives at the Service Provider which prepares an authentication request and sends it and the user to the Identity Provider. The Service Provider software is generally installed on the same server as the resource.

Step 3: User Authenticated at Identity Provider
When the user arrives at the Identity Provider it checks to see if the user has an existing session. If they do, they proceed to the next step. If not, the Identity Provider authenticates them (e.g. by prompting for, and checking, a username and password) and the user proceeds to the next step.

Step 4: Identity Provider issues Authentication Response
After identifying the user, the Identity Provider prepares an authentication response and sends it and the user back to the Service Provider.

Step 5: Service Provider checks Authentication Response
When the user arrives with the response from the Identity Provider, the Service Provider will validate the response, create a session for the user, and make some information retrieved from the response (e.g. the user's identifier) available to the protected resource. After this, the user is sent to the resource.

Step 6: Resource returns Content
As in Step 1, the user is now trying again to access the protected resource, but this time the user has a session and the resource knows who they are. With this information the resource will service the user's request and send back the requested data.

Federated Single Sign-on
If you have heard about Shibboleth you have probably also heard something about "federations" or "Federated Single Sign-on". The steps above are common to all SSO systems, but some of these systems are designed to only work when the Identity Provider and Service Provider are in the same organisation, whilst others are designed to work regardless of whether the two components are in the same organisation. Implementations that fall into the later category are said to implement Federated Single Sign-on.

It is not uncommon that a given Service Provider may wish to work with more than one Identity Provider (e.g. commercial services with multiple customers, resources used by researchers at multiple organizations), and likewise a given Identity Provider might wish to work with multiple Service Providers. When a group of Identity and Service Providers agree to work together, this group is called a federation.