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 <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 > <mailto: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 >
