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.

Hiya,

Per the configuration reference, you can set FUSIONAUTH_ADDITIONAL_JAVA_ARGS for

Any additional arguments that you want to pass to the Java VM where this service will run.

https://fusionauth.io/docs/v1/tech/reference/configuration#environment-variables

I know this was used to tweak proxy settings here: https://fusionauth.io/community/forum/topic/76/can-i-use-a-proxy-with-fusionauth

I'm not sure how to tweak the logging settings via java arguments, but maybe that gives you a place to start?

It looks like the uuid isn't being sent as a string. Per https://fusionauth.io/docs/v1/tech/reference/data-types#uuids it should be quoted.

So you want to send:

{ "applicationId": "15e45e7d-3e34-43df-9366-91c66a8cc9ae", "loginId": "myuserid", "password": "mypassword" }

Note that with version 1.16.x, elastic search is no longer required to run FusionAuth. More here about how you might make the choice: https://fusionauth.io/community/forum/topic/67/what-is-the-advantage-of-using-elasticsearch-as-the-search-engine

Hiya,

When you say

Everybody can see authorization key.

Who do you mean? Do you mean anyone with access to the FusionAuth admin console? Or some other set of users?

There's no built in reporting for login methods.

If you think that'd be worthwhile, please file a github issue with more details about the use case.

However, you could set up a webhook on the login event and record the event.authenticationType in an external datastore.

404 is a valid response code when using the client library to look for a user by email.

If the user exists you’ll get 200 and if the user does not exist you’ll get 404.

If you are using the client in the browser and don’t want to expose the 404 to the console, adding a try/catch would be a good idea. The 404 is the expected response code when the user does not exist:
https://fusionauth.io/docs/v1/tech/apis/users#response-2

With version 1.16.x, you should see a 'logs' menu item in the admin screen. Before 1.16 the only option was contacting FusionAuth.