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

[Douglas E. Engert]

Yes this could work for Kerberos.

You mentioned using an arbitrary gssapi with RX. If you use this approach vs a
mapping service, you will need to support the arbitrary gssapi in the client's
kernel as well as all the services.  With the mapping service the arbitrary
gssapi is only needed for the initial acquisition of the token, and you can
use the krb5 2b tokens. An arbitrary gssapi may not give you access to the
session keys, but require you to use gs_wrap/unwrap whihc might be more
overhead then you want. There might also be more gss_name issues.

Only the initial token issuing mapping service need to be aware of the
gssapi issues introduced with arbitrary GSSAPI.


Jeff Hutzelman wrote:

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

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444