1. Shibboleth 2.0 IdP Training: Introduction
January, 2009

2. Before Lunch Introduction IdP Basics and Installation After Lunch
Authentication
Attributes
Productionalization
Basic topics we will be covering over the next 1-1/2 days. We plan to have lunch around 12 noon and have a mid-morning and afternoon break with refreshments/snacks. We’ll have other breaks as needed.

3. Federated Identity Management
Distributed identity management system
Enterprises trust each other to provide information
Security/privacy protection
Many organizations have implemented identity management systems within their organizations, which allow for many benefits, including reduced or single sign on within the organization. This is typically accomplished by configuring applications within the organization to trust or use a centralized authoritative source for identities.
However, today we find that many applications aren’t hosted locally – an application may be hosted by one organization, but the users are in another (or many others). Accessing these types of applications typically require giving the external organization detailed identity information about the organization’s users either by replicating the information to them, or giving the external organizations direct access to the centralized authoritative sources. This increases the security and privacy risk for the organization, as other external organizations are given access to a lot of identity information. If these type of solutions are not acceptable, then completely separate, non-synchronized identities need to be created and managed in the external systems.
In a federated identity management system, the components of the identity management system are distributed across organizations, with each organization trusting the other to perform the functions of the components they host. Organizations with identities need to provide applications only the information required to make authorization decisions. Organizations with applications need to manage identity information required for their applications, reducing the risk of storing or accidentally releasing sensitive information they don’t need.

4. Shibboleth Open source enterprise federated single sign on software
Project started in 2000, first release 2003
Current version 2.1
Standards based (SAML)
Widely used in education & government environments
Shibboleth is an open source, enterprise federated single sign on software solution using SAML, an OASIS standard. The Shibboleth project started in 2000 with the first release of software in The current version of Shibboleth is 2.0, released in 2008.
Shibboleth is widely used in education and government environments worldwide. Additional information about Shibboleth can be found at:

5. SAML Security Access Markup Language
XML-based standard for authentication and authorization data interchange
Identity Provider – producer of assertions
Service Provider – consumer of assertions
Current Version: 2.0
Shibboleth 2.0 implements SAML 2.0
The Security Access Markup Language, or SAML, is an XML-based standard for the exchange of authentication and authorization data between peers. There are two types of peers: an Identity Provider, which is a producer of authentication and authorization assertions, and a Service Provider which is a consumer of the assertions.
SAML assertions are statements from an Identity Provider that provide information to Service Providers to make access control decisions. There are three types of SAML assertion statements:
Authentication statements
Attribute statements
Authorization Decision statements
SAML is from OASIS and the current version is 2.0. Shibboleth 2.0 implements SAML 2.0.

6. How it works The user tries to access a protected application
The user tells the application where they are from
The user logs in at “home”
The user’s home tells the application about the user
The application accepts or rejects the user
How Shibboleth Works:
The user tries to access a Shibboleth protected application.
The user then tells the application where they are from, which we’ll call “home” (home is typically the organization their identity is hosted, such as a campus).
The user then logs in at home.
The user’s home tells the application about the user (SAML “assertions”).
The application uses the information it receives to authorize the user, either accepting or rejecting the user, and presenting the user with appropriate content.

7. How it works
Here’s the same process from the previous slide, but as a graphic to better illustrate who is doing what.

8. How it works (Shibboleth 2)
This version shows the Shibboleth components involved - there are three services:
Shibboleth Service Provider – “protects” the applications and receives information about the user and provides it to the application for authorization decisions.
Shibboleth Identity Provider – the “home” for the user, which allows the user to authenticate and sends information about the user to the Service Provider.
Shibboleth Discovery Service – allows the user to select where they are from (“home”).
As mentioned previously, there are two versions of SAML – versions 1 and 2. Shibboleth 2 uses SAML 2 which allows the Identity Provider to send all of the information the Shibboleth Provider needs for authorization right after authentication. Shibboleth 1, which uses SAML 1 which requires more communication between the Identity and Service Provider to obtain the authorization information (see the next slide).

9. How it works (Shibboleth 1.3)
Here’s the Shibboleth 1.3 version. It has the same components as Shibboleth 2 (Service Provider, Identity Provider, Discovery Service), but the difference is that the process of providing the application the information it needs to authorize the user happens in three steps, rather than one:
After the user authenticates, the Identity Provider tells the Shibboleth Service Provider that the user has successfully authenticated.
The Service Provider then asks the Identity Provider for the information it needs for authorization.
The Identity Provider then sends the information that the Shibboleth Service Provider asked for.
Shibboleth 2 is compatible with Shibboleth 1 components, so a Shibboleth 2 IdP can communicate with a Shibboleth 1 Service Provider (and vice-versa). Some federations only allow Shibboleth 1 style of communication, such as InCommon.

10. How it works (Demo)
Now we’re going to show you this process in action…

11. Shibboleth Identity Provider (IdP)
Java Servlet application
Runs in any Java Servlet 2.4 container
Does not contain attributes or logins
Connects to authoritative sources
The Shibboleth Identity Provider is a Java servlet application that runs in any Java servlet 2.4 container. It has been extensively tested on Apache Tomcat (5.5 and 6) and to a limited degree, others.
The Identity Provider does not actually contain the logins or attributes about users, but simply connects to the sources that do.

12. What uses Shibboleth? Microsoft Dreamspark Apple iTunesU
Elsevier ScienceDirect
ExLibris MetaLib
Google Apps
. . .lots more. . .
A lot of applications are compatible with Shibboleth. A few are listed here, but a more complete list can be found at:

13. Federations
Trusted communities with common user bases and applications
Can provide metadata, rules, auditing, advertising of services, etc.
Not required for Shibboleth
Federations are trusted communities with common user bases and applications. Federations provide services, such as the centralization of metadata management, common rules and auditing, and advertising of services. Though they can provide a lot of benefits, federations are not required to implement Shibboleth.

14. Federation for CHECO TBD
At the CSU we have a need for reduced signon for resources hosted at local campuses, at other campuses and externally (such as library databases). Shibboleth can provide a technical solution to allow reduced signon to all of these services, but each campus would have to separately negotiate with all of the different entities, as well as manage metadata to enable federated identity.