Three things you should know about SAML

When you are planning to configure single sign on some applications with Azure AD, first of all you have to ask application team whether the target application can "speak" federation protocol such as SAML or OpenID Connect. Of course also ws-federation is good protocol as you know:)

Today, I explain you top three things you should know at least when you choose SAML protocol to federate some applications with Azure AD.

1. Entity id and endpoints

To enable SSO, both of the identity provider(IdP) like Azure AD and the service provider(SP. i.e. application) like Google Apps are required to know each other. "Entity id" is the identifier to specify each entities(IdP and SP) and IdP have to know SP's entity id to specify SSO target application, and SP have to know IdP's entity id to specify where user was authenticated.

It is often misunderstood but entity id is not required to be uri format so that it is not required to be reached on the internet. For example, G Suite(a.k.a. Google Apps)'s entity id is "google.com/a/domainname", not "https://google.com/a/domainame".

Also IdP and SP have to know endpoint addresses to contact to the other party. There are several endpoints to be used while finishing SSO process and at least you should to know following two endpoints.

party	endpoint type	description	sample value
IdP	SingleSignOnService	endpoint to send authentication request from SP	https://login.windows.net/{tenant id}/saml2
SP	AssertionConsumerService	endpoint to send authentication result(SAML assertion) from IdP	https://www.google.com/a/{domain name}/acs

figure 1. SSO setting on Azure AD(IdP)

figure 2. SSO setting on G Suite(SP) * In case of G Suite, IdP's entity id is not required.

2. Certificate for token signing

To finishing SSO process, user-agent(i.e. Web browser) have to POST identity information(SAML Assertion) including authentication result to SP's assertion consumer service endpoint. To avoid identity spoofing, SP verifies SAML Assertion which is received from IdP. To verify the assertion SP uses public key certificate which is paired with private key which IdP uses to sign the SAML Assertion.

Usually during configuring SSO on IdP side, you can create and download token(i.e. SAML Assertion) signing certificate and upload the certificate to SP.

figure 3. Create and download signing certificate from Azure AD(IdP).

figure 4. Upload token signing certificate to G Suite(SP).

3. name id and attributes

"Identity federation" means "To link users between IdP and SP", so to complete SSO process, it is required to determine how to link users both parties. Usually name id element's value in SAML Assertion is used to link users. For example, G Suite requires name id value in SAML Assertion matches email address value of the user to be signed in.

In case of identifier in IdP does not match with SP's identifier, you have to put SP's identifier value to some attribute of the user in IdP. For example, identifier of G Suite is user@example.com and identifier(userPrincipalName) of Azure AD is user@example.net, administrator have to put the value "user@example.com" on mail attribute of user@example.net on Azure AD.

figure 5. Attribute mapping for name id.

Conclusion

SAML is very popular protocol to enable SSO especially for enterprise applications. But there are some tricks to configure successfully and doing trouble shooting. In fact, some one said that 99% of failure while configuring SAML SSO are caused by typo of entity id or endpoints, e.g. a lack of last '/' of entity id causes connection problem. So it is important to know basic structures and components of SAML protocol to configure SSO successfully.

Cheers,
Naohiro