Urgent: Case Sensitivity w/ SSO

Yes, I've run into this before since as you know... these strings are different 😛 There's no Khoros admin backend setting you could apply to work around this, I'm afraid.

You can either solve it on your end and talk to your IT to have the endpoint return lower-cased email identifiers (Sounds like what you described as "B2C front") or you work with Khoros to get it lower-cased on Khoros SSO ingestion point. Latter comes probably with some Professional Service engagement + associated cost.

keithkelly Sorry to hear about the trouble you're having. We try to make it a point throughout the launch process to call out this fact, including in our SSO Kickoff call and in our documentation. Apologies if we missed the mark there. I'll circle back with our team to see where we might have room for improvement in how we communicate this.

The reason we handle the SSO ID as case sensitive is to align with the standards of the protocols we support. For example, the SAML "NameID" is expected to be case-sensitive per the spec, as is Open ID Connect's "sub" value. If we did not align with these standards, then it could create a scenario where one user could log in to another user's account, which would not be good either!

As a side note, we generally discourage the use of e-mail address for the SSO ID, since it is not uncommon for people to change their e-mail address for various reasons (marriage, changing companies, changing email providers, just because, etc.) and one of the requirements of the SSO ID is that it must be immutable. If you do not already have some kind of immutable, unique identifier for each user, the best practice would be to generate and store one, like a GUID.

It's worth noting that while we do not have a config to disable case sensitivity, we do have a backend config that allows us to transform SSO IDs to either all lower case or all upper case. So if you could apply a similar transformation on your IDP side, that might help solve the problem going forward. However, we would still need to account for existing users (i.e. update them all to lower-case), and if you're going to that length, it would be better to replace the SSO IDs with GUIDs if possible.

It sounds like you have experience with scripting for our APIs, so this is potentially something you could self-service. You'd just want to make sure to temporarily prevent SSO logins while you're running the script, to avoid data inconsistency issues. And as Claudius suggested, our Professional Services can also assist with these types of scripts if you'd prefer to work with us via a project.

I hope this helps!

Great, AdamN  thanks for the details and insight. 

With your backend config change, do we even need to do the same on our IDP side? 

Or can you flip the switch, then I run the API calls to lowercase existing user SSO IDs & we call it a day?

keithkelly Ah, you're right. You wouldn't need to update the SSO IDs in the IDP, just the existing ones in Community. 

Great, what's the best way to coordinate this change?

I need to do some testing on my endpoint first & form a plan for my duplicate users.  

keithkelly I gave our Support team a heads up on the necessary backend change, so if you'd like to continue your discussion in the existing Support case, they should be able to help coordinate next steps.

If you weren't already planning to, I'd suggest testing against stage first where possible to confirm expected behavior for existing and new accounts.