[midPoint] Unexpected behavior of attribute mapping in Midpoint with tolerant false option during user recalculations
Oleksandr Nekriach
o.nekriach at dynatech.lv
Thu Jul 26 09:06:44 CEST 2018
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/
> XMLSchema#string', 0, 'http://midpoint.evolveum.com/
> xml/ns/story/orgsync/ext#sshPublicKey', 'e50bac40-2b0f-4566-ba8d-76c65876ed1d',
> 0, 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA+fAh6coYQqrA5ohhqkizbPkFquRKalR
> v0MzTpK620b2oVV0y5jPNgW1hh2tsIoDbXK/ZXc05EtCqV88S7PlJrmRvSPAV5wtZ2
> ZSQ6H42YvgG4MmGgGF98fm8odDtKfjS1uz/aoNXHbvK9378tCy0crzoTyenSwYgav
> DLCjM+IG3/cFFIyDEr0OenQIq6EUXTPxoVIgPlXyb+krah/gpurZHcyc2YKzOtDgpsOZ0/
> yDX68ICJMxm9UDhFxH6KL4tz/A2vNOyfbsXbnIV3bWM9A8ZsuEUR5LS
> CCQopFP02C6Ad3YcRVSRR33EOOwfdwQaGdRCzlzm3oGxzr07CmjqElw==') 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180726/b0f51fb6/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/b0f51fb6/attachment.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/b0f51fb6/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/20180726/b0f51fb6/attachment-0002.png>
More information about the midPoint
mailing list