[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Chained Operation (control, extended op, or op?)
At 11:47 PM 6/24/2004, Mark Ennis wrote:
>Kurt D. Zeilenga wrote:
>>BTW, I'd like to add support for chaining SASL bind exchanges.
>>This will require some fields beyond those offered by the
>>X.518 ChainingArguments/ChainingResults structures.
>
>I agree that a mechanism for chaining SASL bind exchanges would be useful, however, current chaining mechanisms (e.g. X.518 or LDAP referrals) depend on name resolution of a base object. The bind operation, particularly when using a SASL mechanism, does not have a base object for the name resolution process. This would mean special procedures for "chaining" this operation.
>
>Does this also require formalising some type of trust model between DSAs if we are going to delegate authentication operations to another server?
Yes.
>Is it possible to translate this SASL bind exchange into a LDAP operation the initiating DSA invokes, e.g. a search for the SASL "username" with a control used to transmit the SASL credentials and receive the SASL auth-response?
Depending on mechanism, depending on assumptions, yes.
>Such an operation may then be chained by the responding DSA(s) and authorization decisions will be done using the initiating DSA as the authorization identity?
Possibly.
I, however, was considering an approach where the initiating server
would pass through the original request with some additional information
so that the chained server can form the proper response, and return
that response with some additional information needed by the chaining
server to make use of the response.
This may be an area better left to a separate document (and
separate extended operation). If I have time in the next few
weeks, I'll try to outline a proposal here in an I-D.
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext