Posts made by yb98

@dan

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

@dan

Thanks for the reply.
No, this is only occurring for LDAP users. The issue is with the first browser, if I attempt to access a new OAuth linked application, because the refresh token is not valid anymore and accessing this new endpoint will cause authentication with the existing token, I will be incorrectly prompted to log in. If I am just switching between tabs, then there is no weird behaviour as it does not attempt to authenticate me.

So because I have made a new SSO session in the second browser, the existing SSO session in the first browser is no longer valid.

It seems like the fusionauth.sso cookie can no longer be base64 decoded after upgrading to a new version (it was previously decoded with base64 on version 1.28: https://fusionauth.io/community/forum/topic/1103/fusionauth-sso-cookie-s-value-is-encoded).

Is there a specific algorithm used to encrypt/encode the refresh token into a fusionauth.sso cookie? By refresh token I mean the refreshToken.token parameter returned by this api call https://fusionauth.io/docs/v1/tech/apis/jwt#retrieve-refresh-tokens. We were previously using base64 decryption to match the fusionauth.sso cookie in the browser with a specific refresh token to monitor and modify user activity.

Thanks!

Hi,

I came up with a quick test where I logged in as the same LDAP user into two different browser sessions. The first login into browser "A", produced a refresh token "A" for the user, and I was able to confirm that there now existed a session for the user when examining their sessions through the FusionAuth UI. When calling the API, I also confirmed that one refresh token was present.

However, when I logged into a second browser "B" with the same LDAP user, the refresh token "A" was replaced with refresh token "B", which corresponds to the new SSO session. This made it so that the SSO session in browser "A" was no longer tracked by FusionAuth, calling the API revealed only refresh token "B" was present. When examining the list of user sessions in the UI, only the second session was present.

Is this intentional? This would mean that only the most recent sessions for LDAP users are available inside of FusionAuth for modification or deletion. The LDAP reconcile I am using is also not setting any values related to the refresh token. Thanks!

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

@dan Thanks, I just commented.

@dan Hi Dan, thanks for the reply.
To answer your questions:

1. I am using FusionAuth version 1.28.1
2. Logout Behaviour for every configured application is set to "All Applications"
3. The user who is logging out is registered to all applications, including FusionAuth.

Could this also be due to the fact that the "logout url" for FusionAuth's oauth configuration is set to "/admin" instead of "/admin/logout"?

Thanks.

I am currently trying to trigger a global logout using the /oauth2/logout endpoint.

However, it seems that when I execute the following url: https://.../oauth2/logout?client_id=27c57f2e-1b0f-4596-b742-e7e8d7d80fa3, the user's fusionauth.sso cookie is removed and they are signed out of all Oauth 2.0 applications except for Fusionauth (which I believe relies on the fusionauth.session cookie). If however, I replace the client_id with that of FusionAuth, then I do get logged out of all applications, FusionAuth included. Only problem with the second approach is that I can no longer use any post_logout_redirect_url arguments, as the FusionAuth application's list of authorized redirect urls cannot be edited. I did come up with a partial solution by configuring my network to remove the fusionauth.sesson cookie, but that just removes the session from the browser, not the session itself.

Is this behaviour intentional? Thanks!

Hi Josh,

Thanks for the reply.

Our current use case is as follows:

1. User signs into an application (Grafana) via Oauth, this application is registered within FusionAuth
2. The user then logs out of Grafana, this should terminate their SSO session and sign them out of all applications, but it doesn't somehow. I have tried setting the logout behaviour to "All applications" but this doesn't make a difference.

To address that second point, I modified Grafana to redirect to FusionAuth's logout url (/admin/logout) which results in a global logout. This is how a global logout is achieved in Grafana it seems (https://github.com/grafana/grafana/pull/12077).

However, when the user does logout of Grafana, because they are redirected to Fusionauth's logout endpoint, if they attempt to login again (without changing tabs), they will be signed into FusionAuth. Therefore, I was thinking the post_logout_redirect_uri could be used, while it does attempt to redirect the user back to Grafana after logging out from FusionAuth, it ultimately fails as the origin of the request is not listed as one of the "Authorized redirect urls" inside of the FusionAuth application, this is why I was hoping we could modify the "Authorized redirect urls" using the API.

Hello, I was wondering if it would be possible for FusionAuth to save a user's registration information after they have logged in via LDAP?

The issue we are currently facing is that our customer's LDAP does not contain any information pertinent to a user's registration, rather, LDAP is used in this scenario for authentication only. As such, the reconcile lambda code does not modify the "registrations" attribute of the user, this field is left blank each time the user logs in via LDAP and the resulting user is created inside of FusionAuth without any registrations.

After the user account has been created inside of FusionAuth, they can be assigned roles using the UI. While these roles are saved inside of FusionAuth, it seems that the next time the user attempts to log in via LDAP, their account inside of FusionAuth gets recreated according to the reconcile lambda, as such, they have no registrations again.

Is it possible to designate the LDAP connector to perform authentication only? Or to mark a user account to not get recreated each time it uses LDAP to sign in?

I do know we can migrate the user to FusionAuth, but this will not address issues if the user's account changes within LDAP. I am also aware that there is currently an open issue to allow for the reconcile lambda to communicate with the API (https://github.com/FusionAuth/fusionauth-issues/issues/267), which would solve this issue entirely. Furthermore, it may be possible to implement our own authentication API using the generic connector, although this approach will take longer to implement.

Hello,

I am currently trying to modify the "Authorized Redirect Urls" of the FusionAuth application so that another application's post_logout_redirect_uri works as intended. Modifying the default FusionAuth application does not seem possible from the UI but it does seem possible by using the API and a PATCH command, according to documentation and this github issue: https://github.com/FusionAuth/fusionauth-issues/issues/1110.

I tried using the api call documented here: https://fusionauth.io/docs/v1/tech/apis/applications/#update-an-application, and while the response returned a 200 OK, the FusionAuth application wasn't actually updated. I then tried using the same endpoint but specified a different application, and that was updated correctly.

Does anyone know if there's any special variable I have to set inorder to enable modifications of the default FusionAuth application? I believe I am using the API correctly, since I am able to update my other Oauth 2.0 applications using PATCH, just not FusionAuth. I am also on version 1.28.1 right now. Thanks!

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

@yb98 I just figured this out, the cookie value is encoded in base 64, you can simply decode it to retrieve the actual token id.

Hello,

I was looking at the fusionauth.sso cookie and its value seems to be encoded, as I used the "jwt/refresh?userId" API endpoint to retrieve all currently active refresh tokens, and none of the tokens' ids matched with the value of the fusionauth.sso cookie. However, when I look at the value of the fusionauth.session cookie, it corresponds perfectly with the id of the refresh token for the FusionAuth session.

I am wondering why one of the session cookies corresponds to the id of a refresh token (fusionauth.session), whereas the other (fusionauth.sso) does not, perhaps one is encoded and the other is not? Thanks!

Hello,

I was wondering if it was possible for FusionAuth to provide LDAP authentication without giving FusionAuth read permissions to the directory? 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. There would be no need to gain read access to the directory in this scenario.

It seems that the current LDAP authentication process will also pull the user data from LDAP and save them into FusionAuth, hence why read permissions for the directory are given to FusionAuth.

Thanks!

Hello, I am having an issue where I have two applications registered within FusionAuth. Both applications have an OAuth 2.0 connection set up properly, and I have included a picture of both apps' configurations at the very bottom.

The issue arises when a user logs into one of the applications using OAuth, as expected they do not need to supply their credentials when logging into the other application via OAuth. However, when a user signs out of one of the applications, they are not signed out of the other automatically (their sessions is still active and they can interact with the app). I am pretty sure that by setting the logout behaviour to "All applications", the logout endpoint of all applications should be called and the user should be effectively signed out everywhere.

I have also tested this approach, with the user logging out of FusionAuth to trigger the other apps' logout endpoints, this works as intended, this leads me to believe that my "Logout URL" is correct. Does anyone know if my understanding of the "logout behaviour" is correct? Thanks!

Thanks for the reply Dan, the final outcome I was hoping to achieve using those two settings is to Kickstart with some already existing accounts, each using the same, default password. When a user attempts to log in with one of those accounts, they will be allowed to create a new password.

Hello,

I have a use case where I am launching Grafana using Kickstart, the issue is that the accounts created by Kickstart are made with a default password, I have also set passwordChangeRequired = true for each user.

For the Tenant (also modified within Kickstart), I have specified a minimum password lifetime of 1 day. The issue arises when I launch Kickstart and try to log into an account immediately, this triggers the required password change as intended, but the minimum password lifetime causes a rejection of the change, as the password was set only moments ago, during the Kickstart phase.

Effectively, I am unable to use a FusionAuth user account until 1 day after the Kickstart has completed. Is there any solution to this issue, such as not enforcing the password minimum lifetime if the user was forced to change their password?

Thanks!

Hi,

I know that we are able to log out all idle users of an application, regardless of their role, based on the "Session timeout" parameter of the Tenant. Is it possible to instead define an idle session timeout that is based on the role of the user, rather than the tenant?

ie. I have userA and userB, both of which are registered in application A. However, userA is an admin whereas userB is an editor. Inside of application A, idle admins will get logged out in 10 minutes and idle editors will get logged out in 5. Therefore, if userA idles for 10 minutes, they will get logged out, whereas userB will get logged out in 5 minutes. Is that possible?

Thanks!