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

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.

@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

I just have to know!

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.

Interesting, not sure how this would happen. Thanks for the report @stuart-auld - I agree, this is not a good dev experience. We will identify this cause and try to failure better.

Tracking via GitHub Issue #1217

Thanks for the suggestion @david-oggier - this was previously working, but with some recent licensing changes we had to jiggle the handle to get it working again. All fixed!

Thanks @dan for bringing this up.

Most of the doc should now be a available for the new MFA features.

is it possible to enforce both SMS and email verification, i.e., that both occur, not just one of them?

You can configure both, but during a login flow, the user may select one of these options as the second factor to complete login. The first factor being the password.

is it possible to configure at what point in the flow these verifications occur?

No, not during login.

if not, do these verifications occurs at the end of the registration flow, or how does the registration flow look specifically?

Two Factor occurs during a login request.

There is also a Step Up Two Factor API which would allow you to perform a second factor login anytime you want within your own application.

@richb201 said in where is the application oauth tab?:

redirect_uri=35.153.28.16

The redirect needs to match your configured list in FusionAuth. redirect_uri=http://35.153.28.16...

If you are using the FusionAuth email template, you will want to verify the link is getting built correctly in the template.

@richb201 said in invalid_redirect_uri:

http://35.153.28.164:9011/oauth2/passwordless/Hpwfsd2h-82faVz7oFYpX6xg0k43aIFM0d54-ueW7dc?tenantId=4272f95b-0989-4892-badc-0ef6b934885f&client_id=f603697d-41ea-4c53-ac2d-e935d5e34221&redirect_uri=35.153.28.164%2Findex.php%2FConfigure%2Freport_generator_amazing&response_type=code&scope=openid&state=richardbernstein216%40yahoo.com

It looks missing to me, in your example HTML I see &redirect_uri=35.153.28.164... instead of &redirect_uri=http://35.153.28.164....

Hmm... this is likely a JSON merge issue. See linked issues below.

We Marshall objects back and forth from the JS engine via JSON and I the root issue here is likely that JSON merge does not handle arrays.

We could fix this by turning off merge for this field, or we will be updating > Java 14 shortly which means we have to ditch Nashorn, so it is possible this new JS engine will allow us to directly manipulate the registration object and ditch the JSON conversation.

Related issues:
https://github.com/FusionAuth/fusionauth-issues/issues/441
https://github.com/FusionAuth/fusionauth-issues/issues/571
https://github.com/FusionAuth/fusionauth-issues/issues/667

To confirm, you are doing something like this:

registration.roles = [];
registration.roles.push('viewer');

And then the resulting registration contains the previous roles + viewer? And you are expecting a single role of viewer?

A couple of options:

1. You could optionally configure a different template for each tenant so you could hard code the correct URL in each template.

2. You could also add the correct URL to the tenant.data and then pull it out in the template during render so you could use the same template across tenants.

3. If the state parameter is working well for you for other APIs, you could open a feature request in GH to add this to the API in question.

Is this the issue described here? https://github.com/FusionAuth/fusionauth-issues/issues/629