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
FusionAuth is API first, so this type of flow could be created using our API and custom integration code.
On tenant B, a user from tenant A logs in.
Do a search for a user
If found, do a registration and/or user create using API.
The newly created user can now be logged in. As referenced above, you may have some interstitial pages that would be needed for password generation as the user passes from one tenant to another.
Another way to do this would be to reconsider how you are using tenants and applications. Depending on your business requirements, registering a user to a new application rather than a completely separate tenant removes a few steps from a workflow as described.