use the API to integrate with the current login/reg flow with FusionAuth. This lets you keep your existing html pretty much untouched, you're just calling out to FusionAuth instead of the database.
remove them and use the FusionAuth provided pages with OIDC. This lets you use the theming and localization capabilities of FusionAuth, including super simple social signon.
It's your choice based on what your needs are, either way will work.
I'd only recommend using SAML if you have an application which only supports SAML, not OIDC.
You'll also want to make sure that when someone registers with one of your applications in FusionAuth, they register with all three. I'd probably use a webhook to ensure that.
Groups would be a good solution. The group just allows you to assign the roles to the group instead of the user - and then the group membership allows you to inherit those roles (assuming the user is registered for the application whose roles belong to the group).
If you don't care about the possibility of duplicate users or you can handle them in your business logic (because tenants allow multiple users to have the same username or email address), you can use a globally scoped API key and just call the search API with the email address.
For example, here a script I ran after creating two 'firstname.lastname@example.org' users in different tenants in one FusionAuth instance: curl -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/search?queryString=test%40example.com'
The API_KEY variable was a globally scoped API key (not scoped to one tenant).
This returned this json (note, I'm running the database search engine, but the results should be similar if you are running elasticsearch):
You can keep a tenant around or use a particular one as the template, and then always create a new tenant using the sourceTenanId. This does not do a merge however, so if you want specific values, you’d want to do something like:
Call create w/ sourceTenantId
Consume the response and then modify what you want
Call update or patch with the new values
Unfortunately, there's no way to extract the password and the other information via the APIs.
Options I could see working:
if you have developer edition (or other paid edition), you could set up a connector from FusionAuth to itself (via a generic http connector). This would take time to move the users to a different tenant.
you can get a database dump of your FusionAuth instance and run a bulk import of the user data, password, and other password settings into another tenant.
you could move over the users, set a random password and force them to change their password by setting passwordChangeRequired. Not sure that would definitely work; you should test this.