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

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

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

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

@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

I just have to know!

@sswami said in SAMLv2 Failing with Zoom:

Zoom engineering team tried is also ready and trying its best to support FusionAuth. They said me if we figure this out it will be a support FusionAuth officially.

SAML is very complicated, I would recommend purchasing a paid support plan to get additional engineering assistance as you are doing with Zoom. This is likely a signing configuration error.

After a lot of working out, they said, it is probably failing due to "NotBefore" attribute in the Assertion>Conditions tag.

This was fixed in 1.28.0.
https://github.com/FusionAuth/fusionauth-issues/issues/1215

We cannot ship the MySQL due to licensing restrictions. This means we have to download it once you select MySQL, and outbound network access is required to download the correct MySQL connector.

https://fusionauth.io/docs/v1/tech/installation-guide/system-requirements/#network-access

Ensure you have allowed for outbound network access, or if you must air gap the installation, ensure you have copied the MySQL JDBC connector into the correct location.

If you are running Docker, here is an example to package the driver.
https://github.com/FusionAuth/fusionauth-containers/blob/master/docker/fusionauth/fusionauth-app-mysql/Dockerfile

Zendesk does not support SAML Single Logout.

The SAML logout request that Zendesk produces is not adequate to complete logout with FusionAuth.

This means, you click the logout button in Zendesk, it redirects to FusionAuth with a SAML logout request but it is not sufficient to end the SSO session with FusionAuth. Because you are then still logged into FusionAuth SSO, you are implicitly logged back into Zendesk.

This is a limitation of the Zendesk SAML implementation.

A better question may be how are the passwords currently hashed in WordPress?

Once you know that you'll know if one of the off the shelf options will work, or if a custom plugin will need to be written.

https://github.com/FusionAuth/fusionauth-example-password-encryptor

Here is the redirect_uri in the email:

&redirect_uri=35.153.28.164%2Findex.php%2FConfigure%2Freport_generator_amazing

This needs to be be &redirect_uri=http://35...

@richb201 said in invalid_redirect_uri:

I am going to try your standard passwordless email instead of my customized one.

This is a good idea. This should give you a base case to test with to ensure it is working correctly before customizing it too much.

You may also want to capture the raw email message to see if the URL is correct in the MIME encoded version of the email.

In the next release we plan to add additional options for IdPs for account linking. In this up-coming release you should be able to do things such as:

• Use an IdP that only uses usernames (at your own risk)
• Modify or build an email address using a Lambda for any IdP (at your own risk)
• Modify or build a username using a Lambda for any IdP (at your own risk)
• Use an IdP that does not have a username or email address

FusionAuth will remove the X-Frame-Options header if the origin is configured in the OAuth config as an Authorized origin.

But it sounds like in your case AzureAD is the one adding this header, so you would have to determine if this is something you can control in AzureAD through configuration.

In general, running the FusionAuth login through an IFRAME could work, however unless you are doing this all within the same domain or sub-domain. If you have any 3rd party domains - in practice it won't work due to the ever increasing strict cookie handling of mainstream browsers.

It looks as though Trend Micro (or whatever security solution is being used as a pass through) is modifying the URL and not properly preserving the URL encoding. You will need to inquire with Trend Micro about why this would be occurring.