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.

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

I just have to know!

The Lookup API is generally designed for use when you are not going to use the FusionAuth login pages or SSO features.

I think you're asking to go directly to an IdP login page without hitting the FusionAuth login page first and clicking a button to "Login with Acme Corp" for example?

Does this issue cover your use case?
https://github.com/FusionAuth/fusionauth-issues/issues/178#issuecomment-501390468

The above issue would allow you to provide a hint ahead of time so we can bypass the login page for a domain scoped IdP configuration. We could also add the option to provide the Identity Provider Id as a hint on the request ?identityProviderId=42 to force a particular IdP.

In the future we will be supporting an OpenID Connections that do not return an email address.

In the short term, if you are on the most recent version of FusionAuth you can make this work by fabricating an email address in your OpenID Connect Reconcile Lambda.

For example if the Userinfo response available to you in the Lambda has a user Id of 1234 you can build an email from that Id.

Example:

function(user, registration, jwt) {
  // Where the user's unique Id is the 'sub' claim. 
   user.email = jwt.sub + '@no-email-strava.com';
}

This will only work if the JWT does not come back with a claim called email.

The work around described above only works for OpenID Connect based IdPs, it will not work for Facebook. If the Facebook user is not providing you their email, they will not be able to login.

We could review this decision, perhaps it makes sense to leave this information in the API response.

In the event of a database breach, the attacker would have all of the necessary information, but in the API response we initially thought it better not to leak any information about how this user's password may be hashed and stored.

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

Are you asking to send the user directly to the register page? If so, yes, this is possible.

The URL is mostly the same, but the base is /oauth2/register instead of /oauth2/authorize.

If you click the view icon on your application, you will see a Registration URL or Registration URLs depending upon how many redirect URLs you have configured.

I am using name email as it shows in the documentation and I can log in. You can enable debug on the Apple Identity Provider which may provide you some additional details if it is not working.

In FusionAuth, the access token is always a JWT.

So you can always validate it on your own if you like, or use the Introspect, UserInfo or Validate APIs in FusionAuth to tell if you if the JWT is valid.

A FusionAuth invention.
https://fusionauth.io/docs/v1/tech/apis/jwt#validate-a-jwt

The OAuth2 way of doing it.
https://fusionauth.io/docs/v1/tech/oauth/endpoints#introspect

The OpenID Connect way of doing it.
https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo

Each of these APIs essentially does the same thing, takes a token and tells you if it is valid. If you're using an OAuth2 library that already knows how to call an Introspect endpoint, use that, if you're using an OIDC library that knows how to call the Userinfo endpoint, use that. If you're writing your own usage, use whatever you want!

We can add the Introspect or Userinfo endpoints to the client library if you like. Here is an issue for Python. https://github.com/FusionAuth/fusionauth-python-client/issues/8

However, because each of these APIs does essentially the same thing, if you're using the client library, you may as well use validateJWT.

Thanks for letting us know about the UK violations, I would have expected SUBSTR(CONCAT(MD5(RAND()), MD5(RAND())), 3, 16) to generated a unique value. We'll have to do some testing.

Is this a different use case than SSO, and if so, what are the limitations of SSO as it is currently implemented that don't fit this use case?

If your system is cpu bound then you need to scale this horizontally. Each node will only be able to hash n passwords per second. Once you reach this limit, the only way to perform more hashes per second is to reduce the hash complexity or add more nodes. Reducing the has complexity is not recommend as it makes these hashes easier to brute force.

It is clear that you have a lot of knowledge of your environment and have invested a lot of time into this solution. We have many large scale production instances, I'm confident FusionAuth can scale to your requirements. However as I'm sure you're aware performance tuning is not a simple equation.

There are a lot of possible variables here. The best way for you to get this tuned and ready for production is to purchase support so you can get engineering support.

Also, see database.maximum-pool-size here https://fusionauth.io/docs/v1/tech/reference/configuration

Perhaps arbitrary. It is sort of a hack to allow some specific OIDC IdPs to work.

In the case of Facebook, the reason for an email address being omitted from the response is easier to discern in FusionAuth. When you configure a Facebook IdP, you are inherently asking FusionAuth to defer authentication to Facebook.

The Facebook user can optionally decide to not share their email with FusionAuth. I am assuming this is the case since you are not getting an email back from Facebook.

In this scenario, we fail the login because the user has chosen not to share their email address.

So this is the reason why we don't allow the user to login.

The longer term solution to this is coming - where FusionAuth will take a unique Id from Google, Facebook, Twitter etc - and record their unique Id instead of just relying upon the email address. This will allow us to recognize the user uniquely apart from their email address. This will likely also allow FusionAuth to reconcile the user and possibly make the email address optional when creating the user.