Sorry, the SET-COOKIE may be in a list of forbidden headers - I would need to track that down and if so - why it would be forbidden. Since apps like Ambari, Ranger, etc set application specific session cookies and they make it through when proxying, that shouldn't be the case.
It may also be related to whether you are setting it from the same origin/domain - forget the details here. The browser will not allow the set-cookie to take effect if you aren't the one that set it. On Mon, Jul 30, 2018 at 2:03 PM, Christopher Jackson < jackson.christopher....@gmail.com> wrote: > Hi Larry, > > Thanks for the quick response. I saw the work item for the Knox SSO logout > (KNOX-744) and reviewed that code. I was trying to avoid it for a few > reasons: > > 1) Doesn’t seem it supports jwt cookie name other then the default. I’ve > opened an issue for this https://issues.apache.org/jira/browse/KNOX-1403 > 2) It requires an additional topology which I’m not sure how I’d create > and manage on HDP since there isn’t a corresponding topology configuration > file for said service. Any thoughts on this? > > We are targeting the default form based provider and I am okay with a > logout action logging out of all services (this is what I would normally > expect from a SSO logout service). > > Unfortunately your response really didn't address my original question on > why my approach was not working. I would like to understand why the > Set-Cookie header isn’t taking effect, do you have some insight there that > you can share? > > If that approach will not work and I must use the KNOXSSOUT service can > you share what a sample configuration might look like? > > Thanks in advance. > > Regards, > Christopher Jackson > > On Jul 30, 2018, at 12:54 PM, larry mccay <lmc...@apache.org> wrote: > > Hi Christopher - > > SSO Logout is an ongoing issue for KnoxSSO and one that isn't easily dealt > with. > I'll enumerate some of the nuances and challenges and then point you to a > Knox API to do what you need - if you still want to do this. > > * depending on the IDP being used one or all of the following may be true: > - The actual IDP user session is still valid (like Okta/SAML) - so > even if you remove the cookie once you are redirected back to KnoxSSO and > thusly to the configured IDP you will be logged right back in > - For the default form based provider there will be no separate > session - so that will work as you expect > * even when the above works as you expect, do you really intend that a > logout from your application will log the user out of Ambari, Ranger, > Atlas, Zeppelin and any others that may have KnoxSSO enabled? > > If you truly want to accept the above and other nuances then you might > consider the KNOXSSOUT API which will do exactly what you are trying to do > from your logout action and you can likely call it from javascript. > You will need to add a new topology to host it since you don't want it > protected by any particular authenticaiton provider (though it may work > within the knoxsso.xml topology - would have to think through that). > > This isn't even a documented service due to the above issues with logging > out. > > The url to the call would be something like: > https://{GATEWAY_HOST}:{GATEWAY_PORT}/gateway/knoxssout/api/v1/webssout > > Hope this is helpful. > > --larry > > On Mon, Jul 30, 2018 at 12:03 PM, Christopher Jackson < > jackson.christopher....@gmail.com> wrote: > >> Hi all, >> >> I have Knox SSO configured for a custom service for the most part >> everything is working, however I’m having an issue with logging out of my >> UIs now. >> >> I have a logout service in my API which is aware of the knox jwt token. I >> have a logout rest endpoint which overwrites the token value and setting it >> to expire immediately, this essentially clears the token. The service works >> fine on its own when knox is not involved. I see that the SET-COOKIE header >> is properly updating the cookie contents when the service is called. >> However, when I access it through the knox gateway the SET-COOKIE header is >> not ultimately being received by the caller. >> >> I investigated the logs and see that the request is received by the >> gateway and forwarded to the internal service. The response from the >> internal service is working fine (wire logging shows the SET-COOKIE header >> updating the cookies values). However when the final response from the >> gateway to the caller is returned the SET-COOKIE header is no longer >> present. >> >> It seems something is happening in the gateway filters that I’m not aware >> of. Nothing in the logs stood out to me. >> >> Any suggestions on what may be the problem here? >> >> Regards, >> >> Christopher Jackson > > > >
