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

@mgetka

The Elasticsearch index is not queried during an authentication request, it is only used for search operations. We do attempt to update the search index during an authentication request but it is not directly required to complete login.

The Windows install is just a zip package. So deleting is mostly just deleting the directory.

Un-install the service

If you installed a Windows service after unzipping the bundle during the installation, you should un-install that first. If you only used the startup.bat script you can skip this step.

cd C:\Users\me\projects\fusionauth\fusionauth-app\apache-tomcat\bin
FusionAuthApp.exe /uninstall

https://fusionauth.io/docs/v1/tech/installation-guide/upgrade

Note:
Note, I see at the bottom of your code example that binary is not present in the directory. I'll have to look into why that is not present. In any case, if it is not present, that also means you have not installed the service, so you can skip this step.

Delete the directory

To complete the un-install, simply delete the directory once you have stopped the processes.

rmdir C:\Users\me\projects\fusionauth /s

If you have a database running locally, you will need to delete that separately. To do that you can open a SQL shell and run:

drop database fusionauth;

Hope that helps! Perhaps we need to add an un-install section to the documentation.

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

@jmarin the fix you're looking for is was in FusionAuth version 1.11.0, if you upgrade to version 1.11.0 or later this issues should be resolved. https://fusionauth.io/docs/v1/tech/release-notes#version-1-11-0

Thanks for sharing @hopper-jerry , I added a link to your Docker hub and article on the GitHub page so others can easily find your Arm64 images.

Thanks for your contribution!
https://github.com/FusionAuth/fusionauth-containers#arm64

@ashok you got it!

If you omit the encryptionScheme property on the user, FusionAuth will assume you are importing a plain text password.

https://fusionauth.io/docs/v1/tech/apis/users#import-users

If you were importing a hashed password, you'd have the encryptionScheme, factor, salt, and password (in hash form).

You'll want to set the password to something random. You will not need to set the salt, it will be generated for you during import when providing a plain text password.

Here is a Java example to generate a strong random password.

public static String secureRandom(int bytes) {
  SecureRandom random = new SecureRandom();
  byte[] buf = new byte[bytes];
  random.nextBytes(buf);
  return Base64.getUrlEncoder().withoutPadding().encodeToString(buf);
}

String randomPassword = secureRandom(32);

32 bytes is generally considered adequate. A Base64 encoded character has 62 possible values, and an entropy per character of 5.954 bits. A 16 byte token provides approximately 131 bits of entropy (22 characters * 5.954). A 32 byte token provides approximately 256 bits of entropy (43 characters * 5.954).

As a side note, during the Import, if you provide a password directly, i.e. not a hash - then FusionAuth will hash the password inline before it stores the value. If you have a lot of users, this will significantly slow the import process.

Asking for a friend.

About half of our users don't have passwords set as they are authenticated via third party ID providers such as Google. While importing users from an existing system, I'm not setting anything for password and salt fields, which is causing the import to throw You must specify the [user.password] property for each user. error (using the FA's .net client). What would I set for password and salt in this case? Thank you!

@jmarin the fix you're looking for is was in FusionAuth version 1.11.0, if you upgrade to version 1.11.0 or later this issues should be resolved. https://fusionauth.io/docs/v1/tech/release-notes#version-1-11-0

What version of MySQL are you running?

Can you paste in start up portion of the fusionauth-app.log ? This may help point out why we can't connect, or if the schema creation is failing.

As a work around, if you just want to get up and running, you can always install the schema manually using the advanced installation guide.

https://fusionauth.io/docs/v1/tech/installation-guide/fusionauth-app#advanced-installation

@megeshg If you do intend to run this in production, I would recommend a paid edition. We can offer you direct engineering support to ensure your use case works flawlessly.

If you do figure it out - let us know, or perhaps as we review the thread something will jump out that we can share with you.

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