Yes, that is where I have it. I think it is a bug.

Hi @brian_ls

I have included the available documentation below; though I must admit, we could likely use a tutorial or two of Kafka in action.

https://fusionauth.io/docs/v1/tech/integrations/kafka/#overview
https://fusionauth.io/docs/v1/tech/messengers/kafka-messenger/
https://fusionauth.io/docs/v1/tech/apis/messengers/kafka/

As I am not a Kafka expert myself, but I will log an issue on our issues board regarding the need for an example tutorial. Based on what I have read, you would configure a messenger and use Kafka to communicate using FusionAuth. Or use Kafka as an integration point, and yes, webhooks would be involved.

I will discuss this with my colleagues and let you know if I discover anything further.

Thanks,
Josh

@fred-fred,

I will try to offer a few pointers, but as always, the juice is in the details. If you find yourself wanting more guidance, we do offer support plans to assist with implementation (not an upsell, just an option if needed per business requirements )

You could add Your Custom SSO as OpenID Connect Identity Provider. My thinking is that you could have FusionAuth issue an access token by visiting a login page and have your custom SSO accept that token, verify it, and then offer access to all the applications behind its "gate". In the picture from the documentation, replace pied piper with custom sso login button. Disclaimer: I may have to think more on this one to see if it best applies.

If you want to follow OIDC you will want to review the endpoints found below:
https://fusionauth.io/docs/v1/tech/oauth/endpoints/

I will see if @dan, my colleague, has any other directional pointers to add or if I anything else pops to mind.

Thanks,
Josh

 
 
 

Other Resources

Many people use connectors when doing a staged migration of a system (documentation here) as you are. That would be a workflow to consider and educate yourself on. Specifically, there is a section in the documentation on Authentication that might be helpful to you.

Finally, you could peruse our migration guide, to review for tips as you move forward. https://fusionauth.io/docs/v1/tech/guides/migration/

I end up using a docker image of mailcatcher.

I use the default docker-compose.yml, but use this docker-compose.override.yml:

version: '3' services: mailcatcher: image: yappabe/mailcatcher ports: - "1025:1025" - "1080:1080" networks: - mailcatcher search: image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1 environment: cluster.name: fusionauth bootstrap.memory_lock: "true" discovery.type: single-node FUSIONAUTH_SEARCH_MEMORY: ${FUSIONAUTH_SEARCH_MEMORY} ES_JAVA_OPTS: ${ES_JAVA_OPTS} # Un-comment to access the search service directly # ports: # - 9200:9200 # - 9300:9300 networks: - search restart: unless-stopped ulimits: memlock: soft: -1 hard: -1 volumes: - es_data:/usr/share/elasticsearch/data fusionauth: depends_on: - search - mailcatcher environment: SEARCH_SERVERS: http://search:9200 SEARCH_TYPE: elasticsearch networks: - mailcatcher - search networks: search: driver: bridge mailcatcher: driver: bridge volumes: es_data:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

Hey @joshua thank you so much
I spent the weekend on it, and I have been successful. Honestly, FusionAuth has been a revelation. It's extremely powerful, and because of that I struggled a bit getting to know all the features. I apologize for my previous questions... They sound a bit silly now.

I was not yet aware of both the userinfo and introspect apis, so thanks again for letting me know about them. I like the userinfo api more, although introspect does return all the claims, including iat and exp. But before I get into it, please let me describe what I did. I'm no security expert, and I'd be happy if you could vet the process at a high level to make sure I'm not doing anything blatantly naive. Once I complete my implementation, I plan to write a tutorial about Next.js + FusionAuth + Hasura.

After signing in, I grab the accessToken prop and very manually run it through jsonwebtoken.verify using the public key stored on FusionAuth and hold a reference to that object. I then add to it Hasura's custom claims, and then sign this thing using a different RSA key, known by the Hasura server. When it's time to refresh the token I simply repeat the process: decoding the token, enhancing it with custom claims and signing it again. The resulting access token is stored in session and used to talk to the server.

The next step would be trying to implement the userinfo verification api you suggested instead of manually verifying the token.

I have a couple of questions now, which I hope you can answer:

You mentioned both iat and exp are reserved. I currently use them in my enhanced token to let hasura know when it's time to expire the token. As of my current understanding, every newly signed token would have at least a new iat set. What do you think I should use to set exp? Maybe the account.expires_in prop I get from FusionAuth? The sign in process right now requires to call FusionAuth, then I would have to hit the userinfo endpoint and finally call hasura with an upsert operation in case of a new user. Wouldn't that be too chatty and slow? Would you suggest a different flow? I'm currently using 2 different key pairs in this process: the FusionAuth's application RSA256 key for the login process, and an RSA512 key to sign/verify the final access token I send to hasura. Should I just use one key? Having FusionAuth manage keys would be great, but how can I use a key managed by FusionAuth to sign a token from the outside? I wasn't able to retrieve the private key or find an api for that. Finally, is it possible to rotate keys automatically in FusionAuth like Firebase does for example?

I apologize for the long winded post and number of questions. Thank you very much for your time and kind support!

I don't know of any way to do this. You can't query on password expiration status. There's no webhook available.

This seems like a great feature request. Please file a github issue with details about your use case: https://github.com/fusionauth/fusionauth-issues/issues

The user and registration may have a username field. The username field on the user is the one that can be used to login. In general you will want to use the Search API for those types of queries rather than directly accessing the database.

The reason is because the API is documented and stable, and the database is undocumented and may change.

Hi @joshua,

Thank you for your help. At the moment we are using FusionAuth version 1.23.3. We have it deployed on Kubernetes (2 pods at the moment), and using Amazon RDS (PostgreSQL) as database.

Let me know if there's anything else that might be useful to you.

Regards,
Jordi

Hi @luke-fishman,

I have a few questions for you to see if we can get to the bottom of this.

Is this an ongoing problem or has it recently surfaced? If recently surfaced, has anything changed which would slow your queries down? For instance, have you made any architecture changes? Was this user query much faster in the recent past?

What do queries from the Admin UI look like (are they performant?)?

Other things to evaluate include the size of your database and your architecture to make sure it's right-sized for your use case.

Finally, are you seeing anything in the error and event logs in FusionAuth (or in your server) that would indicate a larger problem?

Thanks,
Josh

You will need to obtain the default tenantId from the UI.

If you are using kickstart, you have the option to set the default tenantId so that it is predictable.

Thanks for filing a github issue as well!

https://github.com/FusionAuth/fusionauth-issues/issues/1227

@trevorr,

Based on what I am seeing here, I don't believe this is an issue with FusionAuth, but if you discover something else, please let us know and we can file a bug report.

As you might have indicated, my instincts are telling me you had a popup rule blocking the required dialogs or that something in Privacy Badger does not like a combination of the "post" and something else about that URL. You could try disabling certain "privacy rules/settings" (not very familiar with Privacy Badger) to see if that alleviates your problem.

Let me know if you find anything further!

Thanks,
Josh

Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

Thanks!
Josh

Hi @nick,

We have a good overview section on why you would select/create a group in FusionAuth below and offers a helpful example.
https://fusionauth.io/docs/v1/tech/core-concepts/groups/#overview

My understanding is that groups will allow you to select a subset of users within your application(s). Very useful if you need to define roles, etc.

I hope this helps!

Thanks,
Josh

@maarten,

Glad that you got this working! If you have any other tips about how you got it working, that might help other users in a similar situation.

Glad it worked out!

Thanks,
Josh