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