Hi Jérôme - Thanks for that heads up. We do actually have kerberos support through the Hadoop Auth Provider already which does incorporate support for accepting the Hadoop specific delegation tokens.
If I understand the ask properly here, it is for Knox to request the Hadoop specific delegation token that can be used directly without having to use kerberos to get it. My feeling is that acting as such a factory for sensitive credentials would not be in the interest of the Knox project. But as I said, I may be able to be convinced otherwise. thanks again! --larry On Wed, Oct 18, 2017 at 2:46 AM, Jérôme LELEU <[email protected]> wrote: > Hi, > > I just saw "Kerberos" somewhere in the discussion. I just wanted to quickly > let you know that pac4j 2.1 supports Kerberos so things may be > straight-forward after the pac4j upgrade. > Thanks. > Best regards, > Jérôme > > > On Tue, Oct 17, 2017 at 1:37 PM, larry mccay <[email protected]> wrote: > > > 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 <[email protected]> > > 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 > > > > > > > > >
