This how-to applies to Shibboleth Identity Provider v4.0 and can be used to integrate the authentication flows with other SAML2 compliant identity providers such as SimpleSAMLphp or Microsoft Azure. There is a far more detailed guide to integrating with Azure at Using SAML Proxying in the Shibboleth IdP to connect with Azure AD.
Please read and follow the documentation first, before or along with using this example. This documentation is not maintained by the development team and may not be entirely accurate or consistent with the software at any given time. It is a complement to the documentation, not a replacement for it. It is currently out of date with respect to some improvements made in V4.1.
Delegating Authentication to another IdP
This process will absolve your Identity Provider (IdP) of the process of authenticating the user, instead relying on another SAML2 IdP to do that job. The resulting Assertion is used to generate the user's local username which is then used in the standard Attribute Resolution process.
In essence, your IdP well become a Service Provider (SP) to a second IdP.
This method describes extracting the username from an Attribute in the Assertion. It's also possible to use the Subject.
In this example, the following entities and attributes are in use:
Original IdP EntityID: https://idp.example.ac.uk/entity
Look through list of AttributesToResolve in the resolver and resolve each one.
Look through list of resulting attributes in AttributeSourceIds and pick first valid one to be the principal's name to then be used later
Resulting trusted real username used as $resolutionContext.principal (eg. existing LDAP data connector, etc.) during "standard" attribute resolution process
A working Identity Provider at V4 or above
A SAML2 compliant Identity Provider to delegate to
A suitable attribute available to both IdPs to use as a "joining" attribute (so the other IdP can provide a value which can be looked up in the main IdP's connected data source)
Update your IdP's metadata
As your IdP will need act as an SP, you'll need extra blocks in your entity's metadata. Create a new sp-metadata.xml (or update your existing idp-metadata.xml but consider whether this should be included in multi-lateral federation agreements) file to include a <SPSSODescriptor> block. You'll need to copy the signing and encryption certificates from the IdP part of the metadata and replace the base URI (https://idp.example.ac.uk/idp) with the base of your IdP.
If your upstream IdP is not already known by some other means, then register the upstream IdP, too. This is handled just like any other metadata and can be included in your metadata-providers.xml as a new <MetadataProvider> block. For example:
This workflow takes the incoming assertion and extracts some data from it to work out the canonical (authoritative) username of the authenticated user. In this very simple case we're using uid (unscoped username).
Add a new <AttributeDefinition> to the attribute-resolver.xml which will transform the uid attribute from the Subject (the filtered data from the incoming assertion) into a proxied-uid attribute for use elsewhere:
With the Subject, configure which attributes to fire in the resolver to work out what's going on. Set AttributesToResolve in c14n/attribute-sourced-subject-c14n-config.xml to the id of the new <AttributeDefinition>: