Here's a contrib project where community members have added proxy configs: https://github.com/FusionAuth/fusionauth-contrib

Please check out https://fusionauth.io/docs/v1/tech/tutorials/setting-up-user-account-lockout which walks you through the steps to lock logins after a configurable number of attempts.

We don't support this functionality at this time.

Pulled over from https://github.com/FusionAuth/fusionauth-issues/issues/700

Apparently jackson + friends make assumptions when it comes to parsing raw -> ZonedDateTime. It appears that the ZonedDateTime for createInstant when deserializing timestamps are not being handled properly somehow, so you need custom code. We have our own Jackson serializer and deserializer for ZonedDateTime to ensure we always get milli in and milli out.

Here's the code (Apache2 license) and the maven repository links if it's helpful.

Yes, a refresh token has a configured time to live (TTL). It can be configured at the Tenant or Application level.
More here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#jwt

There are a few ways to do this.

This assumes that you are running elasticsearch on a different server than you are running the fusionauth instances. If they are on the same server, you should be fine, as that is the default configuration.

The first is at the network level, using a firewall or something like security groups on AWS. If you are doing this, you can configure the server that elasticsearch is installed on to accept requests only from the server that FusionAuth is installed on.

The second is to use basic authentication. That is, set fusionauth-search.servers in the fusionauth.properties file, or the FUSIONAUTH_SEARCH_SERVERS environment variable to include the basic username and password. https://user:password@example.com. And make sure to set up elastic to use basic auth, using whatever authentication source you'd like. (You could even go meta and have elasticsearch auth the user against the fusionauth instance 🙂 ).

Further discussion here.

You need to use the user search API with an elastic search query string.

Here's a curl example:

API_KEY=.... GROUP_ID=f4a64b10-1cf6-4289-84c0-c3035f3b78bc curl -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/search/?queryString=memberships.groupId:'$GROUP_ID

If you are using the database search engine, you cannot find all the members of a group.

Regarding all the settings, yes, you'll have to set those up again. There's currently no way to export configuration of a FusionAuth setup.

What you can do is write a Kickstart file which lets you set up a new FusionAuth instance to be configured just how you want it. You basically build a JSON file which calls the APIs to configure FusionAuth: https://fusionauth.io/docs/v1/tech/installation-guide/kickstart

@ashok you got it!

FusionAuth does not have any plugins that directly write to 3rd party services like DataDog.

But with the API https://fusionauth.io/docs/v1/tech/apis/event-logs you can write an ingester.

Hiya!

You have a couple of options.

You should be able to use the validateJWT method on the fusionauth node client. That calls this API: https://fusionauth.io/docs/v1/tech/apis/jwt#validate-a-jwt

You can call into /oauth2/introspect, but you'll have to construct that URL manually, as it isn't currently supported by the client libraries.

Finally, you can also use a jwt package (like this one) to verify the JWT is still valid without communicating with FusionAuth.

Hope this helps.

It depends on the issue, but there are two things you can do. Note that FusionAuth typically sends the query you post to the /api/user/search endpoint with the query parameter straight through to Elasticsearch

First, ensure you are running elasticsearch and not the database search engine.

Then, for some queries you can see the generate ElasticSearch query strings by clicking on the 'advanced' option in the user search area of the admin UI. This can be helpful.

Finally, try running the query directly against elasticsearch and seeing if it works. Here are examples which will pull back all the data in your elasticsearch cluster (beware!).

curl -XPOST -H 'Content-type: application/json' "http://localhost:9021/_search" -d' { "query": { "match_all": {} } }'

or, if you have the query stored in query.json

curl -XPOST -H 'Content-type: application/json' "http://localhost:9021/_search" -d@query.json

Groups would be a good solution. The group just allows you to assign the roles to the group instead of the user - and then the group membership allows you to inherit those roles (assuming the user is registered for the application whose roles belong to the group).

I think you could look at the latest tag on dockerhub? https://hub.docker.com/r/fusionauth/fusionauth-app/tags

I'm not sure if there's an automated way to do this, but this might be useful: https://docs.docker.com/registry/spec/api/#pulling-an-image

UUID v4

More details about datatypes in general: https://fusionauth.io/docs/v1/tech/reference/data-types

@jmarin Interesting. What instructions are you working off of from Rosetta Stone?

Great. It's typically used for CSRF protection, but can be used for other purposes. Here's a pretty good article covering this.

I'm not aware of anyone running this configuration, but Okta is a valid OIDC identity provider, and FusionAuth supports OIDC compliant IdPs, so this should work.

Weirdly, I didn't find Okta documentation on setting up their service as an IdP, but I did find this Auth0 doc. I'd have to test, but it looks like you'll need to set up a FusionAuth lambda to reconcile the user data.

Hope this helps.

Hiya,

I'm glad you were able to make the device grant work.

I looked in the issues list and found this one: https://github.com/FusionAuth/fusionauth-issues/issues/248 which seems similar but maybe not exactly what you are looking for. If it is, please vote for it.

If it isn't, I'd encourage you to file an issue explaining exactly what you'd like, so that others can give feedback. We can't commit to timelines or implementations (unless you engage us for support or professional services) but definitely look at the number of votes for features when planning our roadmap.

At this time I'm not aware of any plans to store/display how many devices are linked to a user, which means that building it out in your codebase is probably the best path forward.

You could possibly leverage the user.data field and update it right after the grant is complete. This would give you the ability to search that in Elasticsearch.

Hope this helps.

If you don't care about the possibility of duplicate users or you can handle them in your business logic (because tenants allow multiple users to have the same username or email address), you can use a globally scoped API key and just call the search API with the email address.

For example, here a script I ran after creating two 'test@example.com' users in different tenants in one FusionAuth instance: curl -H "Authorization: $API_KEY" 'http://localhost:9011/api/user/search?queryString=test%40example.com'

The API_KEY variable was a globally scoped API key (not scoped to one tenant).

This returned this json (note, I'm running the database search engine, but the results should be similar if you are running elasticsearch):

{"total":2,"users":[{"active":true,"email":"test@example.com","id":"0e3f0f4d-6795-4200-b044-9fea2437f0d2","insertInstant":1591914961640,"lastLoginInstant":1591914961678,"passwordChangeRequired":false,"passwordLastUpdateInstant":1591914961675,"tenantId":"1de156c2-2daa-a285-0c59-b52f9106d4e4","twoFactorDelivery":"None","twoFactorEnabled":false,"usernameStatus":"ACTIVE","verified":true},{"active":true,"email":"test@example.com","id":"6d145368-431b-4df1-aba4-5741bd7a9280","insertInstant":1592244970665,"lastLoginInstant":1592244970695,"passwordChangeRequired":false,"passwordLastUpdateInstant":1592244970690,"tenantId":"7b231917-733e-4347-b9e2-11915de60fc8","twoFactorDelivery":"None","twoFactorEnabled":false,"usernameStatus":"ACTIVE","verified":true}]}