SAML Troubleshooting

Tools

You may find it convenient to install some Web Extensions into your Google Chrome browser or Microsoft Edge (Version 85 and above) when you are troubleshooting SAML.

The SAML Message Decoder extension captures and displays SAML documents handled by your browser.

The Edit this Cookie extension allows you to view, delete, and edit the cookies sent by various web sites to your browser.

The Glance Browser Extensions help integrate your use of SAML with CRMs like Salesforce.

Logging

When you first provision SAML, set the Operational Status to Provisioning. When you do that, a Glance staff member can look at the Access Log and see SAML operations, both successful and failed.

Troubleshooting STU

Glance offers a special-purpose service target URL (STU) for troubleshooting SAML.

https://www.glance.net/account/GetLoginKey.aspx?sso=1&test=11&idpid=EXAMPLE

If you use this STU you should see a page containing diagnostic information. Glance Customer Success can use this diagnostic information to figure out problems.

Problems with Redirection

A user trying to authenticate with SAML may see a text document looking something like this:

partnerid=999999&partneruserid=xyz~$1$1540313487$kAXFh9Az665ZTYt8wq48AOJpwXT

This is a Glance Login Key. If the user did not expect to get a login key, but rather some page within www.glance.net, check whether the STU is correct. If the user did not use an STU, but rather came in via an identity provider initiated session, check the value of Redirect for IdP-initiated Sessions.

Time and Clock Synchronization Problems

SAML Assertion tokens expire. It is important that your identity provider server's time-of-day clock is synchronized to a stratum 4 or better time server. At Glance, we synchronize our server time-of-day clocks to pool.ntp.org, which is in turn synchronized to the stratum 1 time service at the US National Institute of Standards and Technology. If the timestamp in an Assertion doesn't match the time on our server, the SAML specification calls for us to reject it, and we do. (Timestamps are all in UTC, rather than any particular time zone.)

This kind of clock problem can occur during prototyping with temporary identity provider installations.

We reject expiring Assertions. Rejecting them makes it more difficult for cybercriminals to use so-called replay attacks to gain access to services where they do not belong.

Users Not Found

Often, during initial provisioning, your identity provider sends us SAML assertions matching no users in Glance's system, so SSO logins fail. Mismatches like this can be for several reasons:

• The User Identity Attribute Name is set incorrectly on our provisioning screen.
• Your identity provider is not configured to send the correct attribute.
• The users you send us are not yet provisioned in our system.
• The users you send us have not yet had Partner UIDs assigned to them.
• The users you send us have Partner UIDs that don't match your identity provider's user identification. This can happen with badge numbers (employee numbers). For example, consider a user with badge number "00144616." The identity provider might strip the leading zeros and send "144616" to us in the Badge attribute when the Partner UID for that user in our system is "00144616." These two versions of the same number do not match.

Examining the output of the troubleshooting STU can help identify these user mismatch issues. So can looking at the Access Log.