@dadasaheb-patil

Welcome! I have passed this along to our sales development team for a reach-out and introduction. FusionAuth can be used in a number of ways to meet various use cases. Our core concepts section offers a review of some of the basic functionality within FusionAuth, as well as our Five Minute setup guide to get you up and running quickly.

Links are included below

https://fusionauth.io/docs/v1/tech/core-concepts/
https://fusionauth.io/docs/v1/tech/5-minute-setup-guide/
https://fusionauth.io/docs/v1/tech/getting-started/

Regarding roles - there are a number of ways that you can map app users and roles. One common method is with a JWT and a lambda.

https://fusionauth.io/docs/v1/tech/core-concepts/roles/
https://fusionauth.io/docs/v1/tech/lambdas/

Roles are available in the JWT upon successful authorization and are also returned as part of the user’s registrations.

I hope this is a good place to start! Let us know if you have more specific questions and we wil do what we can to address them here.

Thanks,
Josh

Hi @Joshua,

It seems this is working as expected as @egis described. FusionAuth needs to find an email claim in the response from the userinfo endpoint (or username, depending on the linking method) before running the reconcile lambda. I confirmed this by linking on username instead and setting preferred_username to sub and was able to confirm that the reconcile lambda executed. I had mistakenly thought that the lambda ran before linking occurred and could be used to populate email.

In my case, the issue is that my IDP (AzureAD) does not return email from the userinfo endpoint. AzureAD is very restricted in what it returns from the userinfo endpoint and allows not customization or claim mapping. It seems AzureAD populates the email claim with Primary SMTP email address, which is reserved field from Exchange, however we don't use Exchange/Outlook365 as our email service provider.

In Azure, claim mapping can only be applied to the access and id tokens and not what is returned from the userinfo endpoint. However, these tokens are not available to the lambdas.

I believe there is already a Github issue created for this:
https://github.com/FusionAuth/fusionauth-issues/issues/323

In the meantime, I'm using SAML instead, because AzureAD allows me to map email address to user.mail which is where it is stored in our case.

@michael-schramm

You can also ask in our slack channel if it suits you 🙂

https://fusionauth.io/community/

Thanks,
Josh

It would appear that you are requesting functionality similar to scopes in OAuth:

https://github.com/FusionAuth/fusionauth-issues/issues/218
https://github.com/FusionAuth/fusionauth-issues/issues/275

Please upvote these issues if they apply to your use case.

I don't see a way to manage "permissions" in fusion auth (what a role would allow a user to do) - so I assume that concept would be left to the individual micro-services to handle.

I believe that you are correct. You would have to write this integration code.

Roles can be used. They are entirely free form. Meaning you can assign the role of "monster_maker_person" to a user and define what the role can and cannot do at the integration code level.

A few other customers have unique implementations regarding roles and permissions. You can read more (at a high level) about them below.
https://fusionauth.io/blog/2021/06/15/sunfinity-fusionauth-python/#undefined

First question is if my "mapping" follows the best practices for fusion auth. I want to make sure that I don't map in a way that means I'll be fighting with the solution.

The answer to this question might be in the details of the integration. From afar, it seems reasonable to me. We do offer professional services/contracts should you need additional support in your integration.

Second quesiton is, how would the community suggest that we model the new requirement in fusion auth, or is the capabilities of fusion auth not a good fit for this use case?

