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

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

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". 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 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.

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