Azure AD: Understanding Guests and SAML-Based SSO
Introduction
If your organization needs to enable partners to access their applications, Azure AD B2B is an important feature. B2B allows your organization to host guests from other organizations and assign them access to your applications without having to manage credentials for those users. This article walks through a scenario where a guest user is assigned access to a 3rd party SAML-based SSO application that has been integrated with Azure AD.
Guest User Attributes
First, let’s look at what a guest user looks like in Azure AD. The following represent a guest user with logon name user@contoso.com This user is created as a guest in Fabrikam.com Azure AD Tenant.
ObjectID |
<GUID in host tenant> |
ObjectType |
User |
AccountEnabled |
True |
DisplayName |
User from Contoso (chosen during creation of guest) |
MailNickname |
User_contoso.com#EXT# |
OtherMails |
|
ProxyAddresses |
{smtp:user_contoso.com#EXT#@fabrikam.onmicrosoft.com,SMTP:user@contoso.com} |
RefreshTokensValidFromDateTime |
2/2/2018 12:00:00 AM |
ShowInAddressList |
False |
UserPrincipalName |
|
UserType |
Guest |
Guest user SAML Assertion
Azure AD generates persistent NameID unless otherwise specified in the SAML request. Most applications ask for user.mail or user.userprincipalname for the subject of the SAML assertion. In Azure AD application configuration, this is the User Identifier property. This value is used to uniquely identify users within the application.
Most applications use the UPN or Mail value for this identification. Since Guest users have the "weird" UPN with # characters, let's try using the Mail value instead.
When testing access using a guest user assigned to the application, we can use fiddler to view the SAML token. I used this technique I allude to but don’t walk through in this article, and assign a guest user to the sample “localhost” application. Here’s what the subject looks like in the SAML assertion:
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">tQrW_ZpzSg-dOvNapvplpC9CMrBS4F_QYwBysZjEXNLI</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2018-02-02T15:27:58.424Z" Recipient="https://localhost"/>
</SubjectConfirmation>
</Subject>
What happened? Where is the mail value and what is this random thing? Azure AD is generating a persistent unique identifier based on the application and user object IDs to create a pseudo-random value for NameID. It does this if the attribute chosen has no value.
Chances are the application isn’t expecting this value, and sign-in will fail. This presents a problem if the application really needs Mail value for all users. So how do we get the right value for guests and users in my tenant? Let's try using user.userprincipalname for the User Identifier.
And here's the resulting Subject for the SAML assertion using user.userprincipalname for the User Identifier.
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@contoso.com</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2018-02-02T15:24:18.845Z" Recipient="https://localhost"/>
</SubjectConfirmation>
</Subject>
To quote the great glennz: "Now we're cooking with fire!"
When user.userprincipalname is chosen for the User Identifier, AAD knows to use the mail value if the user UserType is Guest
Takeaway
First, make sure you test integration with a lab environment or “fake” app to understand how Azure AD will craft SAML tokens. There are some nifty tricks it uses to make integration easier, but some of them may surprise you.
Second, this demonstrates how critical mail and UPN alignment is for users in your organization. Scenarios where Azure AD B2B collaboration is used to assign guest users to your applications, may break down, or the application owners will need to take special care in populating profiles in the application identity store.
References
What is Azure AD B2B Collaboration?