After browsing our open issues (https://github.com/FusionAuth), feel free to log your own use case if not covered.

I hope this helps!

Thanks,
Josh

Our HA cloud offerings, outlined on fusionauth.io/pricing are aimed at the following use cases:

Large production needs Reliability required Higher monthly active users

Development doesn't typically fall into any of these :).

With HA you get an SLA, a custom URL (auth.example.com instead of example.fusionauth.io) and an architecture capable of handling more users.

You might want a custom URL to test your DNS/cookie config. Or you might want to load test (please don't load test with a basic cloud deployment, it won't tell you anything about production performanc).

If you want to derisk this early, in both these cases, we recommend standing up a temporary HA instance, applying your configuration, testing, and then tearing down the HA instance.

https://github.com/FusionAuth/fusionauth-issues/issues/1394 - logged for feature tracking. Feel free to add your own comments or observations as you see fit

That looks like you haven't applied the migrations needed. Per the release notes, that upgrade will require database migrations: https://fusionauth.io/docs/v1/tech/release-notes/

As a reminder, you can have fusionauth do the database migrations, but only if you are in development mode (check fusionauth.properties). If you are in production mode, you'll have to apply the migrations yourself, as outlined here: https://fusionauth.io/docs/v1/tech/installation-guide/upgrade/#database

Yes, you can search for users who are set to

"active" : false

just like any other user

The user can be retrieved but will have a status of {"user" : { "active" : false } }
The user cannot be updated but will instead have this error return

{ "fieldErrors": { "userId": [ { "code": "[inactive]userId", "message": "The User with Id [00000000-0000-0000-0000-000000000007] is inactive and cannot be updated until it is reactivated." } ] } }

Yes, this is the functional equivalent in the UI.

Soft delete is the preferred method.

Hi @ivona, thank you for writing in!

Can you let me know of any output in the error event log for both OAuth and apple config? This may help to troubleshoot this issue.

In the meantime, please feel free to take a look at some of our similar, Apple-related posts on our forum. Here are a couple of posts that may prove useful:

https://fusionauth.io/community/forum/topic/752/not-able-to-login-with-apple-id/6
https://fusionauth.io/community/forum/topic/752/not-able-to-login-with-apple-id

In the meantime I will dig further into this issue on my end and see if I can reproduce it.

Talk soon,

Akira

@elliotdickison said in Awkward OAuth logout in mobile app:

@maciej-wisniowski We ended up going with your solution and it's working alright, thanks for that!

@robotdan One suggestion for you all: I found the naming of the "AllApplications" value for the application.oauthConfiguration.logoutBehavior setting a bit confusing. As far as I can tell all the "AllApplications" value it really means is "show the OAuth2 logout page". That page can be used to log out of all apps (that's the default template behavior), but it doesn't have to be used that way. Per the suggestion from @maciej-wisniowski we are using the page to log the user out of only one app and show a "successfully logged out" message. Maybe to avoid a breaking API change the value "OneApplication" could be added in addition to "AllApplications" and "RedirectOnly". That value could use the same OAuth 2 logout template but maybe set a variable that could be used to conditionally turn off the logout-of-all-apps behavior. Just a thought.

Thanks for the suggestion @elliotdickison - please do open a GH issue with this suggestion and how you'd like the logout to behave in your use case.

Nope, at this time it is all configured at the tenant, via the UI or API.

If you have specific needs, please file a github issue outlining your use case: https://github.com/fusionauth/fusionauth-issues/issues

@saleenajohn49 said in Clicked the regenerate key button on the reactor page:

A nuclear reactor produces and controls the release of energy from splitting the atoms of certain elements. In a nuclear power reactor, the energy released is used as heat to make steam to generate electricity. (In a research reactor the main purpose is to utilise the actual neutrons produced in the core. In most naval reactors, steam drives a turbine directly for propulsion.

Ha ha.. yep, that is pretty much how the FusionAuth Reactor works too. 😆

I think you missed to put FusionAuth Tenant ID.

In my case, I create a file called appConfig.json :

e89f0007-0a18-41d8-b184-5e820eafa09e-image.png

The file contains :

FusionAuth URL (where you deploy your FusionAuth app such as https://login.mywebsite.com) FusionAuth Tenant ID FusionAuth App ID FusionAuth Client Key

Afterwards, I create a new instance of FusionAuth like this (in another file):

d60fe095-14be-4a7e-85fb-44b49a68c462-image.png

I pass FusionAuth Tenant ID here as a parameter.

Hence, I can fire a login function like below :
a4eed8ff-1441-4f15-9a93-9123603c36c7-image.png

@aman

Glad, you got it working!

Remember that CORS is a powerful tool. It's best to keep it enabled, once you nail down your configuration.

Thanks,
Josh

The timeout is already really high (10 seconds). I can see in the logs of my webhook that I get a timeout in the api call to FusionAuth. It feels like a race condition.