Federated identity supplies user information to applications offered by different organizations allowing for single sign-on, one identity for common access, and provisioning of authoritative data. When a user wants to access a controlled resource, a set of attributes is collected dynamically and delivered to the application. Based on this real-time provisioning, the application can make a decision to grant or reject access, or can customize the application for the user.
This identity information can be anything. It could be the user's full identity, or simply the fact that the user can authenticate successfully, leaving the user anonymous. This policy is written per user and per provider to ensure privacy is respected while still delivering all the information an application needs.
There are several major advantages of federated identity:
- It delivers authoritative user attributes directly from the organization responsible for the credentials ;
- Resource providers not longer need to manage accounts, plus access is broadened;
- User data is protected. Storage at a single, hardened location and stringent release policies minimize the chance of privacy violation;
- The user experience is improved, with no special software, no proxies, and no configuration required. Single sign-on is possible.
Shibboleth is an enterprise-class federated identity system. Easy support for any number of users and any number of partners is a key design fundamental, as is interoperability with many commercial systems and applications through extensive support of open standards. Its flexible architecture integrates with other identity infrastructures in many configurations.
Shibboleth has two major halves: an identity provider (IdP), which authenticates users and releases selected information about them, and a service provider (SP) that accepts and processes the user data before making access control decisions or passing the information to protected applications. These entities trust each other to properly safeguard user data and sensitive resources.
Attributes are the core unit of identity data. They have many representations in many systems, but distill to be a single piece of information that is a name/value pair. For example, my surname might be Lehnsherr, or my uid might be scarmody. A set of useful examples is in the default configuration, but you can define any attribute you wish.
These attributes are usually not stored within Shibboleth itself, but instead pulled from other sources. IdP sites may choose to use a directory or database to store user data, while applications may augment the attributes they receive from an IdP . Shibboleth is capable of using arbitrary, different attribute names for each interface, decoupling the name in any protocol from all other systems.
This focus on attributes allows Shibboleth to transfer and utilize only the essential information for any application.
Shibboleth supports a lot of profiles and protocols, but to keep things simple, let's step through the basic profile, which uses SAML 2.0 and encryption.
Step 1: User Accesses Protected Resource. A user can browse a site freely, but once they want to access a protected resource or perform a sensitive operation, Shibboleth intercepts the request and gathers some data first. The SP determines, sometimes with the user's help through buttons or lists, where to send the user home to login.
Step 2: User Authenticates to the IdP. A SAML 2.0 AuthnRequest is issued by the SP to the IdP. The authentication request is placed in the browser, and the user is redirected back to the IdP. The IdP examines the request and decides how it would like to authenticate the user based on the configuration for this SP. The user is redirected to login and comes back bearing an authenticated username.
Step 3: IdP Issues Response to SP. The IdP gathers a set of attributes about the user from back-end sources, transforming them if necessary. These attributes are then filtered, often by the SP or user, so that only necessary information is revealed. The attributes are all encoded and wrapped in a SAML 2.0 assertion. This assertion is signed with the IdP's key and encrypted with the SP's key for security and privacy. The assertion is placed into a message and the user is redirected to the SP carrying it along.
Step 4: Return to the SP. The user is sent to the SP, which unpacks the message, decrypts the assertion, and performs several security checks. If everything's in order, the SP will extract attributes and other information from the message. Attributes are translated into local variables. They can then be used to enforce rules, or they can be delivered to the application to use however it needs.
To avoid the need for all providers to independently vet all of their partners, and to make it easier to find applications and users that are available, many communities have chosen to form federations. A single entity and organization can join multiple federations, though each new federation introduces a little complexity.
A federation is anything you want it to be: single sign-on within one organization, or a very large community such as an entire country's research and education sector. It requires a consistent policy outline, and a few technical arrangements.
Individual sites generally retain all rights and ability to make decisions regarding users and applications independently. The federation is just a framework.
To avoid excessive federation creation, please check to ensure there isn't already a federation that meets your needs before creating a new one.
Shibboleth requires no modification of client software. There is also no modification of existing identity infrastructure or applications needed, although we recommend leveraging Shibboleth as the authentication and attribute delivery system whenever possible, since it's a generalized solution.
The IdP is written in Java, and operates in any standard servlet container. Authentication can be performed many ways, including through Kerberos, LDAP, or the web server itself. Attributes can be sourced from any directory or database or generated internally, and transformed using predefined rules or almost any scripting language. It has built-in replication. The biggest hardware requirement is CPU for XML encryption and signing, which can be reduced through protocol tradeoffs.
The SP runs in Apache, IIS, or NSAPI, and these environments can be proxied into Java and other web servers. It can run automatically or on-demand, and protect resources itself or allow applications to handle access control. It has built-in clustering support and minimal hardware requirements.
Shibboleth supports the SAML 2.0 Web Browser SSO Profile, Cardspace, Shibboleth Profile, ADFS, and SAML 1.1, along with other protocols such as LDAP, SQL, and Kerberos. It is interoperable with known commercial SAML 2.0 providers, and fully backward compatible with Shibboleth 1.3.
