yeah sorry I didn't mean to imply forwarding credentials as a 1.0 requirement, just something I'd like to keep in mind.
On Thu, Jun 26, 2014 at 4:20 PM, Brian Wickman <wick...@apache.org> wrote: > I think 1.0 will just be client <-> scheduler authentication. In the > future it would be great to either delegate or forward credentials to the > Mesos sandbox, but that's not trivial and will likely require native > support from Mesos. It's not clear how one should model entities in this > environment (e.g. host principals vs service principals vs task principals) > and could even be different on a framework by framework basis. I am no > security/kerberos expert either so I'd defer to prior art here if any can > be found. > > > On Thu, Jun 26, 2014 at 3:55 PM, Alexius Ludeman <l...@lexinator.com> > wrote: > > > great! thanks for your quick reply. I saw the client support change. > > understood on authorization. Agreed that initial support could be with > > flat files. > > > > I have a well established accounting system, so my focus will likely be > > less on community solutions for managing authorization/identity. > Certainly > > I am open to making the authentication/authorization that supports those > > systems. > > > > It doesn't appear kerberos supports groups directly. In my case my > > kerberos server is backed by ldap which ideally I would want to manage > > groups rather than role/users. I don't know how specific that is to my > > use case. > > > > One other thing I would like to support is the ability to forward > kerberos > > authentication on to slave/thermos. This would allow the processes on > the > > slave to use those credentials. I'm not totally clear if this even > > possible based on my brief understanding of kerberos. > > > > thanks > > > > > > > > On Thu, Jun 26, 2014 at 2:25 PM, Brian Wickman <wick...@apache.org> > wrote: > > > > > 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 > > > > > > > > > >
