Yes.

The only thing you can't create via the API is another API key. You can track that functionality on this issue.

See the tenant documentation for more.

Try clicking on the Advanced section on the User Search page and see you find what you're looking for.

Or search like this tenantId:9d92ca33-bc7b-4d13-acd7-f7dc06038396 where 9d92ca33-bc7b-4d13-acd7-f7dc06038396 is your tenantId.

Please note that this is an example for the elastic search search engine. With the database search engine, you can only search for the fields as documented in the API. As of this post, those are:

firstName lastName fullName email username

You can’t. You have to create another API key.

If you want to keep the same value, you could copy the value, delete it, and then recreate with the same value and set the tenant you want.

Ah, yes, thanks for explaining.

Yes

You have two options

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 'test@example.com' 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):

{"total":2,"users":[{"active":true,"email":"test@example.com","id":"0e3f0f4d-6795-4200-b044-9fea2437f0d2","insertInstant":1591914961640,"lastLoginInstant":1591914961678,"passwordChangeRequired":false,"passwordLastUpdateInstant":1591914961675,"tenantId":"1de156c2-2daa-a285-0c59-b52f9106d4e4","twoFactorDelivery":"None","twoFactorEnabled":false,"usernameStatus":"ACTIVE","verified":true},{"active":true,"email":"test@example.com","id":"6d145368-431b-4df1-aba4-5741bd7a9280","insertInstant":1592244970665,"lastLoginInstant":1592244970695,"passwordChangeRequired":false,"passwordLastUpdateInstant":1592244970690,"tenantId":"7b231917-733e-4347-b9e2-11915de60fc8","twoFactorDelivery":"None","twoFactorEnabled":false,"usernameStatus":"ACTIVE","verified":true}]}

Yes, you want to use sourceTenantId when creating the tenant

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

Yes, you can provide the tenantId on the request as a parameter. More information here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#openid-configuration

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.