[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: AuthzIDs or DNs, but not both
At 04:05 PM 11/15/99 -0500, Mark C Smith wrote:
>"Kurt D. Zeilenga" wrote:
>>
>> At 01:47 PM 11/15/99 -0500, Curtin, William wrote:
>> >Perhaps the use of the word INTERNAL was a poor choice. By internal I meant
>> >that the server would map the uAuthzId used for authentication into the
>> >distinguished name associated with the uAuthzId to support operational
>> >attributes, access control, etc. Is there a better way to phrase it?
>>
>> The key issue I am raising is whether or not it makes sense to have more
>> than one protocol representation of authorization principals. I believe
>> only one is necessary and that a second is an unnecessary complication.
>>
>> The fact that a server can map the uAuthzId to a DN implies
>> that the client can map a uAuthzId to a DN. Hence, there is
>> no need for the second protocol representation as the client can do
>> this mapping. We just need to describe how the mapping should be
>> done to make it generally useful.
>
>I don't think we should mandate a single algorithm to map a given kind
>of authorization ID to a DN. Why not? Because the right solution is
>likely to be site / deployment specific.
I did not mean to imply a "mandate". I want to provide a mechanism
to allow clients to represent uAuthzId as DNs to eliminate the need
for a second representation. The same mechanism can obviously apply
to other authzid scheme that might be suggested.
As for you point that the site / deployment may want to map the
authorization identifier to some other DN, I see no problem with
allowing it do so. This can be done by the client or the server
and doesn't require an authzid on-the-wire representation.
Kurt
----
Kurt D. Zeilenga <kurt@boolean.net>
Net Boolean Incorporated <http://www.boolean.net/>