On 10/1/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > I suggest that we feed the Roadmap with any other issues. We can then > trigger the roadmap to make it reasonable given the timeframe and > workforce we have.
Biggest problem I can think of for possible short-term inclusion is that in a number of places, we limit principal lookup to a single "search base DN." We have the single vs. multi-base search mechanism for Kerberos and Change Password, and this could work for SASL GSSAPI, but it definitely doesn't handle the other SASL mechanisms (they don't use Kerberos principals). Also, the Kerberos and Change Password single vs. multi-base search mechanism is insufficiently flexible. Other directory servers, like AD and OpenLDAP, allow principals to occur in any container, even if they are in the same realm. OpenLDAP uses regex's to allow this. In the real world, eg Quanah/Stanford, you want to segregate principals that are in the same realm but that are different principal types (such as users vs. services). You can do this with regex's that segregate principals with "host/" in their names vs. users, just as a simple example. This issue comes up periodically as a 2nd-order problem, ie multi-realm support for Kerberos, CP, and SASL GSSAPI and, looking now, quite possibly this is the issue behind DIRSERVER-1068. A good, cross-ApacheDS solution would fix a number of usability issues and clean-up the legacy mess of single vs. multi-base search. As an interceptor, it could be seriously elegant and powerful. Alex asked me back in July to come up with a proposal. The best solution, IMO, would be a component that used regex's to map between an entity, like a Kerberos principal or SASL realm/user, and a DN, either the DN of the desired entity or a base DN for a subsequent search. Of course, this is exactly what OpenLDAP does and I can't think of anything better. We could either re-use this proposed component in LDAP, Kerberos, and Change Password or we could install it as an interceptor. As an interceptor, we could have a system container, perhaps "ou=catalog,ou=system," under which there were regex's. Our internal JNDI clients could execute lookups for "([EMAIL PROTECTED])" against "virtual base DN" "ou=kerberos,ou=catalog,ou=system." That node would be populated with regex's from config XML (or LDIF) that would be processed and result either in (a) the "real base DN" to perform the search at or (b) as an interceptor, simply redirect the query in the interceptor service chain to the "real base DN." This is possible because the OperationContext's passing through the interceptor service chain are mutable and this would optimize the redirect since the query wouldn't need to be executed twice. In other words, to a JNDI client, a query against one search base results in an answer in a totally different search base. If any of this makes sense, I could code up a prototype and commit to my sandbox. Also, I did at one point, start a draft doc in the cwiki sandbox. Enrique
