Awesome!

@megeshg said in Authorize device without using /oauth2/device redirect:

we are not call /oauth/device would we need to? when in the flow would we need to do this? Dont see this in the documentation?

Hmmm. I think I must have been mistaken when I suggested that. I can't track down where I came up with that. My apologies.

I'm glad you found a solution.

If you get an unauthorized message in the UI when you submit a form it is due to your network configuration. This error is caused by our protective measures for cross site request forgery.

I would assume you are seeing an error on the admin page to indicate your proxy configuration is invalid. If not, ensure you have the correct X-Forwarded-Port, X-Forwarded-Host, X-Forwarded-Proto headers set when behind a proxy.

If these values are not set, or are invalid then when we compare the Origin header against the request we will fail our CSRF assertions and return a 401.

@jmarin Interesting. What instructions are you working off of from Rosetta Stone?

Great. It's typically used for CSRF protection, but can be used for other purposes. Here's a pretty good article covering this.

@robotdan Thanks Dan!

Hiya,

I was able to successfully decode a JWT. From reviewing this thread, I think maybe the issue is that you are using the wrong secret. It seems like you might have accidentally been using the id of the signing key '1c8e490a-4972-7d73-8935-06621a0a6441' instead of the actual secret key.

Here's how I found my secret key:

go to settings go to keymaster click on the green magnifying glass icon to view the default key click on click here to see the secret.

My secret looked something like this: n0EfufcUAuYM6199G3ffRp+YUVMPodabtlI/wT8oBYc=.

Can you try validating your JWT with the secret found through those steps and let me know how it goes?

Well, since we're talking about behavior based on a fix that isn't written yet, things are a bit theoretical.

Here's one approach we'd consider. An expired key pair cannot be used to sign a JWT, so we would either have to generate a new key pair ahead of the expiration, or start failing login operations. The former is a better user experience, so a user will either have to regenerate the key, or we would do it based upon a configured policy.

Also, wanted to be clear that we are aware of this limitation, which is why we set the default expiration period to 10 years (so we have a bit of time to solve this in the best way possible).

Hope this helps. Let me know if you don't have the information you need.

Hiya,

I got an answer for you about sunset provisions.

We have discussed source code escrow options with clients in the past. We can also offer a source code release clause (in the event FusionAuth goes out of business). However, these are only options if you are on an Enterprise plan with a custom contract.

Hope that helps you make the right decision for your application(s).

Github issue: https://github.com/FusionAuth/fusionauth-issues/issues/632

Here's a contrib project where community members have added proxy configs: https://github.com/FusionAuth/fusionauth-contrib

I can confirm it works properly in the latest version. Thank you very much for the quick help!

@ashok you got it!

I can see we can create applications and add tenants to them, which can't be edited/changed later. Is it possible to Add multiple tenants to one application? And maybe change the tenant later.

Nope, applications are contained within tenants. Here's a blog post talking about multi tenant in FusionAuth.

Also, on the documentation, it can be seen that in order to support multi-tenant or offer services to more than one client.
In this scenario, it is suggested to maintain separate Users, Applications, and Groups for each of your clients.

Yes, you can think of a tenant as an entirely separate installation of FusionAuth. So you'd have to create users, applications and groups for each tenant. Another way of structuring this would be to have an application for each client. Which you choose depends on how much separation you need.

what is the purpose of multiple application and multiple tenants?

The main purpose of using tenants in the higher level of separation. If you want each client to have their own FusionAuth theme, API keys, and a separate user space, then you want multi tenant. If you don't care about the themes, tenant scoped API keys, or that someone with the same email address wil have the same password for the application of client A and client B (because both use the same FusionAuth and live in the same tenant, the user will have the same password for each application), then separate FusionAuth applications in the same tenant will work.

Hmmm. That seems to be a bug, because the aud claim should be absent from the authorization code grant, since the user isn't registered for that application.

I filed an issue: https://github.com/FusionAuth/fusionauth-issues/issues/713

Hmmm. Weird. Will look at filing a bug. Thanks!

One workaround you can use is the PATCH method on the user object:

PATCH http://localhost:9011/api/user/<user-id> { "user": { "skipVerification": true, "email": "admin@email", "passwordChangeRequired": false, "username": "admin", "password": "....." } }

So would I be right in thinking, currently FusionAuth can't stop someone with an authenticated account using a application, but this is coming?
 

So basically is up to the application itself to check if they're authorised to use the app?

A better way to think about this is to separate authentication and authorization. FusionAuth will always authenticate the user because a user exists in the tenant, so if the user presents a valid username and password they will be authenticated.

FusionAuth then hands you back information about the user so you can authorize them based upon the authority the user has been assigned to the application - specified by the request parameter applicationId (or client_id in OAuth land)

So basically is up to the application itself to check if they're authorised to use the app?

This is correct.

However, even if FusionAuth were to reject the login request because the user was not registered to the application, it would be a mistake for you not to still perform an authorization check on the user.

The user may have an admin role, or a user role - so there will always be a need for you to verify the integrity of the JWT FusionAuth returns to you. These checks include verifying the signature to ensure FusionAuth signed it, not expired, the JWT is intended for your application (generally done by checking the aud claim), and then that the the JWT contains claims that indicate the user can perform the requested action. This can be done by checking the applicationId and roles claims.

There is an open issue to configure the Login API and related OAuth grants to optionally reject the request if the user is not registered to the application. Even with this feature, you'll still always need to be performing additional authorization checks to ensure the response is valid and the user has the necessary permissions.

See https://github.com/FusionAuth/fusionauth-issues/issues/439

Hope that helps!

@onmybus We'll need to do some more research into that error, @dan had some good insight in the reddit thread. Perhaps we are not building the response correctly.

If you wan try @dan's suggest, I think the SAML Populate lambda would look like this: ( @dan was really close)

function populate(samlResponse, user, registration) { samlResponse.assertion.subject.subjectConfirmation.recipient = null; }

Here is how we are building that subject object:

String callback = samlv2Configuration.callbackURL.toString(); response.assertion.subject = new Subject(); response.assertion.subject.subjectConfirmation = new SubjectConfirmation(); response.assertion.subject.subjectConfirmation.inResponseTo = request.id; response.assertion.subject.subjectConfirmation.method = ConfirmationMethod.Bearer; response.assertion.subject.subjectConfirmation.notBefore = now.minusHours(1); response.assertion.subject.subjectConfirmation.notOnOrAfter = now.plusHours(1); response.assertion.subject.subjectConfirmation.recipient = callback;

As a side note, the way you can debug this, is to dump out the samlResponse object to an event log. For example, add this to your lambda body and the samlResponse object will be pretty printed to an info event log. See System > Event Log.

console.info(JSON.stringify(samlResponse, null, ' '));

It seems to be working, thank you very much Dan.