[OpenAFS-devel] struct rx_identity and compound identities

[Jeffrey Hutzelman]

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.