[midPoint] New ldap connector and auxiliary objectClasses
midpoint at mybtinternet.com
midpoint at mybtinternet.com
Thu Oct 22 16:19:35 CEST 2015
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20151022/00667109/attachment.htm>
More information about the midPoint
mailing list