Topics created by yb98

@yb98

Heya, this isn't something we document, so it is considered an implementation detail that could change at any time.

You could file an issue asking this to be codified and documented, but I'm not sure we'd do that. It's more likely we'd do something like this: https://github.com/FusionAuth/fusionauth-issues/issues/1515

Thanks for using FusionAuth!

@dan

Thanks!
I made the new issue https://github.com/FusionAuth/fusionauth-issues/issues/1907

@dan Thanks for the reply Dan, I'll go ahead and discuss this with my team before we go any further.

Just to double check, could the FusionAuth team revise this document's flow chart of the logout request if it's no longer correct? https://fusionauth.io/docs/v1/tech/guides/single-sign-on, or perhaps specify that the Logout request is specific to the FusionAuth app, not Pied Piper? Thanks.

e27f08e0-7665-46f9-a89f-f26637003a18-image.png

@jared GitHub issues are the right place for feature requests, thanks!

There's an 'additional context' section for feature requests, and you can feel free to link back to these forum posts. That can help enrich the discussion when the eng team reviews requests to prioritize them.

Cheers!

@yb98

I think what you are looking for is OAuth's back-channel logout. This is under consideration under ticket 465.

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

As a workaround, you would have to use a backend (or another environment that can appropriately hide credentials) and make a call to revoke the refresh token on a user.

I may be misunderstanding your workflow, but I believe the above should point at a possible solution.

Thanks,
Josh

@pleymor yeah, it is slightly tricky, you can try decoding it here: https://www.base64decode.org/, you will get some gibberish, but the refresh token will be a substring of the decoded token. The length of the decoded token may also vary depending on your browser.

You should be able to use the LDAP connector but when configuring at the tenant, set Migrate User to false.

That will ensure that the user data doesn't migrate to FusionAuth. I realize this doesn't address your desire to not grant FusionAuth read credentials. Feel free to file a feature request for that specific feature: https://github.com/fusionauth/fusionauth-issues/issues

Ideally, a user would attempt to log in with their LDAP credentials into FusionAuth, and then FusionAuth would forward these credentials to LDAP for authentication.

If this is a requirement, you could do this using a lightweight JSON API you write which talks to LDAP and a generic API connector: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/

Your application needs to kill/destroy its session in the Logout URL route.

For example, see the "Logout page route" here: https://fusionauth.io/docs/v1/tech/guides/single-sign-on/

Do your applications do that?

@yb98 thanks for explaining. I don't see an easy way to do what you want with kickstart alone, since you can't set the age of the password programmatically. The same issue would occur if you did this all via an API. The only thing I can think of is to apply the password complexity rules 1 day after system startup. A pain, I know, but that's the only path I see that would work.

Hi @yb98 -

I don't believe that this is currently possible within the Admin UI (but I will update this post if I discover otherwise). You could submit a feature request outlining your use case.

It may be possible to hook something up via the API and lots of custom code (but even then, I am not sure how this would work). You may find some insight here.

Please note, you can set these duration settings on both the tenant and the application level (example below).

roles-app-orginal.png

Thanks,
Josh