Hiya

I am setting up shibboleth support on a clients Drupal installation.

They are integrating with The UK Federation http://www.ukfederation.org.uk/

From my understanding the UK federation are the ones running the IDP server. I am pretty green on the shibboleth front. Is it possible to chain an IDP server to a parent IDP server ie: Uk federation?

Comments

spotzero’s picture

spotzero commented
Status: Active » Closed (works as designed)

The federation does not run an IdP and IdPs are not chainable.

A federations is just an administrative organisation that compiles a list of metadata (keys and urls) of all of the IdPs and SPs that are members of that federations. They make the list available to their member, and then all of the IdPs and SPs in the federation can download it and trust each other.

What federations also can do is run a discovery service (which is chain-able.) Here's an example of what a discovery service is for:

First, let start with a basic Shibboleth workflow:

  1. User tries to use a service
  2. SP on that service forwards them to their trusted IdP
  3. User logs in on the IdP
  4. IdP forward the user back to the SP with an authorization token.
  5. SP validates the authorization token and the user is logged in to the service.

When an SP is part of a federation, it trusts multiple IdPs (at least every single IdP listed in the federation), so the SP wouldn't know where to forward the user in step 2.

To help with this case, federations can run a discovery service (https://wiki.shibboleth.net/confluence/display/SHIB2/DiscoveryService).

A discovery service is essentially an app that generates a single page with a select box on it listing all of the IdPs in the federation, and it asks the user which IdP they'd like to use to login. So the workflow becomes:

  1. User tries to use a service
  2. SP on that service forwards them to the federation's discovery service
  3. The user selects their institution, and the discovery service forwards them to the IdP for that institution.
  4. User logs in on the IdP
  5. IdP forward the user back to the SP with an authorization token.
  6. SP validates the authorization token and the user is logged in to the service.

Discovery services can be chained, which is useful in cases where an SPs is a member of more than one federation. Increasing the workflow to:

  1. User tries to use a service
  2. SP on that service forwards them to the service's discovery service
  3. User selects their home federation, and the service's discovery service forwards them to that federation's discovery service
  4. The user selects their institution, and the federation's discovery service forwards them to the IdP for that institution.
  5. User logs in on the IdP
  6. IdP forward the user back to the SP with an authorization token.
  7. SP validates the authorization token and the user is logged in to the service.

Hopefully, that clears up the roles of the federations and how thing tickle down to the IdP.

Are you sure you're not looking for this module: Shibboleth authentication. That module allows user's to log into Drupal via Shibboleth (lets your Drupal site be a Shibboleth service).

This module provides an alternate authentication handler for Shibboleth IdPs that lets a Drupal site be the authentication source (i.e. You'd use this module with your users where stored in Drupal instead of an LDAP) or use lets the IdP use Drupal as the session source (so your Shibboleth IdP session is actually controlled by the Drupal site.)

mikejuic3’s picture

mikejuic3 commented

Hiya

Thanks for the advice. Will run through it with my fine tooth comb. I have looked at the Shibboleth Authentication module but it requires SP to be on the same server as the Drupal installation. The VPS in question uses Serverpilot for patch management and monitoring and as such it's a bit complicated to get Shibboleth installed on the same box. I am looking into simpleSAML as it seems like it may be a good fit.