[midPoint] Security Violation with Custom Attribute

[Ivan Noris]

Hi Brad,

good to hear it helped :-)

According to the schema, (PropertyAccessType in common-core-3.xsd) the
correct elements are read, add, modify. The samples are automatically
tested during builds, so there should not be any invalid elements. So
you have found error in our documentation. Which I have just fixed :)
Thank you.

Best regards,
Ivan

On 03/30/2017 11:27 PM, Brad Firestone wrote:
> Thank you Ivan!
>
> I'm sorry for my confusing statements.  I wasn't very clear.
>
> The resource is the TARGET.  What I meant by "this resource should not
> ever be modified" is that the resource will not be modified by
> anything OTHER THAN midPoint.
> So we are thinking the same here.
>
> I commented out "<add>false</add>"
> and that solved the problem.  THANK YOU! 
> I was just blindly copying in attributes from the samples. 
>
> Now that I'm reading about the Attribute Limitations, I notice that
> the documentation shows tags for:
> <create> <read> and <update>
>
> Are these more "current"  than <read> <add> and <modify> tags that I
> found in the samples?  If so, I guess I should be using these instead?
>
> Thank you again!
> Brad
>
> Ivan Noris wrote:
>> Hi Brad,
>>
>> I believe you are "mixing" things a little: see below:
>>
>>
>> On 03/29/2017 11:42 PM, Brad Firestone wrote:
>>> Hi, I'm just getting started with my midPoint configuration.  I have
>>> setup an OpenLDAP resource that has custom attributes in a custom
>>> object class.  This resource should not ever be modified, so I have
>>> removed all inbound settings, since I only want information to go out
>>> to this resource.
>>
>> If the resource is TARGET, there must be outbounds. If you don't need to
>> synchronize anything FROM the resource, you don't need inbounds.
>>
>>> When I try to project a midPoint user to this resource, I get the
>>> following error:
>>>
>>> Security violation during processing shadow shadow: null (OID:null):
>>> Attempt to add shadow with non-createable attribute
>>> {http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}gnUniqueId
>>>
>>> The attribute gnUniqueID exists in a custom schema XSD file and it
>>> does display under the Extension section of the User in the GUI. 
>>> Here's the related section from the XSD file:
>>>
>>> <xsd:element name="gnUniqueID" type="xsd:string" minOccurs="0"
>>> maxOccurs="1">
>>> <xsd:annotation>
>>> <xsd:appinfo>
>>> <a:indexed>true</a:indexed>
>>> <a:displayName>GN-UniqueID</a:displayName>
>>> <a:displayOrder>120</a:displayOrder>
>>> </xsd:appinfo>
>>> </xsd:annotation>
>>> </xsd:element>
>>>
>>> Here is the attribute section of the Resource XML file:
>>>
>>> <attribute>
>>> <ref>ri:gnUniqueId</ref>
>>> <displayName>GN Unique ID</displayName>
>>> <limitations>
>>> <access>
>>> <read>true</read>
>>> <add>false</add>
>>> <modify>true</modify>
>>> </access>
>>> </limitations>
>>> <outbound>
>>> <source>
>>> <path>$user/extension/gnUniqueID</path>
>>> </source>
>>> </outbound>
>>> <matchingRule>mr:stringIgnoreCase</matchingRule>
>>> </attribute>
>>>
>>
>> I believe the "<add>false</add>" is the problem. You can't add the value
>> of "gnUniqueId" resource attribute because you have prohibited it. (The
>> attribute is "non-creatable".)
>> What happens if you remove the "<add>false</add>" restriction?
>>
>> Regards,
>> Ivan
>>
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-- 
Ivan Noris
Senior Identity Engineer
evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170331/4deb8e6d/attachment.htm>