Skip to content Skip to site navigation Skip to service navigation

Shibboleth Infrastructure Interaction Sequence

In this presentation, we will trace through the interactions that take place when a Stanford affiliate accesses a Shib-protected resource. We assume that the affiliate does not already have a Shibboleth session started.

  1. User goes to access a Shib-protected website.
  2. Since this user does not have a Shib-session established, the service provider redirects the user's browser to the Where-Are-You-From service, provided by the federation of which the service provider is a member.
  3. When the user selects Stanford as their organization of affiliation, the WAYF then redirects the user's browser to Stanford's Identity Provider Single Sign-On Service, which is WebAuth protected.
  4. If the user does not have a WebAuth session established, WebAuth will redirect the user to the WebLogin page where they can enter their username and password.
  5. The username and password is verified with Kerberos v5. If correct, a WebAuth session is established.
  6. WebAuth redirects the user's browser back to the SSO Service, which was the original request that it had blocked due to lack of a WebAuth session. This time, the access is permitted.
  7. The SSO Service assigns a handle (which is a way of identifying this Shibboleth-session) and redirects the user's browser back to the Service Provider.
  8. The Service Provider sees that a handle exists with this request. It directly contacts the Attribute Authority, presenting the handle, to get information about the user.
  9. The AA pulls attributes (such as affiliation) out of LDAP and targeted ID out of MySQL and returns those attributes requested by the Service Provider and permitted by the Attribute Release Policy.
  10. If the value expected by the Service Provider is returned from the Attribute Authority, the Service Provider grants access to the user.
Last modified January 5, 2021