[midPoint] New ldap connector and auxiliary objectClasses
Ivan Noris
ivan.noris at evolveum.com
Thu Oct 22 17:53:21 CEST 2015
Hi,
I'd recomment to try either:
- using the latest build of the LDAP connector:
https://github.com/Evolveum/connector-ldap
or
- using latest midpoint 3.3 snapshot
To avoid upgrading your database etc. it's probably faster to use the
new connector version.
If you already have version 1.4.2.0-SNAPSHOT in midPoint (I don't
remember what version was bundled with MP 3.2), you should do this:
1) download/git clone sources of the LDAP connector
2) temporarily change pom.xml - the version from 1.4.2.0-SNAPSHOT to
e.g. 1.4.2.0.*a*-SNAPSHOT (you cannot have two connectors of the same
type with the same versions)
3) build the connector
The connector (JAR) should be placed to $midpoint.home/icf-connectors
directory and after restarting Tomcat, you are ready to use it. Check if
the corresponding Connector object is created in Repository for this new
connector and edit your resource and update the connectorRef oid value
to the new Connector.
If this works, problem was fixed meanwhile in the connector.
If this does not work, please let us know / create JIRA for this.
Thanks,
Ivan
On 10/22/2015 04:19 PM, midpoint at mybtinternet.com wrote:
> Hi,
>
> I was doing a delete of the resource from configuration each time
> before importing the resource; was not
> expecting the schema to have survived ... although I did not do that
> for the last test before post, else I may
> have caught one issue; thx for reminding me.
>
> A number of directories, including OpenDJ, IBM, etc, support schema
> definition using a unique string instead
> of OID (dotted notation). This makes the process easier, less prone
> to error, and you don't have to track
> OID numbers actively. When defining my auxiliary objectClas in this
> way, midpoint seems to ignore it, e.g.:
>
> attributeTypes: ( *myCallSign-OID* NAME 'myCallSign' DESC 'Call
> Sign' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE
> userApplications )
> objectClasses: ( *myPerson-OID* NAME 'myPerson' DESC 'My Person'
> SUP top AUXILIARY MAY ( myCallSign ) )
>
> If however I use dotted notation OID, the objectClass is recognised,
> e.g.:
>
> attributeTypes: ( *2.1.1.1.1* NAME 'myCallSign' DESC 'Call Sign'
> EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR
> caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE
> userApplications )
> objectClasses: ( *2.1.1.1.0* NAME 'myPerson' DESC 'My Person' SUP
> top AUXILIARY MAY ( myCallSign ) )
>
> In 3.1.1 with the old connector the first definition worked and I
> have used this syntax for several years;
> hope we do not have to regress ...
>
> Regards,
> Anton
>
> ----Original message----
> From : ivan.noris at evolveum.com
> Date : 22/10/2015 - 13:41 (BST)
> To : midpoint at lists.evolveum.com
> Subject : Re: [midPoint] New ldap connector and auxiliary
> objectClasses
>
> Hi,
>
> do you have your new attributes (coming from ri:myPerson) in the
> resource <schema>? (Not in schema handling).
>
> To be sure, edit please your resource using Configuration -
> Repository objects and delete <schema> .. .</schema> element and
> then save and try to test connection. After this, check the
> <schema> element if it contains your ri:myPerson object class and
> its attributes...
>
> My coleagues are using this new LDAP connector (but in master) and
> there were some fixes, but I can't tell now if it was related to
> auxiliary classes.
>
> Ivan
>
> On 10/22/2015 02:30 PM, midpoint at mybtinternet.com wrote:
>> Hi,
>>
>> I was trying:
>>
>> <!-- snip -->
>> <schemaHandling>
>> <objectType>
>> <displayName>Default Account</displayName>
>> <default>true</default>
>> <objectClass>ri:inetOrgPerson</objectClass>
>>
>> *<auxiliaryObjectClass>ri:myPerson</auxiliaryObjectClass>*
>> <attribute>
>> <ref>ri:dn</ref>
>> <displayName>Distinguished Name</displayName>
>> <limitations>
>> <minOccurs>0</minOccurs>
>> <access>
>> <read>true</read>
>> <add>true</add>
>> <modify>false</modify>
>> </access>
>> </limitations>
>> <matchingRule>mr:stringIgnoreCase</matchingRule>
>> <outbound>
>> <strength>weak</strength>
>> <source>
>> <path>$user/name</path>
>> </source>
>> <expression>
>> <script>
>> <!-- No explicit script language was
>> specified. It means that this is Groovy -->
>> <code>
>> 'uid=' + name + iterationToken +
>> ',ou=staff,dc=internal,dc=example,dc=com'
>> </code>
>> </script>
>> </expression>
>> </outbound>
>> </attribute>
>> <!-- snip -->
>> <!-- snip -->
>> * <attribute>
>> <c:ref>ri:myCallSign</c:ref>
>> <exclusiveStrong>false</exclusiveStrong>
>> <tolerant>true</tolerant>
>> <fetchStrategy>implicit</fetchStrategy>
>> <outbound>
>> <authoritative>false</authoritative>
>> <exclusive>false</exclusive>
>> <strength>normal</strength>
>> <source>
>> <c:path>extension/myCallSign</c:path>
>> </source>
>> </outbound>
>> <inbound>
>> <authoritative>false</authoritative>
>> <exclusive>false</exclusive>
>> <strength>normal</strength>
>> <target>
>> <c:path>extension/myCallSign</c:path>
>> </target>
>> </inbound>
>> </attribute>*
>> <!-- snip -->
>>
>> When having attributes defined in the schema handling, midPoint
>> complains about them;
>> When only the auxiliary objectClass defined, midPoint says it
>> can't be found. myCallSign
>> is an attribute of myPerson objectClass.
>>
>> Regards,
>> Anton
>>
>>
>>
>> ----Original message----
>> From : ivan.noris at evolveum.com
>> Date : 22/10/2015 - 13:15 (BST)
>> To : midpoint at lists.evolveum.com
>> Subject : Re: [midPoint] New ldap connector and auxiliary
>> objectClasses
>>
>> Hi,
>> could you please paste your <objectType> definition from
>> schema handling?
>>
>> Ivan
>>
>> On 10/22/2015 01:36 PM, midpoint at mybtinternet.com wrote:
>>> Hi Guys,
>>>
>>> Trying to use the new LDAP connector in 3.2; but having
>>> issues with my auxiliary objectClass.
>>>
>>> I have tried using:
>>> <auxiliaryObjectClass>ri:myPerson</auxiliaryObjectClass>
>>> in the account section of schema definition. This seems to
>>> be the method implied by the UNIX user
>>> sample scenario ... although not used on the account
>>> section per se.
>>>
>>> After resource load, which is apparently successful,
>>> browsing to "List resources" throws an error
>>> that the objectclass myPerson was not found. When looking
>>> at the objectClasses listed in the
>>> connector, it does not seem to be listed. Also enable read
>>> schema, seems to make not diff. Tried
>>> test connection; again no diff.
>>>
>>> This used to work with 3.1.1 and the previous connector.
>>>
>>> If I do a ldapsearch for schema on OpenDJ, my custom
>>> objectclass is returned; Apache Directory
>>> Studio also recognises the auxiliary objectclass. Thus, is
>>> this:
>>> - an issue with how I'm referencing the auxiliary
>>> objectClass?
>>> - a bug in the new LDAP connector?
>>> - Something else?
>>>
>>> Thx,
>>> Anton
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>> --
>> Ing. Ivan Noris
>> Senior Identity Management Engineer & IDM Architect
>> evolveum.com evolveum.com/blog/
>> ___________________________________________________
>> "Semper Id(e)M Vix."
>>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer & IDM Architect
> evolveum.com evolveum.com/blog/
> ___________________________________________________
> "Semper Id(e)M Vix."
>
>
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper Id(e)M Vix."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151022/7b5e188f/attachment.htm>
More information about the midPoint
mailing list