Closed GuiTeK closed 7 months ago
GuiTeK
commented
2 years ago Any news on this issue?
I just tested OpenSearch 1.0.0 and 1.1.0 and the issue is still present.
The only way to work around it is to delete cookies, which is a nightmare from an UX point of view/usability of the tool.
The JWT expiry setting could maybe be a workaround for this issue, but unfortunately this feature also has a bug: https://github.com/opensearch-project/security/issues/1448
GuiTeK
commented
2 years ago cc @dblock just so you're aware of it as I believe it is a rather high impact bug.
davidlago
commented
2 years ago Thanks for the report, @GuiTeK. Although not a security vulnerability, I agree that this is painful from the user experience standpoint. The team has not had time to look into it yet, but I've removed the untriaged label to make sure we have it on the list of issues ready to take on.
GuiTeK
commented
2 years ago Thank you for your reply @davidlago!
Related issues (although the root cause is not the parameters described in these two issues):
rmelilloii
commented
2 years ago Hello, @GuiTeK all good!? Did you find a solution to this issue? I am currently validating the downgrade of the ES plugin "opendistro_security" from: 1.13.1.0 to: 1.13.0.0. Keeping the Kibana plugin as it is. It works, at least did not break anything. I will proceed with the same for my clusters and see how it behaves. Thanks for the info regarding OpenSearch versions.
rmelilloii
commented
2 years ago Hello, @GuiTeK all good!? Did you find a solution to this issue? I am currently validating the downgrade of the ES plugin "opendistro_security" from: 1.13.1.0 to: 1.13.0.0. Keeping the Kibana plugin as it is. It works, at least did not break anything. I will proceed with the same for my clusters and see how it behaves. Thanks for the info regarding OpenSearch versions.
Replying to self: ended up with: Kibana 1.12 (7.10.0) + opendistroSecurityKibana 1.13.0.0 My case with multiple Tenants suffers a lot fo the lack of real support to them + the session/cookie issue.
With this combination, I can finally see the 1hour timeout (from Azure). Before was a matter of 15 min or less.
But I feel that it will not be enough. So maybe next will try to change my infra (load balancer/request flow) or test with latest Opensearch version.
I guess that everyone is off for the year, is that right? Cheers!! :)
mvanderlee
commented
2 years ago We observed this behaviour when the session keepalive is set to true. Setting it to false fixed it.
In dashboards.yml
opensearch_security.session.keepalive: falseHowever, we found another issue regarding to SAML timeouts. The IDP provides a expiry time, but OpenSearch only honors a specific option in the SAMLResponse. Auth0 for example sends it via a different option. Not sure who is in the wrong here. But in our case the work-around was to set the jwt.expiry setting manually
https://github.com/opensearch-project/security-dashboards-plugin/issues/159#issuecomment-1022438420
sandervandegeijn
commented
2 years ago Confirmed with both saml and oidc
rmelilloii
commented
2 years ago Hello hello! Forgot to post back. I ended up with normal settings (exactly like the official docs) no fancy stuff, normal versions all around. But, I use load balancers, previous person had several ÉS node type under the LB and kibana was pointed to this LB for auth. After pointing to a single client node it never happened again. I didn’t test with multiple endpoints, but it is not really required for me and I am moving to Opensearch. Will test there ;) Cheers and thanks for all the ideas.
mhoydis13
commented
2 years ago This is still an issue for anyone using openid_auth_domain
sandervandegeijn
commented
2 years ago Yip. Tried different ttl values and combination of settings. Problem still persists
mhoydis13
commented
2 years ago This issue is still present in version 2.1.0
sandervandegeijn
commented
2 years ago Confirmed and very annoying.
SakuraAxy
commented
2 years ago I have the same problem
sandervandegeijn
commented
2 years ago Any news on this one? This is one of the reasons I can't migrate an Elastic cluster to Opensearch because the team doesn't want tot deal with this session error.
FryggFR
commented
1 year ago Hello,
I have the same problem with Azure AD
stephen-crawford
commented
1 year ago [Triage 1/30/2023] This issue seems to be related to the cookie storage and potentially the access & refresh tokens expiring. We are passing a token but it does not have a good method of dealing with expiration between front-end and backend systems. @davidlago could you link this to the to-be-created ticket for session management so that this can be a considered use case. Thank you.
Also linking a pair of associated issues
jperhamcatchteam
commented
1 year ago Hello,
I have the same problem with Azure AD
Also running into this issue with Azure AD. I have not found a way to resolve this without manually clearing cookies for the issue browser.
Beeez
commented
1 year ago Same problem @jperhamcatchteam
Are there any changes that can be made in the meantime to resolve this? Running Azure AD SSO as well and having to clear cookies to get back in.
K3ndu
commented
1 year ago Any updates about this? Seems ridiculous that such issue isn't fixed in two years...
sandervandegeijn
commented
1 year ago It got better in the last releases, I'm not seeing 401 error pages anymore for our openid-based installs. That being said, if the session expires and the flow to refresh the tokens is triggered you don't end up at the same screen where you left. That is still quite annoying.
tr0k
commented
1 year ago We can still observe this issue in OpenSearch v2.7.0.
mkhpalm
commented
11 months ago We have this issue with v2.8.0 using gitlab as our IDP and its 2 minute token sessions. As one can imagine it renders using dashboards with OIDC fairly unusable.
jochen-kressin
commented
11 months ago Hi there,
I'm able to reproduce this. While I do not get the 500 error (but as mentioned in previous comments, this seems to have been improved in more recent versions), I am redirected back to the IdP even though my token is still valid.
I believe this line is the offender: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/session/security_cookie.ts#L71 That validate function is used when configuring Hapi's cookie.
if (sessionStorage.expiryTime === undefined || sessionStorage.expiryTime < Date.now()) {
return { isValid: false, path: '/' };
}session.expiryTime is set when the cookie is first created, and it is extended on each authenticated request if opensearch_security.session.keepalive is set to true. But keepaliveonly extends the cookie when there is an actual request - so if the "session" timeouts between requests, it won't help.
So where does that value come from?
In the case of OIDC, here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/openid/routes.ts#L197
OIDC also checks the claim for an expiration time, which is then also correctly set and validated. But I believe expiryTime takes precedence in the cookie's validate function.
For SAML, this is handled a bit differently. If there is an expiration set in the IdP payload, that value is used as expiryTime. At least as long as that claim is called 'exp'). But then again, if the 'keepalive' setting is true, that value will be overridden by 'opensearch_security.session.ttl': https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/auth/types/authentication_type.ts#L158 This may partly explain the issues reported in https://github.com/opensearch-project/security-dashboards-plugin/issues/159
If I'm correct, this issue should happen after after the time of the last request + whatever seconds (or rather milliseconds) are defined in opensearch_security.session.ttl...
sandervandegeijn
commented
11 months ago A fix would be welcome, thanks for the research. Bug is still present in 2.11.
SergioIbIGZ
commented
9 months ago I am having same issue with OIDC and Dashboards 2.11 :( After 10 minutes the token is expired, and the users receiving 401 codes.
jochen-kressin
commented
9 months ago Pardon the delay on this, I will try to come up with a solution and post an update here.
SergioIbIGZ
commented
9 months ago Hello @jochen-kressin Can you share with us some updates about the issue? Many thanks for all your work, we are very grateful :)
jochen-kressin
commented
9 months ago @SergioIbIGZ Not much to share yet, investigating if we can just remove the session.ttl setting.
If you're using SAML, for now you may be able to fix the problem by just setting
opensearch_security.session.keepalive to false, as mentioned here: https://github.com/opensearch-project/security-dashboards-plugin/issues/828#issuecomment-1022442439
If there is an exp property coming from your IdP, this will then be used. Setting keepalive to false prevents that from being overridden with whatever you have in session.ttl.
SergioIbIGZ
commented
9 months ago Hello, Thanks for your response. No, we are NOT using "jwt"; we use "openid" auth. But the error/problem is the same as described in this issue (IMO, maybe I am wrong). For example:
[2023-12-14T11:27:07,592][INFO ][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [tip-master-1] Extracting JWT token from eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJYRTk1NDQ0IiwiY291bnRyeSI6IkVTUCIsInJvbGVzIjpbIkJCVkFfSE8tVklFV0VSX0NUSSJdLCJraWQiOiJyc2ExIiwiaXNzIjoiaHR0cHM6XC9cL2lkcC5saXZlLmdsb2JhbC5wbGF0Zm9ybS5iYnZhLmNvbVwvb2lkY1wvIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiWEU5NTQ0NCIsImdpdmVuX25hbWUiOiJTRVJHSU8iLCJhdWQiOiIxMGMzYzhhNi0zZjc4LTQ5M2UtYTc4Ny02MTJkODcwMjFhZGQiLCJuYW1lIjoiW0V4dGVybmFsXSBTRVJHSU8gSUJBw5FFWiBET01JTkdPIiwiZXhwIjoxNzAyNTUyMTU1LCJpYXQiOjE3MDI1NTE1NTUsImp0aSI6IjQxZGM0ZGViLThmMjMtNDUwYi04OTIzLTc1ZjM3ZjM5NWI4NiIsImVtYWlsIjoiU0VSR0lPLklCQU5FWi5DT05UUkFDVE9SQEJCVkEuQ09NIn0.mwMA0tnhvOPK14kY39MjPawYiklH3TlnHMwBM63K8AABfAIFtz-Ra_8uwy3AfHODKdTzDhOigYU5oFNJlVoudnzRAZek7uDk2YUsYRb3of4zIKJt3tBPkaHOrYOGHUGIQsgeX3kNQewKMPIvmiLgGw-r0Ep5kKbm228TRXhlbWOt_Y_TDj1KqF5SCv2rkr60wiJVt19nPSbzK2WlLhkE_227ywC1gwo9N1lvSH6qoO82o4If75O4L0ddO6crvaE97amgeCxi9jaI6_QM0U9lSX9kGoAvK1kb0ik90NJGnaVBqetw-WWVykZMsxUFDL8dlDP8eMNCRCOwayrDM2_EUQ failed
com.amazon.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token has expiredIn my case the token expires in only 10 minutes and it is quite painful (I think that 600 seconds is the max value for JWT exp default value).
Edit: that log is from opensearch. I have found another error:
[2023-12-15T11:26:03,606][WARN ][stderr ] [tip-master-4] WARNING: Invalid cookie header: "Set-Cookie: _abck=4E25B1E3D81AE7AB946634EADA237E7B~-1~YAAQ7ZrYF5yY/mOMAQAAVPM5bQtr3G/qB0l+o+nrSO76lad2w5YcwovSgCUxts5zstjN45ES23olMQgB7bQmkxit3EdzB1NiFo3lP5v8zLmo8uDXwwol0r9Uw0/bah9t57oVWqUrEpQVJZb2wMEgylCwOQ7zHaZCYyYxk8gLBS5iBzWIcKvhePXIrLw/6NVsODI0cOImJ3rjCfY9FW2CWf7GbD4POuQdgEtR4IRGs9+hPaHe2U6WgPZqEcyPjvyc9Drzh8sXymqnJzwar67oTz9v9arJLVdbJt5p3A0O6boOe+Tz3QNo2JUwAk+7nX/b6jM6I8566S5Dsps4IlDW8Tv9i3w/DdZAYcCVBEjnNb+GBpH/RftcVJE=~-1~-1~-1; Domain=.acme.com; Path=/; Expires=Sat, 14 Dec 2024 11:26:03 GMT; Max-Age=31536000; SameSite=None; Secure". Invalid 'expires' attribute: Sat, 14 Dec 2024 11:26:03 GMTMaybe I must open an issue in OpenSearch Security repo issues?
Thanks :)
jochen-kressin
commented
9 months ago @SergioIbIGZ Reading your log message, and also going through the other logs mentioned in this issue, I may have been to quick with my problem analysis above.
Could you maybe post your opensearch_dashboards.yml settings related top openid here?
Also, your opensearch_security.session settings would be interesting to see.
Do you know if your tokens has any expiration time defined?
SergioIbIGZ
commented
9 months ago Hello again, Our openid token TTL is 12 hours. This is my opensearch_dashboards.yml settings:
opensearch_dashboards.yml: |
# OPENID CONFIG
opensearch_security.auth.type: "openid"
opensearch_security.openid.connect_url: "https://idp.live.*****"
opensearch_security.openid.client_id: "******************************"
opensearch_security.openid.client_secret: "*********************************"
opensearch_security.openid.base_redirect_url: "https://search.****"
opensearch_security.openid.scope: "openid profile email"
opensearch.ssl.verificationMode: none
opensearch_security.openid.refresh_tokens: true
opensearch_security.session.keepalive: false
opensearch_security.session.ttl: 43200000
opensearch_security.cookie.ttl: 43200000
logging.verbose: "true"As additional info, I asked to my OPENID - IDP admins team about this log that I show you before:
[2023-12-15T11:26:03,606][WARN ][stderr ] [tip-master-4] WARNING: Invalid cookie header: "Set-Cookie: _abck=4E25B1E3D81AE7AB946634EADA237E7B~-1~YAAQ7ZrYF5yY/mOMAQAAVPM5bQtr3G/qB0l+o+nrSO76lad2w5YcwovSgCUxts5zstjN45ES23olMQgB7bQmkxit3EdzB1NiFo3lP5v8zLmo8uDXwwol0r9Uw0/bah9t57oVWqUrEpQVJZb2wMEgylCwOQ7zHaZCYyYxk8gLBS5iBzWIcKvhePXIrLw/6NVsODI0cOImJ3rjCfY9FW2CWf7GbD4POuQdgEtR4IRGs9+hPaHe2U6WgPZqEcyPjvyc9Drzh8sXymqnJzwar67oTz9v9arJLVdbJt5p3A0O6boOe+Tz3QNo2JUwAk+7nX/b6jM6I8566S5Dsps4IlDW8Tv9i3w/DdZAYcCVBEjnNb+GBpH/RftcVJE=~-1~-1~-1; Domain=.acme.com; Path=/; Expires=Sat, 14 Dec 2024 11:26:03 GMT; Max-Age=31536000; SameSite=None; Secure". Invalid 'expires' attribute: Sat, 14 Dec 2024 11:26:03 GMTTheir opinion is that it can be a issue similar to this:
https://www.lenar.io/invalid-cookie-header-invalid-expires-attribute/ https://github.com/aws/aws-sdk-java-v2/issues/2421 https://stackoverflow.com/questions/39699123/it-seems-that-set-cookie-having-an-expiration-format-mon-25-sep-2017-134002-g
But personally I have searched related issues in Opensearch github.com and I found nothing. So it sounds weird to me.
jochen-kressin
commented
9 months ago @SergioIbIGZ Hmm I've never seen that error before. Does it show up on each request? And the name "_abck" - have your renamed the dashboards cookie to be called that, or is it maybe some other cookie that is attached to the request?
I'm starting to think this may have to do with your backend auth configuration. Your Dashboards config seems correct to me. I was going to say you may need to set keepalive to true, but even if it is false, the plugin should not invalidate the token after 10 minutes - it should use the 12 hours you've defined in session.ttl.
Another thing I noticed but am not 100% sure about: in some cases you may need to add offline_access to the scope config option in order for the IdP to refresh a token. E.g. my local instance of Keycloak requires it, and I also have to add offline_access in Keycloak's Scope Mapping.
But I don't think that explains your original problem.
SergioIbIGZ
commented
9 months ago Hello @jochen-kressin . Thank you for your answers. I tried adding "offline_access" to the scope but our IDP does not work, is invalid for it :(
Apart of this, yesterday I made a interesting POC. I installed the last version of OpenSearch (2.11) with the latest version of OpenSearch Dashboards 2. Using Helm and applying the exact SAME config as we use in OpenSearch 1.x, including OpenID.
For my surprise, in OpenSearch 2.x logs appears the cookie expire invalid error, but in OpenSearch Dasboards 2.x does NOT appears the BadCredentialsException that exist in the 1.x version. For your reminder:
[2023-12-14T11:27:07,592][INFO ][c.a.d.a.h.j.AbstractHTTPJwtAuthenticator] [tip-master-1] Extracting JWT token from eyJraWQiOiJyc2ExIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJYRTk1NDQ0IiwiY291bnRyeSI6IkVTUCIsInJvbGVzIjpbIkJCVkFfSE8tVklFV0VSX0NUSSJdLCJraWQiOiJyc2ExIiwiaXNzIjoiaHR0cHM6XC9cL2lkcC5saXZlLmdsb2JhbC5wbGF0Zm9ybS5iYnZhLmNvbVwvb2lkY1wvIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiWEU5NTQ0NCIsImdpdmVuX25hbWUiOiJTRVJHSU8iLCJhdWQiOiIxMGMzYzhhNi0zZjc4LTQ5M2UtYTc4Ny02MTJkODcwMjFhZGQiLCJuYW1lIjoiW0V4dGVybmFsXSBTRVJHSU8gSUJBw5FFWiBET01JTkdPIiwiZXhwIjoxNzAyNTUyMTU1LCJpYXQiOjE3MDI1NTE1NTUsImp0aSI6IjQxZGM0ZGViLThmMjMtNDUwYi04OTIzLTc1ZjM3ZjM5NWI4NiIsImVtYWlsIjoiU0VSR0lPLklCQU5FWi5DT05UUkFDVE9SQEJCVkEuQ09NIn0.mwMA0tnhvOPK14kY39MjPawYiklH3TlnHMwBM63K8AABfAIFtz-Ra_8uwy3AfHODKdTzDhOigYU5oFNJlVoudnzRAZek7uDk2YUsYRb3of4zIKJt3tBPkaHOrYOGHUGIQsgeX3kNQewKMPIvmiLgGw-r0Ep5kKbm228TRXhlbWOt_Y_TDj1KqF5SCv2rkr60wiJVt19nPSbzK2WlLhkE_227ywC1gwo9N1lvSH6qoO82o4If75O4L0ddO6crvaE97amgeCxi9jaI6_QM0U9lSX9kGoAvK1kb0ik90NJGnaVBqetw-WWVykZMsxUFDL8dlDP8eMNCRCOwayrDM2_EUQ failed
com.amazon.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token has expiredSo when a user log-in in OpenSearch Dashboards 2.x, the 401/Unauthorized error 10 minutes after the login, does NOT occurs. The session is kept alive or maybe the token is able to be refreshed.
The conclusion for me is that "com.amazon.dlic.auth.http.jwt.keybyoidc" is different, o maybe another version, in 2.x and it works properly with our IDP and its cookies.
Can you tell me about it? Is there possible to study a possible fix for 1.x?
Thanks for your time and dedication :)
sandervandegeijn
commented
7 months ago Any updates on this one? Would really love for this to be solved in 2.12. This one is very annoying :)
stephen-crawford
commented
7 months ago Hi @sandervandegeijn, I don't know of any active efforts to fix this. I will remove the Triaged label so the matainers can review this issue during the Triaging meeting later today and add an update below.
stephen-crawford
commented
7 months ago [Triage] Seems like this is still an issue and something is going wrong with the behavior when using external IdPs and dashboards. Based on the discussion any data is lost from the active session if a redirect to refresh the token is executed during making a changes. I.e. making filters and then a token refresh causes you to lose all of the filters. We should try to prioritize this based on the long life of this issue.
derek-ho
commented
7 months ago @GuiTeK @sandervandegeijn I am beginning to pick this up, and new tho this space. Can you share your settings for opensearch_security.session.ttl and opensearch_security.session.keepalive as well as any settings from the saml provider that you have, such as the expiry/ assertion lifespan? I am seeing some behavior on my local and not sure if it is what you are talking about - is the bug that after some certain amount of time OSD is re-routed back to the saml provider to re-authenticate even though the assertion should still be valid? I do see this on my local, but I do not see the 401's/error pages that you folks were mentioning?
sandervandegeijn
commented
7 months ago We are at the defaults. I'm not running SAML anymore, but with openid it's basically the same thing. Leave the dashboards app for 30 minutes or so, click on the next page and it will kick off the authentication flow (which is better than it was in the past, then it would just throw the 401 and be done with it). This is fast and another problem is dat it loses all the state that you had like filters. :)
andrew-landsverk-win
commented
7 months ago I am doing the same as @sandervandegeijn - using OpenID via Azure AD and the same thing happens to us.
derek-ho
commented
7 months ago Understood. I do think there is a bug/confusion here regarding the whole management of sessions. Would you folks be able to provide some feedback on this issue? https://github.com/opensearch-project/security-dashboards-plugin/issues/1711? Additionally a few questions/comments for you (I am still trying to wrap my head around it so there will be more to come!)
keepalive to false and opensearch_security.session.ttl to match the expiry of the assertion/exp field? This might not solve for cases in which the exp is actually short lived (that may be a separate issue of doing the best to preserve URls, filters, etc.), but this should solve for the redirection. I believe the defaults here: https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/index.ts#L78 are the root case of thissandervandegeijn
commented
7 months ago Actually, I checked, I set the timeouts to one day. Removed the settings, so now I'm on the defaults. Will test again.
I do not understand why you would override the timeout from the IDP. If you need it shorter, you should fix it at the IDP's side I would suppose?
This also seems related: https://github.com/opensearch-project/security-dashboards-plugin/issues/159#issuecomment-1022438420
SergioIbIGZ
commented
7 months ago Hello again, Probably this information is not useful here but I would like to share it with you.
As I said in https://github.com/opensearch-project/security-dashboards-plugin/issues/828#issuecomment-1862341165 in our case, the IDP and its cookie is configuring to try to set 12 hours as Dashboards session ttl. But at the end that session is closed with a 401 error after only 10 minutes (I don't know why in our case is only that time).
Our parcial workaround is configuring this settings:
opensearch_security.openid.refresh_tokens: false
opensearch_security.session.keepalive: true
opensearch_security.session.ttl: 180000
opensearch_security.cookie.ttl: 180000As you can see, the session ttl is only 3 minutes. But what we achieve with that is a browser "auto-reload" to dashboards login each that time. It is annoying but doing this, the 401 error does NOT occurs. But the users have to save its work continuosly to don't lose it, or course.
Thanks!
sandervandegeijn
commented
7 months ago Actually, I checked, I set the timeouts to one day. Removed the settings, so now I'm on the defaults. Will test again.
I do not understand why you would override the timeout from the IDP. If you need it shorter, you should fix it at the IDP's side I would suppose?
This also seems related: #159 (comment)
Problem persists.
atbohmer
commented
7 months ago From a user perspective: mighty irritating! Had a discover window open, did some work, went to fetch a coffee, back and a session reset in front of my eyes. All selections and filtering gone. So back to the ELK setup for daily work.
derek-ho
commented
7 months ago Hello again, Probably this information is not useful here but I would like to share it with you.
As I said in #828 (comment) in our case, the IDP and its cookie is configuring to try to set 12 hours as Dashboards session ttl. But at the end that session is closed with a 401 error after only 10 minutes (I don't know why in our case is only that time).
Our parcial workaround is configuring this settings:
opensearch_security.openid.refresh_tokens: false opensearch_security.session.keepalive: true opensearch_security.session.ttl: 180000 opensearch_security.cookie.ttl: 180000As you can see, the session ttl is only 3 minutes. But what we achieve with that is a browser "auto-reload" to dashboards login each that time. It is annoying but doing this, the 401 error does NOT occurs. But the users have to save its work continuosly to don't lose it, or course.
Thanks!
@SergioIbIGZ If I am reading your situation correctly, it seems like you have issues on 1.x line, but the issue is not on 2.x line? Unfortunately we do not develop for 1.x anymore anymore, and would recommend you upgrade to 2.x. https://opensearch.org/releases.html. That being said, I am going to shortly post a summary on this issue and close it out with the merging of a recent PR. Feel free to open another issue if something that is affecting 2.x comes up, or if I am not understanding your problem correctly. Thanks!
derek-ho
commented
7 months ago This issue is getting a little long in the tooth and it's getting hard for me to diagnose/help individual folks with their problems. That being said, it seems to me like there's several issues mentioned, some related, and some not, and some based on opendistro, which may or may not be out of date. From what I see the issues are:
I will be closing this issue with the merging of https://github.com/opensearch-project/security-dashboards-plugin/pull/1773. Anybody please feel free to open a follow-up issue with detailed reproduction steps (IDP, opensearch_dashboards.yml settings, opensearch security backend config, etc.) so I can better address individual concerns. Thanks!
Additionally, we have a RFC https://github.com/opensearch-project/security-dashboards-plugin/issues/1711 to discuss confusion around some of the settings. If anyone has any thoughts, please leave them there, thanks!
@GuiTeK @rmelilloii @sandervandegeijn @mhoydis13 @SakuraAxy @FryggFR @jperhamcatchteam @Beeez @K3ndu @tr0k @mkhpalm @SergioIbIGZ @andrew-landsverk-win @atbohmer @jochen-kressin
sandervandegeijn
commented
7 months ago Thanks for the effort Derek, we haven't made it easy for you ;)
SergioIbIGZ
commented
7 months ago Hello again, Probably this information is not useful here but I would like to share it with you. As I said in #828 (comment) in our case, the IDP and its cookie is configuring to try to set 12 hours as Dashboards session ttl. But at the end that session is closed with a 401 error after only 10 minutes (I don't know why in our case is only that time). Our parcial workaround is configuring this settings:
opensearch_security.openid.refresh_tokens: false opensearch_security.session.keepalive: true opensearch_security.session.ttl: 180000 opensearch_security.cookie.ttl: 180000As you can see, the session ttl is only 3 minutes. But what we achieve with that is a browser "auto-reload" to dashboards login each that time. It is annoying but doing this, the 401 error does NOT occurs. But the users have to save its work continuosly to don't lose it, or course. Thanks!
@SergioIbIGZ If I am reading your situation correctly, it seems like you have issues on 1.x line, but the issue is not on 2.x line? Unfortunately we do not develop for 1.x anymore anymore, and would recommend you upgrade to 2.x. https://opensearch.org/releases.html. That being said, I am going to shortly post a summary on this issue and close it out with the merging of a recent PR. Feel free to open another issue if something that is affecting 2.x comes up, or if I am not understanding your problem correctly. Thanks!
That's right @derek-ho. I already tested it in 2.x and my issue is not present. So I will suggest to update to that version. Thanks a lot :)
Describe the bug 1 hour after login, Kibana will show one of these 2 errors instead of the requested page:
{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}{"statusCode":401,"error":"Unauthorized","message":"Response Error"}The only way to work around this issue is to delete cookies.
To Reproduce Steps to reproduce the behavior:
{"statusCode":401,"error":"Unauthorized","message":"Response Error"}instead of showing the requested page{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}when manually going to the root Kibana domainNote: to create the Okta app, I followed the instructions here: AWS - Add Single Sign-On (SSO) to Open Distro for Elasticsearch Kibana using SAML and Okta.
Expected behavior The internal JWT created by OpenDistro (I'm not sure exactly what component creates it) should be automatically renewed and Kibana shouldn't throw an error (either 401 or 500) when visiting a page 1 hour or more after initial login.
Logs ES Node Logs
Kibana Server Logs
Host/Environment (please complete the following information):
opendistroforelasticsearch-kibana): 1.13.2