[midPoint] Unexpected behavior of attribute mapping in Midpoint with tolerant false option during user recalculations
Oleksandr Nekriach
o.nekriach at dynatech.lv
Wed Jul 25 13:25:23 CEST 2018
Hi Gustav,
Thank you for the quick reply but you advise doesn't help me. Behaviour is
the same.
My config after
<attribute id="141">
<c:ref>ri:sshPublicKey</c:ref>
<displayName>sshPublicKey</displayName>
<limitations>
<minOccurs>0</minOccurs>
<maxOccurs>1</maxOccurs>
<access>
<read>true</read>
<add>true</add>
<modify>true</modify>
</access>
</limitations>
<tolerant>false</tolerant>
<fetchStrategy>explicit</fetchStrategy>
<outbound>
<strength>strong</strength>
<source>
<c:path>$user/extension/sshPublicKey</c:path>
</source>
</outbound>
</attribute>
On 25 July 2018 at 12:43, Pálos Gustáv <gustav.palos at evolveum.com> wrote:
> Hi,
>
> try to put limitation to use it as single value:
> <attribute id="141">
> <c:ref>ri:sshPublicKey</c:ref>
> <limitations>
> <minOccurs>0</minOccurs>
> <maxOccurs>1</maxOccurs>
> <access>
> <read>true</read>
> <add>true</add>
> <modify>true</modify>
> </access>
> </limitations>
> ....
>
> best regards,
>
> Gustav
>
> st 25. 7. 2018 o 10:48 Oleksandr Nekriach <o.nekriach at dynatech.lv>
> napísal(a):
>
>> Hi to all,
>> I have faced with a problem of unexpected behavior of Midpoint IDM(3.7)
>> during user recalculations.
>> I have extended IDM and LDAP with sshPublicKey attribute
>> (xsd:base64Binary in IDM and Octet String in LDAP) and created of mapping
>> attribute in LDAP resource as is.
>> I have to remove the attribute value on LDAP when it removes in IDM. For
>> this task, I have added tolerant=false option in the attribute mapping in
>> LDAP resource.
>> It works in a wrong way. When I have a non-empty sshPublicKey in IDM it
>> is provisioned in LDAP correctly. It is Ok. But when run user recalculation
>> it removes sshPublicKey attribute value in LDAP. When I run recalculation
>> the second time it re-provisions sshPublicKey attribute value in LDAP
>> again.
>> And it can be Infinite. Every time when recalculation runs it removes and
>> restores attribute value periodically.
>> Please help me to understand what I did in the wrong way in configuration
>> or confirm that is a bug in Midpoint.
>>
>> See below configuration details
>>
>> Attribute in LDAP schema
>>
>> olcAttributeTypes: {17}( 1.3.6.1.4.1.45689.1.1.1.2.18 NAME 'sshPublicKey'
>> DESC 'SSH Public key' EQUALITY octetStringMatch SYNTAX
>> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
>>
>> Attribute in LDAP connector schema
>>
>> <xsd:element minOccurs="0" name="sshPublicKey"
>> type="xsd:base64Binary">
>> <xsd:annotation>
>> <xsd:appinfo>
>> <a:displayOrder>290</a:displayOrder>
>> <ra:nativeAttributeName>sshPublicKey</ra:
>> nativeAttributeName>
>> <ra:frameworkAttributeName>sshPublicKey</ra:
>> frameworkAttributeName>
>> </xsd:appinfo>
>> </xsd:annotation>
>> </xsd:element>
>>
>> Attribute in IDM schema
>>
>> <xsd:element name="sshPublicKey" type="xsd:base64Binary"
>> minOccurs="0" maxOccurs="1">
>> <xsd:annotation>
>> <xsd:appinfo>
>> <a:displayName>sshPublicKey</a:displayName>
>> <a:indexed>false</a:indexed>
>> </xsd:appinfo>
>> </xsd:annotation>
>> </xsd:element>
>>
>> Attribute mapping in LDAP connector
>>
>> <attribute id="141">
>> <c:ref>ri:sshPublicKey</c:ref>
>> <displayName>sshPublicKey</displayName>
>> <tolerant>false</tolerant>
>> <fetchStrategy>explicit</fetchStrategy>
>> <outbound>
>> <strength>strong</strength>
>> <source>
>> <c:path>$user/extension/sshPublicKey</c:path>
>> </source>
>> </outbound>
>> </attribute>
>>
>> --
>> Best regards,
>>
>>
>>
>> Oleksandr Nekriach | Identity and access management engineer
>>
>> Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
>> <https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
>>
>> +37125314685 <+371%2025%20314%20685>
>> ,
>> o.nekriach at dynatech.lv
>> |
>> www.dynatech.lv
>>
>>
>> Stay connected:
>> <https://www.facebook.com/DynatechLatvia/?ref=br_rs>
>> <https://www.linkedin.com/company-beta/17893047/>
>>
>>
>> Confidentiality Notice: This message contains confidential information
>> and is intended only for the named recipient(s). If you are not the
>> addressee you may not copy, distribute or perform any other activities with
>> this information. If you have received this transmission in error, please
>> notify us by e-mail immediately. E-mail transmission cannot be guaranteed
>> to be secure or error-free as information could be intercepted, corrupted,
>> lost, destroyed, arrive late or incomplete, or contain viruses.
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>> --
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>> Gustáv Pálos
>> Identity Engineer
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>evolveum.com
>>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
--
Best regards,
Oleksandr Nekriach | Identity and access management engineer
Dynatech, Mednieku str. 4a, Riga, LV-1010, Latvia
<https://maps.google.com/?q=Mednieku+str.+4a,+Riga,+LV-1010,+Latvia&entry=gmail&source=g>
+37125314685 <+371%2025%20314%20685>
,
o.nekriach at dynatech.lv
|
www.dynatech.lv
Stay connected:
<https://www.facebook.com/DynatechLatvia/?ref=br_rs>
<https://www.linkedin.com/company-beta/17893047/>
Confidentiality Notice: This message contains confidential information and
is intended only for the named recipient(s). If you are not the addressee
you may not copy, distribute or perform any other activities with this
information. If you have received this transmission in error, please notify
us by e-mail immediately. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/35ea9fc1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7772
Type: image/png
Size: 786 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/35ea9fc1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7770
Type: image/png
Size: 4265 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/35ea9fc1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o.nekriach at dynatech.lv1520941785292-7771
Type: image/png
Size: 790 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/35ea9fc1/attachment-0002.png>
More information about the midPoint
mailing list