@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?

@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?

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.

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.

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.

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.

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).

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.

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.

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.

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

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