Hi Andreas - I am pulling this into the public lists for visibility and possibly additional insights from our community.
This sounds like an interesting usecase. I think that I need to understand the architectural aspects a bit more however. It seems to me that you have the following: 1. Custom services (REST I assume) that are higher level business type APIs encapsulating the use of the lower level APIs through Knox 2. Users that are authenticating via KnoxSSO presumably through some custom application (need more detail here) 3. You have considered accessing the custom services through Knox in order to pass the knoxsso cookie to the backend service such that it could be used to authenticate for access to other services back through Knox I think that the above should work already but like I said, I would like to see a more detailed depiction of this deployment so that I am sure that I understand. In my mind, there are a few possibilities here and you will need something like the following inventory: * Application that is being used as KnoxSSO token source. Meaning, without a webapp for the browser to interact with the KnoxSSO cookie will not be managed and presented by the browser. * Application and Knox Gateway will both need to be in the same domain in order for the cookie to be presented to the web service calls - which I assume are coming from JS calls in the application * Each custom web service will require a service definition in order for Knox to be able to proxy access to them [1] * The cookie should pass through to the proxied service by default along with a user.name or doas query param that indicates the identity of the gateway authenticated user * A topology that hosts the cluster services that your web services will need access to that is protected by the SSOCookieProvider [2] The assumptions about the "application" above need to be verified and if inaccurate, we need to understand who is managing the cookie. There may be alternative approaches that we can use if this isn't quite right. Thank you for your interest and contributions to Apache Knox! Hope this is helpful. --larry 1. https://cwiki.apache.org/confluence/display/KNOX/2015/12/17/Adding+a+service+to+Apache+Knox 2. http://knox.apache.org/books/knox-0-13-0/user-guide.html#SSO+Cookie+Provider On Wed, Nov 29, 2017 at 8:50 AM, Hildebrandt, Prof. Dr. Andreas < [email protected]> wrote: > Dear Larry, > > thank you for the quick work on the patch! This is really great news! Now, > we have a followup question. > > Our use cases require us to deploy several web services on the cluster. > These services are supposed, according to the security concept, to go > through knox to interact with the Hadoop cluster (e.g., to query hbase). > The question we try to solve right now is how to authenticate the web > services with knox. The security concept prevents us from using functional > users and proxy user capabilities here. > > After long discussions with Alexandru and a lot of back and forth, we > think that the best solution would be to put the web services behind knox, > i.e., the user would connect to a knox endpoint which serves as a proxy for > the web service. This seems simple enough. But we would need to forward, to > the web service, a token that it can later use to authenticate against knox. > > As far as we can tell, when the user has authenticated with knox against > our OpenID Connect provider, knox establishes a hadoop-jwt cookie which is > later used for authentication. It seems to us that if we could forward that > cookie from knox to the web service backend, the web service could later > use that cookie to talk to, e.g., hbase through knox. > > Is that assumption correct? Is there any way we could achieve this in > knox? If it requires patching the source code, could you give us a pointer > what the correct place would be? > > I hope this explanation makes some sense! > > Best regards, > > Andreas > >
