This how-to applies to Shibboleth Identity Provider v4 and above .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 V4 Shibboleth IdP to connect with Azure AD.
| Note |
|---|
| Note: this is quite a new process and the use of terminology in the document may vary between organisations or SAML2 implementations. Please feel free to clarify or improve on the wording! 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. |
| Table of Contents |
|---|
Delegating Authentication to another IdP
...
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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<EntityDescriptor entityID="https://idp.example.ac.uk/entity" ...>
<!-- Already present IdP data -->
<IDPSSODescriptor ...> ...
</IDPSSODescriptor>
<AttributeAuthorityDescriptor>
...
</AttributeAuthorityDescriptor>
<!-- New SP block -->
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
...Signing Certificate from IdP...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="encryption">
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
...Encryption Certificate from IdP...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.example.ac.uk/idp/profile/Authn/SAML2/POST/SSO" index="0"/>
</SPSSODescriptor>
</EntityDescriptor> |
...
Set the AttributeSourceIds value to which newly resolved attributes you would treat as the real username. This is probably the same or a subset of AttributesToResolve.
Review c14n/subject-c14n.xml and ensure the PostLoginSubjectCanonicalizationFlow bean has been uncommented.
At this point you should have a valid locally understood username to pass into the "normal" resolver that already works, which is now available from places like:
...