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.

There isn’t a single table in the db really. Configuration exists there, and in tenants, applications, etc.

This link is probably what you are looking for:

https://fusionauth.io/docs/v1/tech/themes/#handling-failures

Hi @david-0 ,

I understand your frustration. We're thinking about ways to ameliorate this issue.

And you aren't alone. Here are a couple of open github issues:

https://github.com/FusionAuth/fusionauth-issues/issues/751 (kind of the reverse of what you're talking about, but related) https://github.com/FusionAuth/fusionauth-issues/issues/1 (the very first issue filed!)

Please feel free to upvote them, as that helps direct our development efforts. If these issues don't cover what you're looking to do, please do file a feature request with use case specifics.

Thanks,
Dan

Looks like this might be an issue you'd want to upvote: https://github.com/FusionAuth/fusionauth-issues/issues/439

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

Great. Marking this solved. Let me know if that's not ok 🙂 .

Ah, makes sense.

You should be able to export the email templates via the retrieve email template API and them re-import them using the same API. It may take a bit of fiddling, but it should be possible. In fact, you may want to capture the email templates as a kickstart file for future deployment/dev envt setup ease: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

I think we already have some issues about configuration migration, so you may want to check them out and vote for them if they convey what you'd like (please upvote them if so):

https://github.com/FusionAuth/fusionauth-issues/issues/576 https://github.com/FusionAuth/fusionauth-issues/issues/560

Hmmm. What version of FusionAuth are you running?

If you have set the refresh token usage policy to be OneTime in the tenant settings, then the old refresh token shouldn't give you access tokens after the first call.

Nope.

However, you can write some code to do this. You could write two scripts:

one to add a user, which should register them to all applications one to add an application, which should register all users

Further reading:

This post is probably worth a read, to clarify how FusionAuth handles users without an application registration: https://fusionauth.io/community/forum/topic/5/can-you-limit-a-user-s-login-authentication-access-to-applications-within-a-single-tenant/2?_=1597070984952

You also might be interested in voting up this issue: https://github.com/FusionAuth/fusionauth-issues/issues/772

You could also file a github issue explaining what you are trying to accomplish, perhaps there's a feature to be written to allow this.

@peter-netbal

I would like to know whats the best / recommended practice in this case...

I'm a former consultant, so the answer is "it depends". It depends on how many applications you have and what you are using the verified attribute for.

There is no way to register the user and the registration in one step unless you send the emails outside of FusionAuth. You can of course update the user via the API to have verified true when someone verifies their registration, perhaps by listening to a webhook: https://fusionauth.io/docs/v1/tech/events-webhooks/events#user-registration-verified and with skipVerification set to true.

I also wonder why you need to have both the user object and the register object set the value of verified to true. Can you have your application read just one of those values? Or are you looking to have things consistent between the two objects?

Yes and no. Since OAuth 2.1 isn't released yet (though the working group seems to be getting pretty close) no one can "support" it yet. This is the draft specification right now: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00

This blog post examines some of the changes and how FusionAuth is set up to handle them: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1#can-you-use-oauth-21-right-now

Ah, I just tested this out and if you don't need it in the JWT, you should be able to see it in the registrations object returned after login.

Here's a response I get after logging in:

{ "token": "ey...", "user": { "active": true, "connectorId": "e3306678-a53a-4964-9040-1c96f36dda72", "email": "email@example.com", "id": "2df13f18-01cc-48a4-b97a-2ab04f98d006", "insertInstant": 1592857899119, "lastLoginInstant": 1596819645662, "lastUpdateInstant": 0, "passwordChangeRequired": false, "passwordLastUpdateInstant": 1592857899145, "registrations": [ { "applicationId": "78bd26e9-51de-4af8-baf4-914ea5825355", "id": "73d2317b-d196-4315-aba2-3c205ed3ccae", "insertInstant": 1592857899151, "lastLoginInstant": 1592857899153, "lastUpdateInstant": 1596813810104, "roles": [ "Role1" ], "usernameStatus": "ACTIVE", "verified": true } ], "tenantId": "1de156c2-2daa-a285-0c59-b52f9106d4e4", "twoFactorDelivery": "None", "twoFactorEnabled": false, "usernameStatus": "ACTIVE", "verified": true } }

So user.applicationId.roles is what you want. Note that roles are applied on an application by application basis. If a user is in a group which has a role 'roleA' which is created in 'applicationA', but is not registered for 'applicationA', they won't receive that role. More on that here: https://fusionauth.io/docs/v1/tech/core-concepts/groups

The JWT (id_token or access_token) will contain the email_verified claim with a value of true or false, so if you wish to limit privilege based upon this state, that would be a good way to do it.

Not through a FusionAuth policy, but you can do that in the login template if you want to filter it by email domain or something like that.

If you have not let the user set their password, then passwordless will implicitly be the only path that will work for them (assuming you don’t offer them social login buttons).

If you pass the user’s email on the redirect to FusionAuth as &loginId=test@example.com, that value will be available to you in the template and you can then key off, parse the domain, or whatever - and use that to hide or show whatever you like.

I don't see any way to customize the redirect URL on completion of password setup.

One option could be adding a link to the 'Change Password Complete' template to the login page: "Return to example.com".

You could also inject some javascript to do a redirect.

8GB is way plenty. 1 or 2GB is generally adequate, it can depend a bit, but FusionAuth doesn't keep much in RAM. Scaling out horizontallly is likely more effective than more ram per instance. This way you can handle more logins per second--these are going to be cpu bound.

Hiya,

Yup, you've encountered a known limit of the lambda functionality. The two options you outline are the ones I'd consider. You could update the user data with the tenant name on create using a webhook, so maybe not as messy as you might think.

The only other option would be to file a github issue requesting the tenant information be made available in the lambda: https://github.com/fusionauth/fusionauth-issues/issues

There are some similar issues I'd suggest voting up if this is important to you:

https://github.com/FusionAuth/fusionauth-issues/issues/571
https://github.com/FusionAuth/fusionauth-issues/issues/267
https://github.com/FusionAuth/fusionauth-issues/issues/229

Generally this is a dev time message. Although depending upon your integration, it may be possible that an end user would see that message.

You could try adding a message to your theme:

[MultiTenantSSONotSupported]=n/a

In general, any user facing message can be overridden by your theme.