Delegated Authentication
Redirected page: We have decided that "Delegated Authentication" is not the best name for this page, so we've renamed it to IdP Proxying and included the content below.
You may wish to replace the link you followed to this page with https://www.ukfederation.org.uk/content/Documents/ProxyingIdP
IdP Proxying
Universities and Colleges operating within the UK federation often have multiple Identity Providers within their organisations, and we are frequently asked about the Inter-operability of SAML Identity Provider (IdP) products such as Microsoft Azure, Microsoft AD FS (Active Directory Federation Services) and Net IQ Access Manager (NAM).
Unfortunately, many of these IdPs cannot inter-operate within a multi-lateral mesh federation such as the UK federation (and by extension eduGAIN). Additionally, organisations may operate other single sign-on systems such as CAS (Central Authentication Service), which because they use the CAS protocol which is incompatible with the SAML protocol used within the UK federation.
As an example, Microsoft have published details of how their Entra ID (formerly AzureAD?) system cannot support SAML federations (eg the UK federation and by extension eduGAIN).
https://learn.microsoft.com/en-us/entra/architecture/multilateral-federation-introduction
There are advantages and disadvantages to IdP Proxying. These are:
Advantages
- A true single sign-on experience for your end-users
- Ability to leverage functionality available in the other IdP (e.g. within Azure, the Azure Multi-Factor Authentication solution and some aspects of conditional access), without requiring additional support within the Shibboleth IdP
- Since version 4 of the IdP such integration is now provided Natively within the IdP - this makes the process of integrating simpler than in previous versions of the IdP.
Disadvantages
- Users' loss of experience of the authentication flow at the IdP that is participating in the UK federation
- Loss of Metadata User Information (mdui) from the SP metadata, this can be mitigated by using the Consent module in the Shibboleth IdP.
- Loss of control of elements of the process such as Multi-Factor Authentication, where this would either be on or off for all federated services, based on the Other IdPs configuration.
- If you're considering dropping a local attribute resolver in favour of a directory-less IdP then you'll need to make sure that you don't use any back-channel SAML flows (which will no longer work).
Options available to organisations
- Following documentation on the Shibboleth Wiki for SAML proxying to another IdP or SAML Proxy to Azure AD, which is possible in Shibboleth IdP v4 without additional SP software. You can also use our Trust and Identity consultancy service to support you.
- Deployment following Delegated Authentication on a Shibboleth IdP guide to use RemoteUser support in the IdP (SAML Proxy described above is now preferable to this) or by using our Trust and Identity consultancy service to support you.
- OpenAthens (also part of Jisc), provide connectors within their OpenAthens hosted IdP service which can be used to provide IdP proxying functionality.
- Overt Software Solutions can provide a Shibboleth ADFS bridge, which provides similar IdP proxying functionality.
- Other third parties may also offer similar services and solutions.