[OpenAFS-devel] struct rx_identity and compound identities

Benjamin Kaduk kaduk@MIT.EDU
Tue, 3 Dec 2013 22:18:02 -0500 (EST)


Back in 2010, Siomn added an rx_identity structure to store identity 
information, a structure that is similar to, but not exactly compatible 
with the PrAuthName type for which RPC-L is given in 
draft-brashear-afs3-pts-extended-names (finalized after the addition of 
rx_identity).

There's also infrastructure in place for using rx_identitys for (e.g.) 
SuperUser checks, a base64 encoding for entries in the UserList on disk, 
etc., so there's a clear advantage to using the rx_identity type as soon 
as possible when accepting PrAuthNames from the network.  (The conversion 
is pretty easy.)  However, the current draft-wilkinson-afs3-rxgk-afs 
defines a token format with a list/array of PrAuthNames, the result of the 
various token-combining operations.  It's not entirely clear how to 
translate a list (or more complicated structure!) of PrAuthNames into the 
rx_identity world; on the one hand, a list of PrAuthNames could be 
directly translated into a list of rx_identitys; on the other hand, the 
list of PrAuthNames in some sense represents a single identity.  Yet there 
is not a clear way to represent a compound identity of this form in a 
single rx_identity structure.

Before I looked closely at the rx_identity bits, I had started to 
implement similar functionality using PrAuthNames directly -- the 
structure is essentially parallel to the existing rx_identity API, but 
with the addition of routines to handle arrays of names.  I could add 
similar functionality to the rx_identity API, but it seemed worth checking 
if there was prior work in this area.

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.

-Ben