Migrating accounts with Enterprise SAML connections to database connections

Get Help
,
1

Hey there!

We are looking at setting up federation via Enterprise SAML connections for some of our clients, but one of the cases that is causing us to scratch our heads a bit is how best to handle migrating federated users that were migrated to (or created with) the SAML connection back to unfederated database connections if the client wishes to no longer use their identity provider with us.

I am picking this work up in the middle, so I am mostly trying to get my bearings on what I am working on and making sure that what I have is the best options we have available to work with before continuing the work on it for context.

For the federation migration, we are linking the database connection accounts to the new federated accounts, and new users do not get database connection accounts if made after this migration I believe.

We have two ideas in mind currently, but we don’t know if there is a better way about this either. I am not super adept at Auth0 but I have a bit of an idea what is going on also for context.

  1. Create new primary user with database connection, copy roles and metadata, link the old identity as secondary. In the document I am referencing we have “The main risk is that linked identities can introduce edge cases in application logic if downstream systems assume a single stable identity without considering linked profiles.”
  2. Create a new target user, copy roles and metadata, and delete the old user. in the document I am referencing we have “This option results in a simpler end state and reduces ambiguity, but it requires high confidence that all roles, metadata, and references have been migrated correctly.”

Additionally, we want to make it so that after the move from a federated Enterprise SAML connection to unfederated database connection, all accounts under those domains will need to reset their password. The document I have says that we have two options for this as well:

  1. Send bulk email reset emails after migration
  2. Login gating preventing the user from logging in until their password is reset

Now after looking around Auth0 I am wondering if these options listed reflect how things work in Auth0, and if there is a simpler solution.

My initial idea is

  1. Make database connections for all federated user accounts that do not already have a linked connection in the database (can we verify that the accounts are not disabled by the provider as well?)
  2. Set the database connected accounts as the primary account, moving all metadata to it before unlinking
  3. Delete all federated user accounts for the domain that is being unfederated.
  4. Invalidate passwords for all users under the federated domain so they are forced to reset upon login attempt (can we inform the user their password needs to be reset instead of just an “invalid password” error)

Some questions:

Can you make database accounts for an email address when the domain for the email already is handled by an Enterprise SAML connection?

Is there any metadata or similar that can not be transferred in any way that is important?

Is there an easier way about this that I am not thinking of, like being able to just change the connection type for an account? Other things I might just be unaware of as well.

Is there a way to do this via the Management API that avoids hitting rate limit errors (either by sending everything together in one request for each step, wildcards, etc) and knowing when the request finishes executing between steps?

Any help is appreciated!