SSO issue

I have followed all the steps to get the SSO my organization-sso-slug, but it keeps loping the SAML token to a new token request every time.

would you please help me out in finding a fix, as from the Azure MS side it says it was able successfully to issue a SAML token, and the issue is on the App side?

thnx

Hi,
I looked into your account and it seems the format of the certicate fingerprint is wrong.
It seems, you pasted the whole certificate, but you should only enter the fingerprint.
Kind regards
Philipp

Thanks Philipp for looking into this issue.
Unfortunately, this is not the issue/RC here, as I have tried before without the whole cert, and it did that same, that is why I tried the whole cert.

anyway, I have left only the cert fingerprint, and it is still causing the same loop.

please check it again

thanks a lot.

Hi, maybe we can schedule a debug meeting next week?
Please contact me at philipp@pollunit.com

Hi Philipp,
thanks for your help, you may close this case.

thanks,

Great!
Have a nice day!

What was the solution?

Hi James,

The cause was on our side, not in the customer's configuration. In March 2022 we deployed a fix to our SAML integration:

• User lookup: PollUnit used to match the SAML user by the NameID (subject). If the NameID from the identity provider wasn't the user's email address, the user couldn't be matched and login ended in a redirect loop. PollUnit now finds users by the email attribute from your attribute mapping.
• Saving SSO settings: One SSO setting (the authentication context used for Azure AD) wasn't being saved correctly. That's fixed too.

If you have a similar problem, please check:

1. Your IdP sends an email attribute, and it's mapped to the email field in PollUnit's SSO settings. Use the exact »Name« value from the AttributeStatement in the SAML response.
2. The IdP certificate fingerprint matches the certificate your IdP currently uses for signing.

If it still doesn't work, let me know!

Kind regards,
Philipp

Hey Phillip, we are still running into this redirect loop. We use Entra ID (previously Azure AD) as our IDP.

We used the default attribute names in the "SAML attribute mapping" field. We did not change them. They are as follows:
{
"urn:mace:dir:attribute-def:email": "email",
"urn:mace:dir:attribute-def:name": "lastname",
"urn:mace:dir:attribute-def:givenName": "firstname"
}

For the urn:mace:dir:attribute-def:email claim we are sending the user.mail attribute (e.g. jdoe@test.com)
For the urn:mace:dir:attribute-def:name claim we are sending user.surname (e.g. Doe)
For the urn:mace:dir:attribute-def:givenName claim we are sending user.givenname (e.g. Jane)

Do you have any additional insight you can provide?

Hi James,
thanks for the details – your attribute mapping looks correct. A wrong mapping would show an explicit error message on our login page rather than a loop, so the problem is likely elsewhere. To narrow it down, could you tell us:

• In Entra, please double-check that the Identifier (Entity ID) is https://pollunit.com/saml/metadata and the Reply URL (ACS) is https://pollunit.com/users/saml/auth?sso=<your-sso-slug>, and that the "IDP Entity ID" in PollUnit exactly matches the "Microsoft Entra Identifier" (https://sts.windows.net/<tenant-id>/, including the trailing slash).
• If possible, a SAML-tracer or browser HAR capture of one loop, or at least an approximate timestamp, so we can correlate it with our server logs.

Philipp

Hey Phillip, I have just emailed you with our SAML-tracer capture. Feel free to reply to that email with any additional insight or questions you may have.

Just for future readers: The issue was on our side and is fixed now. Thank you for helping investigate!

It works now. Thank you!

Great!