[midPoint] Unexpected behavior of attribute mapping in Midpoint with tolerant false option during user recalculations
Alexandre Zia
alexandre.zia at ifood.com.br
Wed Jul 25 20:45:08 CEST 2018
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180725/fbad542e/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/fbad542e/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/fbad542e/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/fbad542e/attachment-0002.png>
More information about the midPoint
mailing list