[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Jeffrey Hutzelman]

On Wednesday, September 22, 2004 10:07:57 -0500 "Neulinger, Nathan" 
<nneul@umr.edu> wrote:

> I have a scenario that I'm needing to treat 5 or 6 different kerberos
> realms as equivalent for access to AFS even though they have different
> sets of users in them. Other requirement is that users not have to type
> in the full "user@realm" for acling.

Yes, CMU is doing that, with multiple sites each of which has its own realm 
and AFS cell, but which share a common user principal namespace with each 
user having a "primary" home realm.  They're using that approach to support 
new campuses which have separate infrastructure while allowing users to 
move between campuses.  I can't provide more details, since that's not 
actually my part of the university, but I bet Derrick or Chaskiel can.





> One thought I had is that I could live with regular cross-realm if there
> was some way to add "aliases" to PTS. That would solve the "regular
> userid for the acl" problem and eliminate #2 above in lieu of just using
> regular cross realm support. Basically, allow a PTS ID to have multiple
> possible principal names, so that "nneul" would also be known as
> "nneul@umr.edu" and "nneul@um.umsystem.edu", with only the primary
> (short) name being returned in a ID-to-Name lookup.

I've been thinking about something along these lines for a while; in fact, 
the issue just came up on zephyr.  IMHO this is too major a feature to 
appear in 1.4 (especially since we've just begun to design it), but I do 
believe it's the right direction.


Basically, I envision augmenting the existing PTS database with a mapping 
from authentication identities to PTS entries.  Each entry in the PTS 
database would continue to have a single canonical name.  However, each 
entry would also have a set of authentication identities which correspond 
to that entry.  Each identity would consist of an authentication mechanism 
ID (name?) and a name, so that it would be possible to add new 
authentication methods without changing the interface again.  This is 
particularly interesting as rxgk makes it possible to use arbitrary GSSAPI 
or even other mechanisms.

Under this approach, the existing ptserver operations would continue to 
work as before, using the entry's canonical name only.  A new set of 
operations would be added to examine and manipulate the authentication 
identity mappings, including a lookup-by-authid operation which the 
fileserver would use in lieu of a normal name-to-id mapping.

Comments?

-- Jeff