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