@andrew-boyd

Perfect! Sounds good1

Josh

First, we recommend a webview or system browser. They have different strengths. The system browser is recommended by the security BCP and is preferred if the mobile app is not built by the same development organization as is running the identity provider (FusionAuth).

However, if both mobile app and IdP are owned by the same organization, a webview is fine too, and can offer more control over the user experience.

That said, some folks, as mentioned in the question, don't want a webview. They want to build the login experience out of native UI components. This gives them full control:

In that case, there are a few consequences:

the Authorization Code grant is not possible to implement, because it requires the user authenticate at FusionAuth. You will be re-implementing all of the "hosted login pages" logic and flow using the API. See https://fusionauth.io/docs/v1/tech/core-concepts/integration-points/#hosted-login-pages for the list of functionality you should be prepared to re-implement. Your mobile app will see username and passwords. Prepare for that from a security perspective. You will need to choose between the password grant and the login API

These are functionally equivalent. Arguments in favor of the Login API:

Richer response (you get different status codes for things like MFA required or "user not registered to this application") Can be protected with a tightly limited API key. You could actually provision an API key per mobile device if needed, using the API key API and some custom code: https://fusionauth.io/docs/v1/tech/apis/api-keys/

Against:

You must embed an API key in your application or relax certain security settings Tightly couples your application to FusionAuth

Arguments for the password grant:

It's an OAuth grant, so code written against it is more portable. No API key needed. No security requirements need to be loosened.

Arguments against:

You'll have to be prepared to parse JSON in the response if you are in any exceptional cases (MFA enabled, etc).

HTH.

@joshua
Thanks. I've up-voted a few of those open issues.

Since I'm trying to make this work for a COTS application I don't have the luxury of injecting another API call.

For now I'm pretending that the groupId being returned is the LDAP distiguished name for the group (I prefixed it in the Lambda with dn=). Then I can trick the application to looking up the group by the LDAP dn instead of name.

As of q4 2021, FusionAuth officially supports Kubernetes.

You can read the docs here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/

The best way to do this is to put a value on the tenant.data object. From there you can access it in each theme.

So, for the tenant in the dev environment, set tenant.data.assethost to dev.example.com. For the prod environment, set tenant.data.assethost to dev.example.com.

Then, in your theme, you'd have something like this:

<link rel="stylesheet" href="${tenant.data.assethost}/styles.css"/>

The reason to use the tenant object is that it is available on every theme template.

This does mean that your tenant configuration will differ slightly between environments. You can also replicate this field value between tenants if you are using multiple tenants.

What do you mean by 'user logs into desktop application'? How would you like to implement it?
If you implement step 1. as I've described in my previous post (by opening the browser window to log the user in) then there will be an SSO session in the browser already.
This is the flow that OAuth specs define for native applications, eg. desktop ones: https://datatracker.ietf.org/doc/html/rfc6749#section-9

This means that in step 3. when the browser is opened, the user is already authenticated.

I have enjoyed these books:

https://www.manning.com/books/oauth-2-in-action very specific to OAuth, lots of code)

https://www.apress.com/gp/book/9781484250945 More focused on bigger identity strategies and problems.

Also, the IDPro body of knowledge is free and useful:

https://idpro.org/body-of-knowledge/

Hiya,

It depends on what you mean by "dynamic". What are they based dynamically based on?

If they are based on attributes of the user, you could pull them from user.data. If they are random or time based, you could use the method outlined here: https://stackoverflow.com/a/51554484/203619

I'd also suggest testing to see if any parameters you add to the confirmation link are received by the destination page. I'm not sure if any processing happens that might strip unknown parameters. (I don't think so, but am not certain.)

Let us know what you find!

Hiya,

You should review the APIs to determine if FusionAuth can meet your needs.

You can sync almost everything.

One notable exception is the password hash and other info around it (salt, etc) which are not available via API call.

@mg

Good question! Aspects of this question are covered in our FAQ.

https://fusionauth.io/license-faq/#19
https://fusionauth.io/license-faq/#11

Additional information can be found by contacting our sales team should you have a business need for continuity plans.
Please use the contact form found on the home page.

https://fusionauth.io/contact/

Thanks,
Josh

Instead of using an OpenIdConnect authentication method I instead used a JWT Bearer like so:

services.AddAuthentication(options => { options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, opt => { opt.Authority = "https://my.fusionauth.instance"; opt.RequireHttpsMetadata = true; opt.SaveToken = true; opt.TokenValidationParameters = new TokenValidationParameters() { ValidAudience = "my application id / client id"; }; });

I could add the oidc back and use it to so long as I decoreate my Authorize attributes with that authentication scheme.

Now the pipeline calls my fusion auth instance and checks the token matches and has not been tampered with. To get this to work I had to create my own Key in FusionAuth and apply it to the JWT settings of my application. Then when the runtime calls https://my.fusionauth.instance/.well-known/jwks.json it returns the key needed to validate the token.

Now to get roles to work ...

A couple of things:

https://fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email has troubleshooting tips worth checking out.

The UI copy doesn't copy the SMTP password, so double check that as well.

Good question.

JWTs are either signed or encrypted. For the most part, you will encounter signed JWTs. When a JWT is created by an authorization server, it is signed. The signature essentially functions as a way to say "this payload has been signed using this algorithm. If the payload is different than what was signed, then this JWT is invalid." It is important to not pass sensitive data in a JWT payload for the reason that it can be viewed, but if a malicious actor tries to tamper with the JWT, the signature will no longer match it, and it will be invalid.

Yes, you can put anything in the user object that is documented here: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/#using-the-generic-connector

You can return registrations which contain roles as outlined in the sample JSON in the link above.

Hope that helps!

Is this the same as https://fusionauth.io/community/forum/topic/1317/error-after-updating-the-password ? or different?

Please share any logfiles you see (you can go to "System" -> "Logs" in the admin UI to view them).

Hi @saitulasiram94!

FusionAuth can act as both SP and IdP via SAML.

You may want to review how Gmail integrates via SAML. If Gmail (as Idp) supports an SP or IdP initiated login from FusionAuth, then you should be able to integrate.

I have included our relevant documentation below.

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2-idp-initiated/ https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

Thanks,
Josh

With advanced threat detection you can block access to applications via IP ranges (it's touched on briefly here: https://youtu.be/pjGxOXamVfk?t=1209 ).

Advanced threat detection requires an enterprise license. Currently you can't lock a certain user to an IP range, though.

Please feel free to file a feature request with details of this use case if you'd like to see this implemented.

Tested and verified this works. Feel free to use theme.data to your heart's content, @mmcnamara !