Re: Ceph authentication/authorization paradignms

["Matt W. Benjamin" <matt@linuxbox.com>]

This approach/family of approaches is certainly the one taken by all classical Kerberized file sharing systems, including AFS, DCE, and NFSv4.

There's a lot of new work just coming to fruition now in both the AFS and NFSv4 communities (rxgk and RPCSEC_GSS, respectively) that are specifically designed to handle important next-generation multi-party authorization scenarios, and which I think we would be wise to at least have a look at.

Regards,

Matt

> > 
> > Right. But you'll either need to plug Kerberos into the
> client<->mon
> > authentication pathways, or (this would be my naive choice) have
> some
> > sort of agent that Kerberos authenticates and then gives the client
> > its CephX shared secret for authenticating with the monitors
> (without
> > the users having to get involved). Either way, there's at least a
> > little CephX integration going on, right?
> > Or am I completely off the mark with what you're trying to do here?
> 
> My thought is the former.  We'd add a new CEPH_AUTH_* type, the client
> 
> side would call into kerberos and get a kerberos ticket to pass to the
> 
> mon, and the mon would call into kerberos to authenticate it.  That
> would 
> authenticate the session.
> 
> I assume there will then be some futzing around to make things behave
> so 
> that the mon will provide the client cephx tickets for interactions
> with 
> the rest of the cluster so that *only* the mon is doing non-cephx 
> authentication.  The focus now is just to make the first step work, 
> though...
> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309