Azure AD Authentication

With Azure AD authentication an organisation can configure users with specific domains for authentication with SWITCH edu-ID when accessing Microsoft Online Services.

When entering the Email for login, the domain is analysed and, according to the settings of the organisation owning this domain, the user authenticates either against the Azure AD or is redirected to an external login page, in this case the SWITCH edu-ID login page. The organisation can manage the domains in their tenant each separately, allowing for example to authenticate only a subset of their domains via edu-ID. Note that the authentication of a subdomain is usually bound to the one of its parent domain. Contact us for more detailed information and the prerequisites to separately handle subdomains.

Authentication Flow

When entering the email for login, the domain/realm is discovered and, according to the settings of the organisation owning this domain, the user authenticates either against the Azure AD or is redirected to an external identity provider (IdP), i.e. SWITCH edu-ID. The organisation can manage the domains in their tenant each separately, allowing for example to authenticate only a subset of their domains via edu-ID.

aad-auth-overview

A user wants to access an Azure AD resource (i.e. Office365).
The user must use as username an email address of the organization that owns the tenant.
Based on the domain part of the username, the tenant is selected and the user is redirected to the edu-ID IdP for authentication
The user authenticates with any edu-ID supported authentication mechanism, and is then redirected to the desired resource. The attributes ImmutableID and UserPrincipalName are passed to the resource to identify the user.

Service Description

With the chosen solution architecture using SAML Proxies, it is possible to let users authenticate via SWITCH edu-ID for Microsoft Online Services. In addition, also multiple domains can be configured to be eventually redirected to the same IdP, which Microsoft by default has no mechanism for. The user-centric Single Sign On (SSO) approach of edu-ID allows students to require only edu-ID credentials for all authentication.

SWITCH offers a straightforward guidance for the changeover to the federated authentication with edu-ID, providing ready-to-use commands for the configuration in the Powershell.

Prerequisites

General requirements

Organizations must have introduced SWITCH edu-ID.
All Azure AD enabled accounts must have been provisioned in the Azure AD tenant beforehand. This can be accomplished with Azure AD Connect, Graph API, Powershell or other means.
Two attributes, ImmutableID and UserPrincipalName, must have been provisioned in the SWITCH edu-ID accounts of all users (see below for details).
The primary domain of a tenant is restricted to managed authentication and can not be federated to the SWITCH edu-ID. We therefore recommend to keep the “@<tenant name>.onmicrosoft.com” domain as primary domain of the tenant.
The global administrator account of the given Azure AD tenant must have an email domain which is not authenticated with the edu-ID. We recommend to use an account with the domain “@<tenant name>.onmicrosoft.com” with managed authentication against the Azure AD.
Why is this needed?
If there is a problem with the federated authentication, you could permanently be locked out of your tenant using only federated domains. It is important to have a fallback option. Contact us for more information.

Attribute Synchronization

The following two attributes need to be provided by an organisation (Attribute Provider) either via Push (Affiliation API) or Pull (Attribute Provider API) for each Azure AD enabled user account.

Attribute Name	Value	Comments
extAzureADImmutableID urn:oid:2.16.756.1.2.5.1.1.2013	ImmutableID matching the user object in Azure AD	For organisations using AD and Azure AD Connect: The values must be those that Azure AD Connect uses as `sourceAnchor`. By default, Azure AD Connect stores these values in the Active Directory attribute „ms-DS-ConsistencyGuid“. In this case, the ImmutableID is the base64 encoded value of „ms-DS-ConsistencyGuid“. For organisations not using AD/Azure AD Connect: The organisations must create suitable values for each Azure AD enabled account and store these values appropriately in their identity management system or user directory (e.g. OpenLDAP). The values must be supplied as part of the affiliations synchronised to the SWITCH edu-ID. Furthermore, the organiations must synchronise these values with their Azure AD tenant in a suitable way (e.g. via the Graph API or using PowerShell). (The synchronisation to Azure AD is not part of the SWITCH edu-ID service.) The value must be provided in the format as the PowerShell command „get-msoluser“ returns the attribute „ImmutableID“. Additional information: Azure AD Connect: Design concepts
userPrincipalname urn:oid:1.2.840.113556.1.4.656	UserPrincipalName matching the user object in Azure AD	For organisations using AD: These values can directly be taken from the Active Directory attribute „userPrincipalName“. For organisations not using AD: Since the „UserPrincipalName“ values should correspond to the users' e-mail-addresses per convention, organisations can usually directly use the users' existing primary e-mail addresses as values. Alternatively, they can store the „UserPrincipalname“ as separate attribute in their identity management system or user directory (e.g. OpenLDAP), which might be an advantage in certain cases. Additional information: Active Directory User-Principal-Name attribute

These attributes are supported by the following SWITCH edu-ID components:

Affiliation API: The Affiliation API supports these two attributes in the SCIM scheme urn:mace:switch.ch:eduid:scim:1.0:affiliation with the names extAzureADImmutableID and userPrincipalName.
Attribute Provider API: An implementation of the Attribute Provider API must provide these two attributes with the names extAzureADImmutableID and userPrincipalname.

Azure AD synchronization

When the prerequisites are met, the last step is to adjust the authentication settings for your Azure AD tenant using Powershell. This step is guided by SWITCH, providing a set of commands to safely accomplish the changeover.

The flow of the SAML request when a user logs on to a Microsoft Online Service. The flow depends on the domain part of the username and eventually ends up at the SWITCH edu-ID IdP. After successful authentication, a SAML assertion containing userPrincipalName and extAzureADImmutableID is sent back to the requesting service via the same way.

Each proxy consists of two instances, running in docker containers on different machines. In front of them, there is a Load Balancer which ensures the traffic is evenly divided and in case of outage of one instance, only the healthy one is used.

Speaking of healthiness, SWITCH monitors the proxies, regularly doing automated health checks with alerting when failing, and extracting various metrics and Logs in order to keep track of their status.