|
This is a good example of the problem space I'm trying to address. The only difference is that I'm dealing with different types of "clients". When chaining a request from DSA1 to DSA2, DSA1 is also a client of sorts, and may need to know how to authN to DSA2. If DSA2 returns a referral back to DSA1, where the referral points to DSAS3, again, DSA1 might need to know how to authN to DSA3.
Another small example is TLS. Say the DUA gets a referral from DSA1 to DSA2. The DUA has never been configured with the public key of DSA2. We could configure DSA1 to return the public key of DSA2 when returning a referral.
In terms of the format of the referral response, there seem to be two choices in how this could be done:
1) The DUA asks (via a control) for this (public key) information to be returned in a response control when referrals are sent. What's ugly here is when there are multiple referral values. The response control would have to have a way of associating the public keys with the referral values.
1.1) Alternately, the referral could contain a dummy referral value (or just return with a different result code, and include no referral at all), and the response control would contain structured data where each referral is associated with a set of data).
2) DSA1 (perhaps only if solicited) places the entire public key (base64 encoded) in an extension on the ref URI.
In terms of placement of this information, it could be stored exactly the way it is sent in #2 above, or it could be stored in a number of other ways ? each of which would have to define a way to associate the ref URI to the public key.
What I'm trying to get a sense of is whether a continuation of using values of the ref URI for both the management and instructional parts of referrals is preferred over breaking things up into more atomic units.
I think I prefer breaking it up, and using solution 1.1 above. It actually solves other issues as well ? for example, consider the X.518 CrossReferece. It is (when broken down) a contextPrefix, and a list (possibly) of addresses. Today, if we have 10 ref values on a reference object, and if the DSA is returning a search result reference due to it, the DSA must augment all 10 values by adding the proper DN to each. A more structured referral could contain a targetObject field, and one or more sequences of { address, overriding target, authN Info, mapping info, etc }.
Sorry Michael, I didn't answer any of your questions.
Jim
>>> Michael Ströder <michael@stroeder.com> 4/23/04 8:58:32 AM >>> Howard Chu wrote: >> >>- Authentication information (instructions on how to authenticate to >>the remote service) > > In the case of a foreign/untrusted server, generally it would be > inappropriate for the local server to automatically tell the client anything > about how to authenticate/authorize. Since most times I have the client-side view I'd like to focus on authentication information in LDAP URLs. Are there any client implementations out there using the bindname extension of LDAP URLs? If yes, how do they treat it? My web2ldap simply presents a login form asking for the credential (password) for this bind DN. Are there any server implementations setting bindname extension in a referral LDAP URL? How should a client treat such a referral URL? Now if a LDAP server would sent back a referral with bindname extension set in the referral URL I would simply act the same way as described above: Present a login form to the user before following the referral. Any security considerations? Furthermore I'd also like to have a mechanism like that for specifying SASL related authentication information in a LDAP URL: - StartTLS ext. op. SHOULD/MUST be used - SASL authc ID - SASL authz ID - SASL realm - SASL mechanism I can easily use LDAP URL extensions for these off course but what do the list members here think about this approach? Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext |