I'm dealing with a tricky situation regarding SSO (Single Sign-On) applications in our organization. We have several SSO apps up and running without a hitch, but one department insisted on setting up a separate primary SMTP alias for a specific group of users, which has caused some issues.
To illustrate, take John Smith as an example: he has a User Principal Name (UPN) of [email protected] but has been assigned a primary SMTP alias of [email protected], along with a secondary alias of [email protected].
Now, the problem is these users are unable to access SSO apps because some of these applications only utilize the primary SMTP alias for authentication and not the UPN.
Isn't it the case that the support for the UPN versus the primary alias really depends on the vendor or service provider? This isn't something we can manipulate on the Identity Provider (IdP) side, right? I think our next move should involve reaching out to the vendor to see if their application supports UPN for SSO authentication. I've been told that we have no leeway in how these users need to be configured on our IdP, which makes it all the more frustrating.
1 Answer
You might want to check the SSO settings in your configuration. In Entra ID, for instance, there's a section where you can set SAML attributes and claims.
It’s possible you could specify the UPN instead of the primary email for the unique user identifier. If that's the case, it could solve the issue for the SAML-based SSO apps you're using!
Yeah, I'm also using Entra ID and I noticed that option too! If changing the identifier to the UPN works, it would definitely help avoid these issues for those users.