Hey Larry, Thanks again for your timely responses, and I really appreciate any insights you provide no matter how small as they give me a starting point for researching the fix myself which helps me get unblocked quickly.
Prior to this email thread I had verified the path and domain were matching on the cookies so that shouldn’t be an issue. I did another search through the code after your last email and it does look like you are preventing the setting of the Set-Cookie header (https://github.com/apache/knox/blob/fe84b04561f6131ddc0593fb811cd1bfba21316d/gateway-spi/src/main/java/org/apache/knox/gateway/dispatch/DefaultDispatch.java#L157 <https://github.com/apache/knox/blob/fe84b04561f6131ddc0593fb811cd1bfba21316d/gateway-spi/src/main/java/org/apache/knox/gateway/dispatch/DefaultDispatch.java#L157>) if I am reading that code correctly. I’m not sure why though. Based upon your comments about Ranger I looked at its service config and I see it uses a different Implementation of Dispatch: <dispatch classname="org.apache.hadoop.gateway.dispatch.PassAllHeadersDispatch”/> I will try doing this as well to see if that resolves the issue. I am wondering if there is any security considerations I may be overlooking in doing so though? Regards, Christopher Jackson > On Jul 30, 2018, at 2:09 PM, larry mccay <[email protected]> wrote: > > 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 > <[email protected] > <mailto:[email protected]>> 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 > <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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] >> <mailto:[email protected]>> 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 >> > >
