The first step of client support is there -- we created the TRequestsTransport on the client, which uses the python requests library to do thrift-over-HTTP. There is a python package called 'requests-kerberos' that has a class called HTTPKerberosAuth that can be passed into TRequestsTransport and properly handles WWW-Authenticate negotiation.
On the server side, we'll need to add a KerberosAuthFilter that does the SPNENO/WWW-Authenticate handshake and validates/extracts the GSSContext from the authenticate header. This will need to do things like validating that the target principal is the Aurora scheduler. This says nothing of authorization though -- we'll need to agree upon a solution for managing authorization, perhaps initially just flat files or a simple mapping from user principal to accepted roles. We should also investigate existing community solutions for authorization/identity management such as Apache Shiro. Open for ideas on all fronts. I'd love to hear your input and a hand in any of the above would be welcomed and greatly appreciated. cheers, brian On Thu, Jun 26, 2014 at 1:50 PM, Alexius Ludeman <l...@lexinator.com> wrote: > hi Brian, > > I see "aurora client should support kerberos" in AURORA-515 > <https://issues.apache.org/jira/browse/AURORA-515> and I am quite > interested on the expected timeline. Is an early stage of it available? > > If you think that AURORA-515 is in the order of months away for an alpha > version then I would plan to develop it internally as I need it on a > shorter deadline. I hope we can chat about your intended design so that my > implementation could be similar and when the time comes I could swap my > local fork and use the upstream implementation. > > At this time I'll admit upfront I know very little about kerberos so I have > some learning ahead. > > thanks > lex >
