[OpenAFS-devel] struct rx_identity and compound identities

[Jason Edgecombe]

On 12/04/2013 01:22 PM, Jeffrey Hutzelman wrote:
> On Tue, 2013-12-03 at 22:18 -0500, Benjamin Kaduk wrote:
>> Any thoughts?  It seems that we (and potentially afs3-stds) may need to
>> put more thought into complex identities before the rxgk-afs document
>> (which specifies the token format) goes final.
>
> While many things are possible, the original intent for combined tokens
> was to combine a token belonging to a user with one belonging to a cache
> manager, resulting in two benefits:
>
> First, the CM can carry on communication with the fileserver on behalf
> of the user, with the user's authorizations, but using a key the user
> does not know and cannot forge.  This allows the CM to trust responses
> it gets from the fileserver and use them to manage a shared cache, while
> preventing one user from poisoning the cache for another.  For this
> usage, the combined token need have no more complex an identity than the
> original user's token.
>
>
> Secondly, the combined token was intended to have a combined identity
> which identified both the user and CM.  The "first" identity (the
> user's) would be used in exactly the same way as a simple identity -- to
> identify the user for ownership and superuser tests and to record
> authorship, and to seed the user's CPS for access control checks.  The
> "second" identity (the CM's) would be used instead of or in addition to
> the machine's IP address, to seed a host CPS.  At the fileserver end,
> this means the FS would make a new RPC in place of PR_GetHostCPS(),
> which takes a PRAuthName as an additional argument.  Beyond this, the FS
> need not do anything different from what it does today; in particular,
> everywhere a single identity is used today, the FS should use the first
> identity from a complex token.
>
> At the ptserver end, the PRAuthName argument to the new GetHostCPS call
> needs to be used slightly differently.  In particular, the PTS database
> needs to be able to distinguish an entry representing "the user with
> identity X" from an entry representing "users from the host with
> identity X".  It partially does that now, in that entries whose names
> are dotted quads have the latter meaning, while all other entries have
> the former(*).  Thus, to usefully provide authenticated host-based
> access control, we need to extend both the format of the PRDB and the
> interfaces used for creating and managing entries, and we probably need
> to define conventions for naming such entries, so that admins and users
> will know what they are.
>
> However, if we do it right...
> - The interfaces for managing group memberships don't need to change,
> since
>    a host entry is just another entry, with an ordinary name and ID.
> - Because host entries are first-class objects with IDs, they can and
> should
>    be included in the returned HostCPS, which means they should be able
> to
>    appear directly on ACLS.  This would solve a longstanding source of
> user
>    confusion with regard to host-based access control.
> - Perhaps most importantly, we don't have to implement any of these
> changes
>    in order for the fileserver to be able to accept tokens with complex
> IDs
>    and do something useful with them.
>
>
> Whatever the format for AFS's combined token IDs ends up being, it
> probably needs to allow for the possibility of additional identities,
> and be able to represent a token that has a user identity and some
> future additional ID, but not a host/CM identity.
>
>
>
> (*)Actually, there is nothing preventing a dotted-quad entry from being
> used as an ordinary user, if one happens to have that as a principal
> name.
Do the combined entries allow for you to restrict an ACL to the 
intersection of a user and host?

Thanks,
Jason