Hi Mohammad - I need to better understand your usecase.
It seems that you would like Knox to provide a delegation token factory type role where a service/user can authenticate to knox against LDAP or some other provider and return a delegation token without proxying a call to a backend service. So, something like a DelegationToken service instead of KnoxToken service. Considering that we go to some trouble to not leak the delegation token to clients outside of the gateway, this seems like it is at odds with some of the goals of what the gateway is trying to do. It will also likely require RPC calls from the jersey service to the backend services to request the delegation token. This will add a compile time dependency on those libraries which we currently don't have. I do assume that the trusted proxy model in Hadoop does allow us to play that role, however, given the above I don't know that it is a great usecase for Knox. I could possibly be persuaded otherwise. I'd like to hear the full usecase and how the use of the delegation tokens and managing their expiration without kerberos will ultimately be better than just leveraging the Hadoop common libraries and kerberos directly or consuming the same cluster resources with proxied calls through Knox. thanks, --larry On Tue, Oct 17, 2017 at 3:28 AM, Mohammad Islam <misla...@yahoo.com> wrote: > Hi, > We have a use case where non-Hadoop services want to utilize delegation > token instead of direct Kerberos ticket. Therefore, I'm wandering if Knox > can support this service where Knox can get delegation tokens from Hadoop > services such as HDFS, YARN, Hive, HBase etc. > This will allow the non-Hadoop services to connect to Hadoop services w/o > Kerberos ticket. > > Does Knox support this in any way/form? Otherwise, would it be a good idea > to support this? > > Regards, > Mohammad > >
