[ldapext] RE: Complex knowledge information

["Jim Sermersheim" <jimse@novell.com>]

>>> "Howard Chu" < hyc@highlandsun.com > 4/23/04 2:50:08 AM >>>
<snip>
>I think the answers depend a great deal on the actual usage scenarios.
In
>particular, it depends on whether the first server's referral points
to
>another trusted/local server, or if it points to a foreign/unknown
server. I
>suppose if you know enough about the remote server to have schema
mapping,
>data transformation, and name resolution information, then you
probably know
>a fair amount of other things about it too.

Yes, even the trust relationship you describe is an example of the aux
data that needs to be stored on a per--ref value basis. Rather than
storing the data on each instance of a ref value which points to say
openldap.org:389, the ref value could be augmented to point to an entry
which holds the relationship (and other) data for that server. This
works for data that is general to a remote DSA, but something different
is needed if the information is tied somehow to a specific naming
context on that DSA.

>In the case of trusted/cooperating servers, my preference is for the
server
>to maintain all of this information internally, chain the queries, and
return
>the mapped results to the client transparently. In this case,
>authentication/authorization is also handled by the chaining server.

Right, if the chaining server (say DSA1) is in a chaining mode, it will
(hopefully) return results (not referrals) to the client that look like
they came from DSA1. But someone had to confugure the infomation needed
for DSA1 to chain to (say DSA2). That data could be configured using the
extension information on the ref URI, or in some other way. So one part
of my original question was: where should this information be stored? If
I pick a methodology of doing this without consulting others, my way
will likely not become the standard way, and people implementing
management tools will have one more LDAP inconsistency to deal with. 

>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.
>
>Probably not a very useful reply, but that's how I see things at the
moment.

Actually it is useful. What I'm trying to do is to define things such
that they work the same regardless of whether we're dealing with:
- a referral being passed back to the client
- a referral being passed back from one DSA to another (while
chaining)
- a referral being passed from one DSA process to another
(findDSEProcedure returning to the searchProcedure)

Whether any or all of the extra information is passed during these
steps does depend on access control and solicitation. The former (access
control) makes a case against placing all the information on the each
ref URI as I don't think many server implementations allow ACI to
identify parts of a value.

Currently, what you get in a referral is pretty much what you manage on
the reference object (though sometimes the DN part is generated). So
part of me wants to continue with that paradigm, but another part of me
thinks doing so will lead to an ugly, bloated mess.



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext