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!

3

Hi @rei.el-khouri

Welcome back to the Auth0 Community!

The second approach you have mentioned would be the cleanest, most deterministic approach for bulk de-federation.

Attempting to heavily manipulate linked identities (Idea 1) at scale often leads to race conditions and complex edge cases in your downstream apps, just as your documentation warned. Auth0 users are hard-bound to their specific Connection (SAML vs. Database). There is no “change connection” button; you must create a new profile in the target database.

To answer your questions:

  1. Yes. Through the Management API, you can absolutely create a user in a Database connection with an email like user@corporate.com, even if corporate.com is mapped to an active SAML connection. However, if your login page uses Home Realm Discovery (Identifier First), Auth0 will still route user@corporate.com to the SAML IdP until you remove that domain mapping from the SAML connection settings.

  2. Yes. You can easily copy user_metadata and app_metadata. However, you cannot transfer the Auth0 user_id (it will change from saml|connection-name|id to auth0|new-id), nor can you transfer Auth0-generated analytics like created_at or last_login. Your downstream applications must be prepared to update their foreign keys to the new user_id.

  3. As I have mentioned above, no. For security and cryptographic reasons, user profiles are inextricably linked to the connection they were created in. Extraction and recreation is the only supported method.

  4. Yes. This is the most crucial part of the strategy. You should not use the standard “Create User” API in a for loop for thousands of users. You should use the Auth0 Bulk User Import feature.

Please let me know if I can help you out with the process by providing some steps/instructions or if you have other questions.

Kind Regards,
Nik