On Wed, Sep 17, 2014 at 9:58 PM, Sebastian Oerding < [email protected]> wrote:
> The certificates we have to deal with are defined in a technical > recommendation, specifying some mandatory / forbidden X.509 extensions and > other special stuff. Especially there is some stuff which is (close to) > violating RFC 5280. > > Furthermore there may be customers which require that a specific product > is used as LDAP Server (OpenLDAP, Apache DS, MS Active Directory, Novell > Directory Server, ...). Hence we can only rely on functionality which > available in all of these products (or can be implemented for them with a > reasonable effort). > > Currently I'm wondering about using an embedded Apache DS with > interceptors simply forwarding each call to the corresponding stand-alone > LDAP server (which may also be an Apache DS). However let's denote my > component with C then we may end up with (ASCII art) the following due to > chaining: > > C - C > | | > external LDAP external LDAP > > ok, this kinda answers my earlier question, but why do you need to have more than one component? The best solution is to have one ApacheDS instance as a _proxy_ and cause you are going to use it in embedded mode then you practically have all things ready to make this solution work, provided you know which 3rd party server needs to be contacted for a specific request when a cert is not present. If you can determine that information based on the search request, then the best way to solve it in the proxy ApacheDS instance is by adding a new in-memory partition and overwrite the search() method. Now each of these instances of C holding an embedded Apache DS which simply > forwards the messages to the external LDAP seem to result in a huge > overhead which may be unaffordable. I would prefer a better by "overhead" you mean maintenance or performance? performance wise there is nothing other than the overhead of proxying a connection. > solution but I have around five days to implement this functionality and I > do not see any chance to implement this stuff if there is no code which > nearly exactly fits my needs and that I can simply take and re-use. > Unfortunately arguing for a better technical solution or more time is > currently ignored. Hence recommendations for other approaches currently are > of no help (just in case someone wants to argue that everything would be > fine using JMS / protocol XYZ / ...). > > Sebastian > > -- Kiran Ayyagari http://keydap.com
