@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.

The way most of our clients handle this is by using proxy redirect rules. For example, if your service is available at https://auth.example.com then you would redirect https://auth.example.com/ to https://example.com to push the user back into the "user" space of your site. This would mean that if you have a FusionAuth admin, they would need to directly access the UI by navigating to https://auth.example.com/admin/.

If you're already using a load balancer or a similar technology that provides routing rules, these are easy to configure.

You can also use managed IP locking (limiting access to a certain set of IP addresses), or some other type of HTTP header on the request to limit access to the FusionAuth admin UI to authorized users and treat all other traffic to anything under /admin for end users as an invalid request. These types of solutions are best handled at the network layer or with a proxy.

I totally forgot to add the register the user manually to the FusionAuth application. It is working now, thank you!

Looks like you added an issue: https://github.com/FusionAuth/fusionauth-issues/issues/668

Thanks!

@dan Thanks so much for the followup! For now, I'll work around the issue with a read/merge/write on the client.

If you are using https://aws.amazon.com/elasticsearch-service/ for your Elasticsearch server, you can access it via AWS APIs and use IAM to control access: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-ac.html

However, FusionAuth doesn't currently support the AWS signature for Elasticsearch requests.

The recommended way of securing such clusters is to place it in a private subnet and restricting traffic to it using a security group. More information: https://fusionauth.io/docs/v1/tech/installation-guide/securing#fusionauth-search

If you have to make it public to make it accessible to resources outside if AWS you could use a source IP lock, a VPN, basic auth if AWS supports it, or you could proxy the request perhaps to another endpoint that can build the AWS sig v4 header.

The client libraries all consume the same REST API, so you can use that as a reference: https://fusionauth.io/docs/v1/tech/apis/

In order to use a custom font within a publicly accessible FusionAuth template for a hosted deployment, pull the font from a CDN or other server hosting the font.

FusionAuth doesn't have any persistent storage for custom theme assets. You can use any font you like as long as it can be included via a tag.

You can double check the client id and secret are correct and don't have any trailing white space when entered in the FusionAuth config.

The scope you have configured does not show up in the discovery document but I would assume you'd receive a different error I'd that was a problem.

Confirm you registered the correct redirect_uri (something like http://localhost:9011/oauth2/callback) in your Intuit account.

Their APIs don't seem to be working well with the client_secret_basic authentication method.

Their discovery document indicates they support both client_secret_post and client_secret_basic.

"token_endpoint_auth_methods_supported":[ "client_secret_post", "client_secret_basic" ]

The default OpenID Connect config in FusionAuth will use client_secret_basic.

I found a thread indicating others are also having problems with the Basic Authorization strategy.
https://help.developer.intuit.com/s/question/0D50f000050TBnCCAW/getting-the-errorinvalidclient-for-access-tokens

Switching the configuration to use client_secret_post seems to have allowed an authentication request.

Here's a doc about how to switch search engines: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines

First, django-allauth supports an impressive list of providers. FusionAuth can support most of them using our generic OIDC connector, but kudos to the django-allauth team! If you are sure you only are building one django app, it's a good choice (and way better than rolling your own auth lib--please don't do that).

I'm not super familiar with django-allauth, but I did a bit of research. I think the reasons to use FusionAuth rather than django-allauth are:

centralized user management and control, even if you use a social provider. This scales to multiple applications within one tenant (so a django app and an open source forum app like nodebb can share a userbase; each user has the same username/email and password for each app) and multiple tenants (so you can have django app A and django app B totally separated, with different usernames/emails and passwords, if you're whitelabelling your app) ability to integrate with other auth providers using non OAuth protocols, like SAML FA is a single app, as opposed to a set of extensions you need to find, merge together, and keep in sync. You just drop it in and it works. additional features that you might not know you need until you need them (and have to build or evaluate/integrate a different library): passwordless consents family grouping webhooks for integration on user changes user actions groups jwt generation DAU/MAU reporting 2fa (I saw a 2fa plugin for this, but it was supported version 0.25 and django-allauth is at 0.42)

In short, FA is a full user management system, as opposed to an authentication and authorization plugin like django-allauth.

You'll need to be on version >= 1.15.0 to enable to enter the license code.

That's configurable at the tenant level.

The default is 180 seconds, but it is customizable in the tenant settings: https://fusionauth.io/docs/v1/tech/guides/passwordless#one-time-code-customization

And I can't change default port 9013 in option "fusionauth-app.https-port=9013" to 443. App just doesn't start

What error messages, if any, are you seeing in the logs when you try to start it? I was able to change the port to 4000 in a local instance and the app started. Are you starting FA using the root user, because when I changed SSL to run on 443, I saw this error:

29-May-2020 14:03:41.466 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-443]]
...
Caused by: java.net.BindException: Permission denied

If you are seeing that in your Tomcat log files, you'll need to start tomcat as root or use a tool like jsvc to do so. Or you can just run the SSL listener on a port above 1024, like 9013.

Is there any option to use my ssl certificate to secure communication with FusionAuth app? By default its "Inversoft Self-signed root certificate Expired: Wednesday, 25 September 2013 "

You can do so by installing your own certificate in Tomcat. This is not something I've done before, but these instructions look helpful: https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html

@ashok glad you solved the problem!

The only problem is that I don't seem to be able to pass all the tokens and then "map" it out in the backend.

I'm not sure what you mean here. Are you not seeing all the tokens in the lambda? Or are you not able to put them all in the custom claim?

Also, I think I already know the answer to this and this may sound dumb, but how can you have multiple tokens? A user with multiple providers? If so, how are they consolidated and combined?

A token is tied to a registration/application, so someone could login with google to one FusionAuth application and with facebook to another. Unless I'm missing something, I don't believe they are combined.

Lastly, it would have been nice if user.registrations had a providers field.

We welcome your feature requests 🙂 . Please file a github issue: https://github.com/fusionauth/fusionauth-issues/issues

Thanks for the reply @dan.
We ended up storing sub ID on our side. We thought that might gives us more flexibility down the road (not sure about this but if it doesn't work then we'll have an extra column in the db; a small price to pay IMHO).

"Where to map the ID?" was a bit headache for us as we didn't want to miss it or make an extra call by polling ourselves. Since we are using .NET Core, we ended up hooking into OnUserInformationReceived event, one of many from OpenIdConnectEvents. Hopefully, I'm not doing something really stupid.

Hiya,

The issue is that the identityProviders map needs to be populated for that login script to work, and the class behind this page doesn't provide that map. So for now I don't see a way to do this.

There is an open github issue to allow identity providers to be displayed on the registration page. I'd suggest adding your use case to that issue: https://github.com/FusionAuth/fusionauth-issues/issues/554 and I'm happy to rename it to something more general. Alternatively you can file a new issue if you feel the use case is distinct enough.

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!

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

@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, ' '));