authentication vs authorization was Re: [OpenAFS] 1.3.70 and aklog

Douglas E. Engert deengert@anl.gov
Tue, 17 Aug 2004 10:29:26 -0500


Sorry, I mis-typed.  A realm is an authentication domain.
I think we are in agreement.
(Thats what I get for typing mail too early in the moring.)

Jeffrey Altman wrote:

> Douglas E. Engert wrote:
> 
>> The issue is the AFS cell name is not the same as the user's realm name.
>> The K5 is using cross realm, where as in the past the krb524d could have
>> covered this up.
>>
>> This goes back to what is the difference between a realm and a cell.
>> I would argue a cell is an authorization domain, a realm is authorization
>> domain. AFS needs to be able to map a principal in a realm to an afs
>> user in it cell. By default AFS is assuming the cell name matches the
>> realm name, or if the realm-of-cell file (forgot the name) is set, then
>> the cell is in that realm. It needs more flexibility to map foreign
>> principals to local cell.
>>
>> This is a practical issue, as newer realms are coming on line which
>> don't match the older AFS cell names.
> 
> 
> I disagree with the statement that a realm is an authorization domain.

Sory, see above. I agree with you.


> A realm is an authentication domain.  Kerberos authentication provides
> an authenticated name and a trust path by which the name was 
> authenticated.  It does not provide any form of authorization UNLESS
> the Kerberos ticket contains a PAC of ACLs.
> 
> In the traditional Kerberos model, the authenticated Kerberos principal
> name would be used in an authorization exchange by the service to
> determine what that principal is allowed to use.  In the case of AFS
> the authorization database is PTS.

I agree.

> 
> I believe it is very important that the authenticated name be preserved
> for logging and because you never know when some admininstrator might
> screw up and issue jane.doe@FOO.COM to jane.doe@BAR.COM to different
> users when both the FOO.COM and BAR.COM realms are trusted by the 
> foobar.com cell.
> 

Actually they may want to do this, to map two differnet principals to the
same authorization name. ~/.k5login is an example of this.

> If there is a mapping to be applied it should be applied within the
> authorization database (ptserver) not in something that modifies
> authentication names.

OK, that would be acceptable.  I would also agrue that the krb524d
or gssklogd where principals in a k5 realm where mapped to users
in a AFS realm was in effect an extension of the PTS authorization.
Maping authentication names to a authorization name.

> 
> Jeffrey Altman
> 

-- 

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