Metadata Archive

Configuring Microsoft Entra ID (Azure) SAML-based SSO for SAFIRE

Microsoft recommends integrating Entra ID into SAFIRE via a SAML Proxy such as Shibboleth, which mirror’s the R&E federation communty’s guidence. While it is possible to connect Microsoft Entra ID directly into SAFIRE, this has several caveats and cannot be guaranteed as a long-term solution. This documentation assumes that you already have an Microsoft Entra ID tenant correctly configured and provisioned with your institution’s user accounts. To configure Microsoft Entra ID as an identity provider for SAFIRE, you need to configure SAML-based SSO. Doing so requires you do three things:

Configuring SimpleSAMLphp to use Entra ID (Azure AD)

This documentation will guide you through the Microsoft Entra ID (Azure AD) configuration process as an authentication source in SimpleSAMLphp. By integrating Entra ID in this way, you can retain your users’ familiar login experience while leveraging SimpleSAMLphp’s flexibility to fetch and/or manipulate attributes from Entra ID and other sources. While SAFIRE can directly work with Entra ID or SimpleSAMLphp (as explained in our Configuring Entra ID SAML-based SSO for SAFIRE and Configuring SimpleSAMLphp for SAFIRE documentation), you may find yourself in a situation where this approach better fits your use case.

Configuring SimpleSAMLphp for SAFIRE

SimpleSAMLphp has good documentation, and so this is not a complete/worked example of how to configure it. Instead this provides the SAFIRE-specific snippets you may need when working through that documentation. Configuring metarefresh to fetch SAFIRE metadata You should use the metarefresh and cron modules to manage SAFIRE’s metadata automatically. SimpleSAMLphp provides documentation on automated metadata management which explains the basics of how you set this up. This document assumes you have a working cron module and have installed and enabled metarefresh.

Performing a SAML certificate or key roll-over

This is a recipe for rolling over (changing) your SAML signing certificate and the associated private key without a service affecting outage. NB! You should be aware that this process is NOT instantaneous, and requires proper planning to ensure your users can continue using your provider without incident. Therefore, you need to begin the process well before the expiry of your existing SAML signing certificate (plan for at least a week). If you let your certificate expire, your users may not be able to log in, and it will take some time to recover from this.

Configuring ADFS for SAFIRE

Note: While it is possible to use ADFS with SAFIRE, it has known interoperatability problems with the sort of multi-party federation used in the R&E world. SAFIRE’s architecture shields you from some of these effects, but you do sacrifice some flexibility and control. In order to configure Active Directory Federation Services (ADFS) as an identity provider for SAFIRE, you need to do four things: Create a Relying Party Trust that fetches the federation hub’s metadata from https://metadata.safire.ac.za/safire-hub-metadata.xml Configure claim rules to map AD LDAP attributes to SAFIRE’s attributes Configure a claim rule to generate eduPersonAffiliation from some internal role mapping Configure a claim rule to generate a transient NameID and then map this internal claim as a Name ID of type urn:oasis:names:tc:SAML:2.0:nameid-format:transient Scripted configuration Ensure you make adequate backups before executing any script from this site

Configuring Google Workspace (G Suite) as an IdP for SAFIRE

As a result of the baseline changes that occured in march 2021, it is no longer possible to directly integrate Google Workspace (G Suite) with SAFIRE without making schema changes. In particular, you would need to add support for the displayName and eduPersonScopedAffiliation attributes. As no current providers use Google Workspace, his document has not been updated to incorporate information on how to do that, nor has it been tested. It remains theoretically possible to integrate Google Workspace.

Configuring Shibboleth Service Provider for SAFIRE

The Shibboleth Service Provider has good documentation, and so this is not a complete/worked example of how to configure it. Instead, this provides the SAFIRE-specific snippets you may need when working through that documentation. Installing Shibboleth Service Provider Note that some package repositories ship out-of-date and vulnerable versions of the Shibboleth SP. However, the Swiss federation operator (SWITCHaai) maintains up-to-date packages for Debian and Ubuntu.

End of SAFIRE transition period

At 00:00 SAST on 1 August 2017, the remaining entities in the old metadata aggregate at https://discservice.sanren.ac.za/safire.xml will expire. Any provider who still has mention of the above URL in their configuration should remove it, as it will not be supported beyond the end of the month.

Monitoring of Identity Providers

As a courtesy, we monitor the reachability of the various South African identity providers and make that information available at monitor.safire.ac.za. The monitoring system initiates a single sign-on request, and reports the outcome as follow: Green means that we completed all the tests and found something that looked like a login page. Yellow means that we got as far as what we think should be a login page, but didn’t find a username field on it. The institution’s own monitoring or I.T. help desk may be able to provide more information. Red means that we weren’t able to contact the identity provider for some reason. This could be because there’s a network problem or that the there’s some problem with the identity provider (service not running, certificates expired, metadata expired, etc). The monitoring output shows the hosts we passed through on the way to what we believe is the login page. It may also give details of any problem(s) that were encountered.

South African Identity Federation