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.
Glance offers a special-purpose STU for troubleshooting SAML.
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:
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 3 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 problem can occur during prototyping with temporary identity provider installations.
Expiring Assertions make it 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 often happens 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.