[BASE-89] Add ANY_OBJECT special object class

[Sylinsic]

Currently, there is no ObjectClass for “ANY OBJECTS”.
This capability was recently added to the LDAP bundle, although it could also be beneficial to the wider ConnID project.

[ilgrosso]

@Sylinsic honestly, I have troubles to figure out why ANY_OBJECT could be useful at ConnId framework level.
Can you add some use cases?
Maybe it's even better to send an email to connid-dev@ ML to raise some consensus about such a change.

[Sylinsic]

@ilgrosso
Apologies, I believe the ML you are talking about is [email protected], however I am having trouble emailing it. However, my response was as below:

ANY_OBJECT as an object class is useful for being able to specify type specific provisioning configurations for anything other than Users or groups.

For example, with the LDAP connector in apache syncope, being able to work with certificates was not feasible unless treating them as user objects. This would cause a bit of a mess, and rendered ANY_OBJECTS basically pointless in that case. This has since been updated, with ANY_OBJECTS having their own configuration variables, allowing for provisioning with a set of object classes, rather than just a single one, which was often unusable with LDAP servers, that would require multiple different object classes for a set of attributes.
This functionality would also be beneficial for the AD connector, azure, scim etc, where parameters specific to the object type are of use.
I.e object classes in AD, attributes to get in azure, update methods for SCIM etc.

Of course this isn't an ideal solution, as the parameters would be set for all ANYOBJECT'S rather than for each ANYOBJECT type, although those specific types are created by a user at runtime so can't be defined as properties at the connector level.

[ilgrosso]

Apologies, I believe the ML you are talking about is [email protected], however I am having trouble emailing it.

You should really find your way through it, not a big deal, actually.
PRs are not place for community discussion.

I still don't see the need to add a specific object class at framework level.
If you need a specific connector to handle more object classes than the ones it is currently handling (typically, __ACCOUNT__ and __GROUP__) just submit a PR against that connector repository.

For example, the Azure connector is also managing licenses.