[midPoint] Unexpected behavior of attribute mapping in Midpoint with tolerant false option during user recalculations
Alexandre Zia
alexandre.zia at ifood.com.br
Thu Jul 26 13:26:45 CEST 2018
Hi Oleksandr
I think it is the same problem.
I was using index=false, have just enabled index=true in hope to make it
work, didn't realize the error on database was due to enabling indexing.
Now I've just disabled it again.
I have the same behavior as you mentioned if I set the outbount mapping
strength to "normal" then one time it adds the attribute, other time it
removes the attribute exactly as tou reported.
If I set the outbound mapping strength to "strong" it doesn't delete the
attribute anymore when doing a reconciliation, but when the user is editing
its own sshPublicKeys midpoint is not syncronizing user object with shadow
properly, one of its sshPublicKeys are missing, if user has only one
sshPublicKey shadow has none
Regards
Alexandre
On Thu, Jul 26, 2018 at 4:06 AM, Oleksandr Nekriach <o.nekriach at dynatech.lv>
wrote:
> Hi Alexandre,
> I have a little bit different situation. I have not a problem with
> provisioning sshPublicKey from a user profile to LDAP resource but I have a
> problem with recalculation of users that have such attribute on the user
> profile and the tolerant=false option in mapping in LDAP resource (more
> details see above).
> Your case is different in Midpoint schema you use type="xsd:string" for
> sshPublicKey and you have a problem with field length in DB as you wrote.
> But I use type="xsd:base64Binary" in midpoint schema and have another
> problem only with recalculation users. When mapping has the tolerant=false
> option in LDAP resource. The first user recalculation event adds attribute
> value from user profile into LDAP resource the second one removes this
> attribute on the resource from the user account. And this happens
> periodically.
>
> Best regards, Oleksandr
>
>
> On 26 July 2018 at 05:46, Alexandre Zia <alexandre.zia at ifood.com.br>
> wrote:
>
>> Think I may have found something
>>
>> Got this error in logs:
>> Caused by: java.sql.BatchUpdateException: Batch entry 0 insert into
>> m_object_ext_string (dynamicDef, eType, valueType, eName, owner_oid,
>> ownerType, stringValue) values ('0', 'http://www.w3.org/2001/XMLSch
>> ema#string', 0, 'http://midpoint.evolveum.com/
>> xml/ns/story/orgsync/ext#sshPublicKey', 'e50bac40-2b0f-4566-ba8d-76c65876ed1d',
>> 0, 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA+fAh6coYQqrA5ohhqkizbPkFquRKalRv
>> 0MzTpK620b2oVV0y5jPNgW1hh2tsIoDbXK/ZXc05EtCqV88S7PlJrmRvSPAV
>> 5wtZ2ZSQ6H42YvgG4MmGgGF98fm8odDtKfjS1uz/aoNXHbvK9378tCy0crzo
>> TyenSwYgavDLCjM+IG3/cFFIyDEr0OenQIq6EUXTPxoVIgPlXyb+krah/
>> gpurZHcyc2YKzOtDgpsOZ0/yDX68ICJMxm9UDhFxH6KL4tz/A2vNOyfbsXbn
>> IV3bWM9A8ZsuEUR5LSCCQopFP02C6Ad3YcRVSRR33EOOwfdwQaGdRCzlzm3oGxzr07CmjqElw==')
>> was aborted: ERROR: value too long for type character varying(255) Call
>> getNextException to see other errors in the batch.
>>
>> using postgresql as database.
>>
>> table: m_object_ext_string - that stores extended string attribute has
>> only 255 chars and sshPublicKeys are bigger my key have 380 chars
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 25, 2018 at 3:45 PM, Alexandre Zia <
>> alexandre.zia at ifood.com.br> wrote:
>>
>>> I'm facing the exact same issue, and was about to ask for help as well.
>>> However my setup is a bit different, sshPublicKey is multivalued in
>>> ldap, so I'm using it as multivalued in Midpoint as well
>>>
>>> Differences of my setup:
>>> - Attribute sshPublicKey in my Ldap is multivalued
>>> - Attribute sshPublicKey in my Midpoint is multivalued
>>> - Created authorization for users to log into GUI and edit their own
>>> sshPublicKeys
>>>
>>> Issues:
>>>
>>> - when users edit their own profile and add/delete sshPublicKeys
>>> sometimes they are not propagated to Ldap, sometimes they are but
>>> incomplete,
>>>
>>> - enabling Clockwork Debug in Midpoint, it shows that sshPublicKey is
>>> being included in Shadow ObjectDelta but shows no action (ADD, DELETE):
>>>
>>> ObjectDelta(ShadowType:b679ca00-4b00-47ba-819b-c18253624bc3,MODIFY:
>>> PropertyDelta(attributes / {.../resource/instance-3}sshPublicKey), ...
>>> REMOVED TEXT ....): SUCCESS
>>>
>>> - sometimes Clockwork Debug shows actions, ADD or DELETE, but it never
>>> reflects the user object in Midpoint, e.g. User objet has 4 sshPublicKeys,
>>> Shadow has 3, or even User object has 1 sshPublicKey and shadow has 0
>>>
>>>
>>>
>>>
>>> My setup:
>>>
>>> -----------------------------
>>> - OpenLdap schema: (in openldap service)
>>>
>>> attributetype ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey'
>>> DESC 'MANDATORY: OpenSSH Public key'
>>> EQUALITY octetStringMatch
>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
>>>
>>>
>>> -----------------------------
>>> - IDM extended attibute: I've created sshPublicKey as "string" in
>>> userType
>>> (so it would be easy for users to type it in their profiles):
>>>
>>> <!-- sshPublicKey -->
>>> <xsd:element name="sshPublicKey" type="xsd:string" minOccurs="0"
>>> maxOccurs="unbounded" >
>>> <xsd:annotation>
>>> <xsd:appinfo>
>>> <a:indexed>false</a:indexed>
>>> <a:displayName>SSH Public Key</a:displayName>
>>> </xsd:appinfo>
>>> </xsd:annotation>
>>> </xsd:element>
>>>
>>> -----------------------------
>>> - attribute in ldap connector schema:
>>>
>>> <xsd:element maxOccurs="unbounded" minOccurs="0" name="sshPublicKey"
>>> type="xsd:base64Binary">
>>> <xsd:annotation>
>>> <xsd:appinfo>
>>> <a:displayOrder>150</a:displayOrder>
>>> <ra:nativeAttributeName>sshPublicKey</ra:nativeAttributeName>
>>> <ra:frameworkAttributeName>sshPublicKey</ra:frameworkAttribu
>>> teName>
>>> </xsd:appinfo>
>>> </xsd:annotation>
>>> </xsd:element>
>>>
>>> -----------------------------
>>> - attribute mapping in ldap connector:
>>>
>>> <attribute>
>>> <c:ref>ri:sshPublicKey</c:ref>
>>> <displayName>SSH Public Key</displayName>
>>> <tolerant>false</tolerant>
>>> <exclusiveStrong>false</exclusiveStrong>
>>> <outbound>
>>> <authoritative>false</authoritative>
>>> <exclusive>false</exclusive>
>>> <strength>strong</strength>
>>> <source>
>>> <c:path>$user/extension/sshPublicKey</c:path>
>>> </source>
>>> <expression>
>>> <script xsi:type="c:ScriptExpressionEvaluatorType">
>>> <trace>false</trace>
>>> <relativityMode>absolute</relativityMode>
>>> <includeNullInputs>true</includeNullInputs>
>>> <code>
>>> def ret = []
>>> for (publicKey in sshPublicKey)
>>> {
>>> ret.add(publicKey.getBytes() )
>>> }
>>> return ret
>>> </code>
>>> </script>
>>> </expression>
>>> </outbound>
>>> <inbound>
>>> <authoritative>false</authoritative>
>>> <exclusive>false</exclusive>
>>> <strength>weak</strength>
>>> <source>
>>> <c:path>$account/attributes/sshPublicKey</c:path>
>>> </source>
>>> <expression>
>>> <script xsi:type="c:ScriptExpressionEvaluatorType">
>>> <trace>false</trace>
>>> <relativityMode>absolute</relativityMode>
>>> <includeNullInputs>true</includeNullInputs>
>>> <code>
>>> def ret = []
>>> for (publicKey in sshPublicKey)
>>> {
>>> ret.add(new String(publicKey, "UTF-8"))
>>> }
>>> return ret
>>> </code>
>>> </script>
>>> </expression>
>>> <target>
>>> <c:path>$user/extension/sshPublicKey</c:path>
>>> </target>
>>> </inbound>
>>> </attribute>
>>>
>>>
>>> -----------------------------
>>> - Added authorization in "End User" role, for users to manage their own
>>> sshPublicKey attribute
>>>
>>> <authorization>
>>> <name>edit-own-ssh-public-key</name>
>>> <description>
>>> Authorize users add and delete ssh public keys from the GUI.
>>> </description>
>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>> authorization-model-3#modify</action>
>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>> authorization-model-3#add</action>
>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>> authorization-model-3#read</action>
>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>> authorization-model-3#delete</action>
>>> <object>
>>> <special>self</special>
>>> </object>
>>> <object>
>>> <type>ShadowType</type>
>>> <owner>
>>> <special>self</special>
>>> </owner>
>>> </object>
>>> <c:item>extension/sshPublicKey</c:item>
>>> <c:item>attributes/sshPublicKey</c:item>
>>> </authorization>
>>>
>>> -----------------------------
>>>
>>>
>>>
>>>
>>> Regards
>>> Alexandre Zia
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jul 25, 2018 at 8:25 AM, Oleksandr Nekriach <
>>> o.nekriach at dynatech.lv> wrote:
>>>
>>>> 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>sshPub
>>>>>> licKey</ra:nativeAttributeName>
>>>>>> <ra:frameworkAttributeName>ssh
>>>>>> PublicKey</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.
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Alexandre Roberto Zia
>>>
>>> *Security*
>>>
>>> *TEL:* +55 (11) 3634-3360
>>>
>>> www.ifood.com.br
>>>
>>>
>>>
>>>
>>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>>>
>>
>>
>>
>> --
>>
>> Alexandre Roberto Zia
>>
>> *Security*
>>
>> *TEL:* +55 (11) 3634-3360
>>
>> www.ifood.com.br
>>
>>
>>
>>
>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>>
>> _______________________________________________
>> 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.
>
--
Alexandre Roberto Zia
*Security*
*TEL:* +55 (11) 3634-3360
www.ifood.com.br
<https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
<https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
<https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180726/e740a8bc/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/20180726/e740a8bc/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/20180726/e740a8bc/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/20180726/e740a8bc/attachment-0002.png>
More information about the midPoint
mailing list