Re: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?))

["Jim Sermersheim" <[e-mail]>]

The proxied authN control would be used in the case where the chaining
server has at some point established a single connection and
authenticated as a trusted identity to a remote DSA (this identity would
be trusted to chain operations). As the first DSA needs to chain to the
second, it will re-use the same outbound connection for any number of
different inbound connections.

This is only one mode of operation, some other modes would require a
1:1 relationship between in and out connections.

Jim

>>> "Kurt D. Zeilenga" <[e-mail]> 6/25/04 10:07:39 AM >>>
At 08:42 AM 6/25/2004, Jim Sermersheim wrote:
>One (albeit simple) mechanism for this has been around for a while
>(http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-12.txt).
>This seems to meet a few of the criteria that people want. It allows
the
>sender to pass a control which says "use this identity for this
>operation".

But who's asking to use this identity?  The originating client
or the chaining server?

>Though it doesn't say so, it seems able to be used between
>DSAs (it uses client and server terms). When used between DSAs, one
>would sasume the sending DSA has ensured that the sent identity has
>already authenticated somehow.
>
>Maybe this only meets some minimal requirements.

I think, in order to make it clear that as who is asking what,
there needs to be good separation between what belongs to
original request and the chaining request.  The chained
operation exop provides that.

>I think the chained bind that Kurt is talking about is a little
>different. It allows the one DSA to forward some forms of a bind
>operation to a second DSA.

Yes.  I'm looking at mechanisms for distributed authentication
operations in addition to mechanisms for distributed
(non-authentication) operations.

Kurt


>Jim
>
>>>> Ed Reed 6/25/04 8:37:08 AM >>>
>I'd really love to see an extended, chained operation that:
>
>1) relies on the chaining DSA to authenticate, using it's own
identity
>and crendentials, to establish a secure connection (probably over
SSL)
>over which the chaining DSA and the target DSA (the one who will
receive
>the chained request) will communicate;
>2) a chained, or perhaps alltogether new, operation that
authenticates
>a user and their bind credentials, but doens't result in a separate
>authentication connection on the target DSA, but rather results in a
>"yeah, I'd accept that, perhaps with these limitations" result on
which
>the chaining DSA (or other intermediary service speaking as though it
>were a trusted chaining DSA) could rely.
>
>This would allow a proxy, whether a web service, a firewall, or
another
>directory, to open a single connection to each target DSA, and then
>utter "is this guy okay" requests, perhaps with multiple round trips
so
>any challenge-response transactions used in the authentication
mechanism
>used by the end users could be satisfied.
>
>Such a multiplexing of the single trusted connection would reduce
>resource consumption by the intermediary as well as the target DSAs. 
>Doing this for SASL, generally, would seem like a good idea. Target
DSAs
>could then be configured to allow or not allow such intermediary
>multiplexing connections, and if allow them rely on the strength and
>confidence in the authentication of the chaining server to guide its
>responses.
>
>In the most simple sense, if a simple compare of a presented password
>to a user's password attribute would satisfy the chaining DSA of the
>authentication of the user, there would be no need to lash up a whole
>connection with bind and SSL handshakes for the relying system to
know
>the user is authenticated.
>
>SASL presents a more challenging design, but this notion of chaining,
>if done correctly, would seem to fit the bill.
>
>Or am I off in la-la-land, again?
>
>Ed
> 
> 
>>>>"Kurt D. Zeilenga" <[e-mail]> 06/25 9:49 am >>> 
>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 
>[e-mail] 
>https://www1.ietf.org/mailman/listinfo/ldapext 


_______________________________________________
Ldapext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ldapext