Topics tagged with migration

Importing users over time

dan — Invalid Date

I think the way I'd approach this is:

import all users into FusionAuth

At cutover time:

look at local database to see which password hashes had changed pull the user data from FusionAuth for each of these users delete the user re-import the user with the new password hash and the FusionAuth data, maintaining the same userId (if you provide the UUID, we'll use that)

I get that is an additional complexity, but hopefully that helps.

How to bulk import users with no password hash?

fusionauth.qhj5e — Invalid Date

@mark-robustelli Oh ok, I'll set the password to a UUID then and set the user to change password on login. I'll try on Monday. Thanks for the forum link.

Importing users from Fusion Auth to KeyCloak

dan — Invalid Date

@benjamin Hmmm.

I'm not quite sure what the issue is, because we do specify salted-pbkdf2-hmac-sha256-512 in the import script:

https://github.com/FusionAuth/fusionauth-import-scripts/blob/master/keycloak/import.rb#L151

The migration guide says:

"The encryptionScheme for this plugin is salted-pbkdf2-hmac-sha256-512."

So when you write:

Hello Dan, I found the fix, at least for my test instance, seems that pbkdf2-sha256 maps to salted-pbkdf2-hmac-sha256 rather than salted-pbkdf2-hmac-sha256-512.

Do you mean that pbkdf2-sha256 is the value from Keycloak and it only worked when you used salted-pbkdf2-hmac-sha256 in FusionAuth, or something else?

What version of Keycloak are you migrating from?

Migrating from mysql to postgresql

dan — Invalid Date

@sander

Thanks for the update. We're bummed that we can't include the mysql connector as part of the docker image.

If FusionAuth is stuck in maintenance mode, this thread might prove useful: https://fusionauth.io/community/forum/topic/135/can-t-get-by-maintenance-mode

Can you give me any more details about the issue?

What can I migrate from a different system

dan — Invalid Date

You can migrate all of your user data (store any non standard info in user.data), their roles, groups, application association, refresh tokens (so that someone using a TV app, for example, won't have to login again) and their password hashes.

Please see the FusionAuth migration guide for more.

Switching databases from mysql to postgresql

dan — Invalid Date

There is no easy way to do this. You'd have to migrate your configuration, your users and your DNS (if you are standing up a separate system).

If you have all your configuration as scripts, that should be easy to migrate, otherwise you need to move things over manually.

You could probably script a retrieve and then add of all the configuration, but there is no 'export all configuration' option.

For your users, you could do a database dump to get the hashes and do a bulk import. Or if you have developer edition you could set up a slow migration using connectors. The user migration process is broadly documented here: https://fusionauth.io/docs/v1/tech/guides/migration/

DNS migration is like any other DNS migration.

Migrating users who have signed in with apple

dan — Invalid Date

The best solution is to migrate first name and last name from your previous provider.

I don’t know of any other options. Apple is stingy with those details about the user.

Using FusionAuth without migrating data into it

dan — Invalid Date

Yes, you can have FusionAuth simply federate identity and not hold anything permanent in its own datastore. SSO should work in that case.

Two options:

If your existing user store can speak SAML or OIDC, you should be able to use an identity provider https://fusionauth.io/docs/v1/tech/identity-providers/ You would need to modify the theme and you'd probably want to use a hint. If your existing user store can speak LDAP or a JSON API, you can use connectors without migrating (this is a feature for which you must buy at least a developer license, starting at 125/month, more here: https://fusionauth.io/pricing/ ). Here's more on connectors: https://fusionauth.io/docs/v1/tech/connectors/

In both these cases, FusionAuth communicates with your userstore through some kind of facade, not directly with the database. Such direct database access isn't supported.

I'm not sure how this will work for all aspects of FusionAuth (password expiration, passwordless, etc) but for the main login flows it should work great.

How can we migrate FusionAuth configuration from dev/qa to prod

dan — Invalid Date

For exporting changes, it depends on how you make the changes. There's a community supported terraform module, but it doesn't cover all the apis (PRs welcome!).

You could also script all your changes using the API and apply those scripts to different environments. We mostly see folks writing migration scripts that call the APIs. These are very similar to database migration scripts except they make REST calls instead of SQL. The scripts are run during upgrades of their app. (If you are using an app like rails, you could even leverage the existing migration framework and a client library.)

Kickstart works well for dev envts and CI, but doesn't handle changes (it assumes there is no data in fusionauth and won't run if it sees any).

Testing loading of large numbers of users

dan — Invalid Date

Options:

You can drop the database. This will work if you want to start with a clean slate every time. You may want to look into kickstart or terraform to set default applications, accounts, and other items up every time. You can load all the users into a tenant (not the default one). Then, when you are done with loading up the users and want to clean up, you can delete the tenant, which will remove all users associated with that tenant. This option maintains all the other non tenant settings (IdPs, emails templates, themes, etc). You can use the bulk delete API. You can start deleting blocks of 5-10k users and increase the number deleted with each API call. This will be slower, but has the benefit of leaving the rest of the system untouched.

When migrating, what happens to our existing tokens

dan — Invalid Date

This depends on how the JWT was signs, but is probably fine, especially if JWTs are only used in APIs. It's very typical to want to ensure that existing JWTs are accepted as long as they haven’t expired. You'll also need to ensure that new JWTs from FusionAuth are also accepted.

So this is really a question of making sure the JWT producers and consumers have the correct signing secrets.

You can solve this by sharing the secrets between the old system and FusionAuth (check out the Keymaster to import existing keys or making sure your clients can look up the keys from a JWKS endpoint from both the old and the new system.

What is the best way to migrate into FusionAuth?

dan — Invalid Date

You can use Connectors to integrate with your old backend but this isn’t the best approach.

The best approach is to do a migration all in one step using our Import API.

If you are worried about resetting your users' passwords (justifiably!), you can implement custom password hashing if needed so that no one would need to do a password reset. See password encryptors for more info. If you use this path, you can upgrade each user's old password hash to BCrypt as users log in.

Password plugin and FusionAuth cloud

dan — Invalid Date

You can send us your jar file and we'll assist you. Just open a support ticket from your account page.

Migrate users between fusionauth instances

dan — Invalid Date

I'd use the import users API.

Helpful links:

https://fusionauth.io/docs/v1/tech/tutorials/migrate-users https://fusionauth.io/docs/v1/tech/apis/users#import-users