@adrien-laugueux said in NullPointerException with POST /api/identity-provider/start:

2020-11-02T09:12:47.670831893Z 2020-11-02 9:12:47.670 AM ERROR io.fusionauth.app.primeframework.error.ExceptionExceptionHandler - An unhandled exception was thrown
2020-11-02T09:12:47.670862293Z java.lang.NullPointerException: null
2020-11-02T09:12:47.670866593Z at io.fusionauth.api.service.authentication.SAMLv2IdentityProviderAuthenticationService.start(SAMLv2IdentityProviderAuthenticationService.java:176)
2020-11-02T09:12:47.670870593Z at io.fusionauth.app.action.api.identityProvider.StartAction.post(StartAction.java:61)

Thanks for reporting. This looks to be a bug, moving to GitHub.
https://github.com/FusionAuth/fusionauth-issues/issues/963

As a work around, pass in a dummy data object to the API, for example:

{
  "applicationId": "1c212e59-0d0e-6b1a-ad48-f4f92793be32",
  "identityProviderId": "778985b7-6fd8-414d-acf2-94f18fb7c7e0",
   "data": {
      "workaround": true
   }
}

@james-black

Thanks for letting us know, this is a bug. To work around it, add this to the top of startup.sh:

CURL_OPTS="-fSL --progress-bar"

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

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

Another option is to use FusionAuth Cloud, then you do not need to be aware of the underlying data storage layer.

Thank you to everyone using FusionAuth, thank you for your feedback, your support and for helping us succeed.

https://www.getapp.com/security-software/identity-access-management/category-leaders/

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

@dan said in Systemd service template:

https://fusionauth.io/direct-download/

To Add to what @dan mentioned, you can install .deb or .rpm packages using the fast path install method. It will default to zip file installation.

For additional ways to call it - see the Fast Path install guide.
https://fusionauth.io/docs/v1/tech/installation-guide/fast-path/

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.

Generally speaking the primary bottleneck for logins per second is CPU. Hashing the password is intentionally slow and FusionAuth will not be able to perform more logins per second than your CPU can handle.

One way to identify if the password hashing is the bottleneck in load tests is to reduce the hash strength. See Tenants > Edit > Password > Cryptographic hash settings. Set this to Salted MD5 with a factor of 1 and then enable Re-hash on login. This will cause each user to have their password re-hashed next time they login to use MD5.

If you can still only get 50 logins per second with this config, then the database is likely the bottleneck. If this config allows you to achieve a much higher logins per second, then the CPU is your bottleneck. If you are CPU bound, the only way to get more logins per second is to horizontally scale or throw larger CPUs at each node.

I think @mark-robustelli is on the right track.

Ensure that you have configured the correct search type.

If you were to remove the configuration file or install into a new directory for the upgrade, you may be picking up the default configuration which will have search.type=database set as the default.

You can change this to search.type=elasticsearch for use with Elasticsearch or OpenSearch, or set an environment variable FUSIONAUTH_SEARCH_TYPE=ELASTICSEARCH.

See search.type in the config reference.

• https://fusionauth.io/docs/reference/configuration

We'll be adding native support for TLS in an upcoming release. See this GitHub issue for reference.
https://github.com/FusionAuth/fusionauth-issues/issues/1996

In the UI you can select "Special character" to require at least one special character. If anyone is looking to understand which characters will satisfy this requirement read on.

If you view the tooltip or the API - you’ll see the configuration is actually for non-alpha-numeric.

https://fusionauth.io/docs/v1/tech/apis/tenants#create-a-tenant

tenant.passwordValidationRules.requireNonAlpha
Whether to force the user to use at least one non-alphanumeric character.

So instead of limiting this to a specific set of special characters, we allow it to be any character that is not a unicode alphabetic and not a digit. In this way, we do not artificially limit the entropy of the password by saying you must use one or more characters for a finite set of "special characters" as you may be used to seeing on some login forms.

@chekikeja

You'll need to use WSL v2 or wait for the update which will include a native Windows start script using PowerShell.

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

@greggwonderly

When using the Docker image you'll need to either use PostgreSQL or build the MySQL JDBC connector into the image.

We've updated the Docker Hub description and the Docker install instructions to make this clearer.

https://hub.docker.com/r/fusionauth/fusionauth-app
https://fusionauth.io/docs/v1/tech/installation-guide/docker#limitations
https://raw.githubusercontent.com/FusionAuth/fusionauth-containers/master/docker/fusionauth/fusionauth-app-mysql/Dockerfile

This is a current limitation due our current understanding of the license under which the MySQL JDBC connector is released by Oracle.

@hwallenstone @chekikeja @greggwonderly

Sorry for the delay here, I've opened a GH issue to identify the cause of this and resolve ASAP.
https://github.com/FusionAuth/fusionauth-issues/issues/1862

@dev-2

Resolved in version 1.36.7 via https://github.com/FusionAuth/fusionauth-issues/issues/1654.

https://fusionauth.io/docs/v1/tech/release-notes#version-1-36-7

@utahtwo Currently this requires two different configurations. We initially tried to do it all within one IdP, but each mode requires different configuration and has unique security constraints. It seemed simpler for all involved to make them separate IdP configurations.

If there is a use case that breaks due to this design decision, please open a GitHub issue and outline the use case so we can better understand your needs. Thanks!

@stephen Thanks for the update.

That is correct, if you do provide a trustChallenge on the Two Factor Start API, it must be used in along with the trustToken.

This allows you the option to bind a trustToken to a particular request.

Are you indicating that it now works as you expect, or that you did not provide a trustChallenge during the Two Factor Start API, and it is still saying it is required when completing the Change Password API? In your example you only show you are sending a loginId, so if that is the case let me know.