Hi Radovan,
On 11/06/2019 16:11, Radovan Semancik wrote:
Hi,
I thought that this may be of interest for the community here. I have
created a prototype code to process "native" Active Directory schema
with Directory API:
https://github.com/Evolveum/connector-ldap/blob/feature/ad-native-schema/src/main/java/com/evolveum/polygon/connector/ldap/ad/AdSchemaLoader.java
https://github.com/Evolveum/connector-ldap/blob/feature/ad-native-schema/src/main/java/com/evolveum/polygon/connector/ldap/ad/AdSchemaManager.java
This is much needed. We probably also need the same thing for OpenLDAP,
as it uses a slightly different way to describe schema (typically, you
can have macros).
For those of you who are not aware of those AD "peculiarities", AD
provides an somehow-standard LDAP-like schema definition. But this
leaves a lot to be desired.
Indeed. Like 'userPassword' is single-valued in AD, while it's expected
to be MultiValued per the RFCs, and many other atrocities (aka
"*Embrace, extend, and extinguish*").
E.g. it does not provides any means to work with objectCategory, which
is quite essential if you want to get any decent performance of your
AD server. (Un)fortunately, there is another form of AD schema which
is, quite surprisingly, not standard. What I have done is to write a
code to parse that proprietary form of the schema and load it into
modified Directory API SchemaManager. Then the API can work with the
same in the same way as it works with standard LDAP schema.
I would be interested about having an exhaustive description of the
differences.
First tests suggest that this may work. Once I manage to stabilize and
test the code, I will most likely contribute that directly to
Directory API, as this may be useful also for other people. But that
will be most definitely after the 2.0 release of the API.
AFAICT, you are working in a branch, which is just fine. I don't think
the LDAP API base code will move a lot in the coming weeks, now that we
have cut a release, so you have time to do what you need and be safe
merging all of it back in master.
Current structure of Directory API, especially the schema-processing
parts (SchemaLoader, SchemaManager) is not ideal for this particular
kind of abominations.
trudat. I saw that you made it extensible, which is a sane decision. May
be creating an abstract classin the middle would make sense, I don't
know. Or a factory ?
However, I have managed to make it work just with a few minor changes
in SchemaLoader and SchemaManager. Those classes would deserve much
tender loving care. But the current code seems to work and the rework
of SchemaLoader and SchemaManager is currently not my priority.
I think that rethinking the design after you are done would benefit from
your experience.
E.g. dependency of the API on MINA is something that bothers me much
more.
Actually, decoupling the API from MINA will be quite difficult. We can
discuss that further, but the main issues are :
- the API is used on both side (client and server). We could imagine
having a client based on a synchronous network layer (ie, plain socket)
instead of somlething based on NIO. That would make the client code much
simpler
- abstracting an asynchronous layer (be it MINA or NETTY or whatever we
decide to use) would be quite difficult.
- we could also decide to stop using a network framework, and wrap our
own. We don't need all the whistles and bells MINA offer, we just need
the SSL part. Tomcat did that, to avoid having to depend on such a
framework for many reasons (mainly because they wanted to be in
control). However, we are pretty much in control of MINA.
Anyway, this is clearly something we can discuss further.
Thanks Radovan !
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
