[midPoint] Unexpected behavior of attribute mapping in Midpoint with tolerant false option during user recalculations

[Pálos Gustáv]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/f8834a78/attachment.htm>
-------------- 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/f8834a78/attachment.png>
-------------- 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/f8834a78/attachment-0001.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/f8834a78/attachment-0002.png>