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!
