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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
