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

Is it a total coincidence that that is GitHub Issue #404? Ha!

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

If you have your own login form, you'll either be using the Login API or the OAuth Password grant. You will use one or the other, not both, each option will provide you roughly the same functionality. Totally up to you, the Login API is our own creation, the Password grant is defined by the OAuth RFC.

High level:

Collect email and password Call the Login API or the Token endpoint using the Password grant Collect the JSON response which will contain an access token (JWT)

Login API docs: https://fusionauth.io/docs/v1/tech/apis/login#authenticate-a-user

Password Grant: https://fusionauth.io/docs/v1/tech/oauth/endpoints#resource-owner-password-credentials-grant-request
https://fusionauth.io/docs/v1/tech/oauth/#example-resource-owner-password-credentials-grant

That response is essentially defined by OAuth2 / OIDC as the token response. If you want to customize it, the best solution is to use a lambda to encode additional details in the access_token (JWT) and then at the client decode that value to extract the necessary claims.

More on lambdas: https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate

As far as I know it is not possible, I believe Google builds that text based upon the redirect_uri. I would assume you'd only see the fusionauth.io domain listed if you're using our hosted URL. If you are using an enterprise plan with a custom domain (login.example.com) you shouldn't see fusionauth.io mentioned.

I know in the Google cloud console where you configure your credentials there is a customization option for the consent screen, but I do not know if that will modify this account chooser or not.

Hiya @iggs ,

It's been a few years since I used cpanel, but if you've set up a mysql or postgresql database, it shouldn't be too hard.

You do need a server which can run java. Here are the system requirements: https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements

If you've made sure your remote server can run java, then you can download the zip files: https://fusionauth.io/direct-download

Then I'd ftp up the unzipped files. Then you'll need to ssh to your server and run bin/startup.sh from that directory. This should start up fusionauth on the 9011 port.

If your server was iggs.example.com, you'd then access it at iggs.example.com:9011. This would prompt for your database information. After entering that, you should be able to start setting up users and FusionAuth applications in the admin screen for use by your applications.

Finally, if you'd like a dedicated support channel, we have paid plans for that: https://fusionauth.io/pricing

Let me know if that helps.

Thanks,
Dan

Unfortunately not at this time. There are a couple of open issues that are related, but if they don't cover your precise use case, please feel free to file a new one.

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

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

This is a CORS error. You'll need to ensure POST is an allowed HTTP method, and the origin of your SAML IdP is configured as an allowed origin.

https://fusionauth.io/docs/v1/tech/reference/cors

Making this change will allow FusionAuth to run even when utf8mb4 is not configured properly. We added that configuration option to ensure the limitation is understood before you turn off the enforcement.

The implication is that if you attempt to store a 4 byte unicode character the INSERT or UPDATE request will fail. The initial MySQL UTF-8 support only allowed for 3 byte characters, they then came out with utf8mb4 to support 4 byte characters. More here: https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html

For example, many emoji are 4 byte characters, so if you tried to store a piece of text with a smiley such as 😁 it will fail. The 😁 is a four byte character, U+1F601 or \xF0\x9F\x98\x81.

Unless you configure MySQL to use utf8mb4, any character points between U+10000 and U+10FFFF will fail to be stored.