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

[John McMeeking <[e-mail]>]

Jim,

Potentially, the proxied authN control can be used at two points in the
scenario.
1) the chaining DSA uses it to pass along the client's identity.
2) the end application can be use it on behalf of a client it has
authenticated

For example, assume the chaining DSA authenticates as cn=chainingDsa, an
application authenticates as cn=application, and some user has
authenticated to the application as some identity associated with the LDAP
id cn=user.  The application uses the proxy control to perform some request
under the authority of the user - but it sends this request to the proxy
server.  The chaining DSA needs to pass along two identities to the remote
server so it can determine if cn=application is authorized to request
authzid cn=user -- maybe use it for other purposes.

Keep the stuff you need for chaining where it is clearly part of the
chaining mechanism.  This may apply to other controls you had mentioned as
being related to chaining but possibly being useful elsewhere.  It can get
messy really fast when a DSA uses a control for chaining and a client can
also attach the control to requests sent to the chaining DSA.

John  McMeeking


[e-mail] wrote on 06/25/2004 11:23:10 AM:

> 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


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