[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 04:46:38 CEST 2018
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+fAh6coYQqrA5ohhqkizbPkFquRKalRv0MzTpK620b2oVV0y5jPNgW1hh2tsIoDbXK/ZXc05EtCqV88S7PlJrmRvSPAV5wtZ2ZSQ6H42YvgG4MmGgGF98fm8odDtKfjS1uz/aoNXHbvK9378tCy0crzoTyenSwYgavDLCjM+IG3/cFFIyDEr0OenQIq6EUXTPxoVIgPlXyb+krah/gpurZHcyc2YKzOtDgpsOZ0/yDX68ICJMxm9UDhFxH6KL4tz/A2vNOyfbsXbnIV3bWM9A8ZsuEUR5LSCCQopFP02C6Ad3YcRVSRR33EOOwfdwQaGdRCzlzm3oGxzr07CmjqElw==')
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:
> frameworkAttributeName>
> </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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/4f426f16/attachment.htm>
-------------- 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/4f426f16/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/20180725/4f426f16/attachment-0001.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/4f426f16/attachment-0002.png>
More information about the midPoint
mailing list