Merging local Brightspace accounts with SSO accounts

Hugh.P.4150

We’re facing regarding transitioning our current platform users (who have native Brightspace accounts) to an SSO-based login. Some of our existing users won’t/don’t have accounts in the CRM we use for our SSO and I would like to understand our options for how we can handle these users going forward.

If we bulk-update the users who currently don't use the SSO with their Org Defined ID, will they automatically be able to login with the SSO?
Also, has anyone got any best-practice recommendations for how to handle existing users who don't won't create an account in the system we use to admin our SSO?

Matt.W.287

Hi Hugh

When setting up SSO the login page is typically redirected to the Authentication Host so local users won't have an opportunity to log in without some sort of intervention. The most common way is to either add /local to the login address (which only works if you've had that configured) or to add ?noredirect=1

I do the latter routinely to use my admin accounts on client systems.
i.e.: https://something.brightspace.com?noredirect=1

For users that you are transitioning from local logins to SSO logins, updating the OrgDefinedId will have immediate effect (presuming your SAML config uses that value in Brightspace to look up matching users). Those users' login passwords in Brightspace will still work as long as the passwords were not updated over time if they likewise add ?noredirect=1 to the URL when logging in.

Federated Authentication creates credentials on the trusted host and then passes the session back to Brightspace where the credentials are recognized and a parameter (the SIS ID value) is searched in Brightspace for a matching number. Then the inbound user is allowed into Brightspace using that matching account.

I hope that's helpful
Best,
Matt
Learning Administration Manager