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
>

Reply via email to