[midPoint] Role Explosion and Role Parameters

Ivan Noris ivan.noris at evolveum.com
Mon Jul 2 09:09:57 CEST 2018


Hi Nicolas,

hmm, in my example (in blog and in real customer deployment) I was
constructing the "group membership" (using associations) and the group
was searched in the target system using associationTargetSearch, where
the group name was parametrized.

I have simplified the association part (this was the .NET AD connector
originally) and emphasized the *tenantRef* parameter. As in my case, I
was constructing the group name as
icfs:name="cn=Readonly_<tenant_name>,..." I needed to get the
organization (tenant) object and get its name first.


|. . .
        ||<||association||>|
|            |*|<|**|ref|**|>ri:adGroups</|**|ref|**|>|*
|            ||<||outbound||>|
|                ||<||source||>|
|                    ||<||path||>$assignment/*tenantRef*</||path||>|
|                ||</||source||>|
|                ||<||expression||>|
|                    ||<||associationTargetSearch||>|
|                        ||<||filter||>|
|                            ||<||q:equal||>|
|                                ||<||q:path||>||attributes/icfs:name||</||q:path||>
<!-- icfs:name because .NET AD connector -->
|
|                                ||<||expression||>|
|                                    ||<||script||>|
|                                        ||<||code||>|
|if (!basic.isEmpty(*tenantRef*)) {|
|  ||org = midpoint.getOrgByOid(*tenantRef*?.getOid())|
|  ||if (org != null) return *'cn=ReadOnly_' + **org?.getName()**+
',ou=portal-groups,dc=example,**dc=com'**
*|
|}|
|</||code||>|
|                                    ||</||script||>|
|                                ||</||expression||>|
|                            ||</||q:equal||>|
|                        ||</||filter||>|
|                   
||<searchStrategy>onResourceIfNeeded</searchStrategy>|||
|                    ||</||associationTargetSearch||>|
|                ||</||expression||>|
|            ||</||outbound||>|
|        ||</||association||>
. . .
|

The <searchStrategy> will only look up the group name if the shadow for
it does not exist in repository, so it will be quite fast for all except
the very first time.

In the example you refer to, you are setting resource attribute "dummy"
to the assignment description (which is of course one of the
assignment's parameters, too). It's not setting anything related to
roles. You need to combine in the association outbound mapping.

The outbound in association should return group DN or other searchable
attribute so that repository or provisioning can search for the shadow
object. And the group is identifier by whatever + assignment parameter
of your choice. In my previous example, the resource configuration for
association is (simplified) - again this is the old .NET AD connector,
so the attribute names might differ:

            <association>
*                **<ref>ri:adGroups</ref>*
                <tolerant>true</tolerant>
                <matchingRule>mr:stringIgnoreCase</matchingRule>
                <kind>entitlement</kind>
                <intent>group-portal-users</intent>
                <direction>objectToSubject</direction>
                <associationAttribute>ri:member</associationAttribute>
                <valueAttribute>icfs:name</valueAttribute>
              
<explicitReferentialIntegrity>false</explicitReferentialIntegrity>
              
<shortcutAssociationAttribute>icfs:groups</shortcutAssociationAttribute>
               <shortcutValueAttribute>icfs:name</shortcutValueAttribute>
            </association>

Of course I'm also constructing the groups, in this case, intent
group-portal, in the same resource.

Best regards,
Ivan

On 29.06.2018 23:20, Nicolas Rossi wrote:
> Hi guys, we made some progress on this but we still have some doubts.
> We defined a "dummy" property on the user schema and we mapped an
> assignment parameter to this property:
>
> <role>
> ...
>     <inducement>
>         <construction>
>             <resourceRef oid="702ecc89-deba-4542-9618-5b9c8ba94abe"
> type="ResourceType"/>
>             <kind>account</kind>
>             <attribute>
>                 <ref>*ri:dummy*</ref>
>                 <outbound>
>                     <source>
>                         <path>*$assignment/description*</path>
>                     </source>
>                 </outbound>
>             </attribute>
>         </construction>
>     </inducement>
> ...
> </role>
>
> When the role is assigned to the user the connector receives an
> AddAttributeValue operation on the "roles" attribute and then an
> Update operation on the "dummy" attribute with the value defined on
> the assignment. It works fine but It doesn't meet our requirements
> because we need the parameter value on the context of the
> AddAttributeValue operation. 
>
> In the past we had a similar issue with the Google Apps connector
> <https://github.com/Evolveum/midpoint/blob/master/samples/resources/googleapps/googleapps-resource.xml>because
> the groups membership also has an additional field to represent the
> relationship type (e.g. OWNER, MEMBER). Do you know where we can find
> some working examples of this configuration ? I mean a complex
> association between AccountObjectClass, GroupObjectClass
> and CustomMemberObjectClass.
>
> Thanks in advance,
>
>
>
> Ing Nicolás Rossi
> Identicum S.A.
> Jorge Newbery 3226
> Tel: +54 (11) 4552-3050
> www.identicum.com <http://www.identicum.com>
>
>
> On Fri, Jun 29, 2018 at 2:09 PM Nicolas Rossi <nrossi at identicum.com
> <mailto:nrossi at identicum.com>> wrote:
>
>     Hi Ivan, we found the assignment properties and we also extended
>     the AssignmentType for other project but we don't know how to
>     specify in a role definition that a property on the assignment is
>     mandatory. Is there any way to do that ?
>
>     On the other hand we are working on a Rest Connector and I
>     couldn't find any example to access the assignment parameters when
>     provisioning the role to the resource.
>
>     Regarding the issue at Jira, what does Evolveum need to continue
>     the development? Maybe we can find some support from our customers
>     to achieve that. 
>
>     Kind regards,
>
>
>
>
>     Ing Nicolás Rossi
>     Identicum S.A.
>     Jorge Newbery 3226
>     Tel: +54 (11) 4552-3050
>     www.identicum.com <http://www.identicum.com>
>
>
>     On Fri, Jun 29, 2018 at 4:03 AM Ivan Noris
>     <ivan.noris at evolveum.com <mailto:ivan.noris at evolveum.com>> wrote:
>
>         Hi Nicolas,
>
>         when I was working with parametric roles, I was using an
>         approach which I described here:
>         https://evolveum.com/blog/working-multi-tenant-roles/
>
>         (The screenshots are from old midpoint :-) but you should get
>         the message.)
>
>         By default you can assign roles with parameters: orgRef or
>         tenantRef:
>
>         - orgRef: you select (probably any) of the organizations in
>         midPoint to be the parameter
>
>         - tenantRef: you select any organization marked as tenant in
>         midPoint to be the parameter
>
>         This might help you as it is (we were / are using this in
>         multiple deployments).
>
>         What we definitely want is to make this more configurable and
>         extensible. But I'm sure Radovan will prove more on this topic.
>
>         I believe the feature is tracked here:
>         https://jira.evolveum.com/browse/MID-3515
>
>         Best regards,
>         Ivan
>
>         On 29.06.2018 00:11, Nicolas Rossi wrote:
>>         Hi guys, 
>>
>>         We are working on a customer who needs to define some roles
>>         with parameters to prevent role explosion scenario. I have
>>         found lot of references to this issue on the wiki (here
>>         <https://wiki.evolveum.com/display/midPoint/Role+Explosion>,
>>         here
>>         <https://wiki.evolveum.com/display/midPoint/Advanced+Hybrid+RBAC#AdvancedHybridRBAC-ParametricRoles>
>>         and here
>>         <https://wiki.evolveum.com/display/midPoint/Assignment+Configuration#AssignmentConfiguration-ParametricAssignments>).
>>         There were also similar question
>>         <https://lists.evolveum.com/pipermail/midpoint/2013-July/000096.html>s
>>         on the mailing list few years ago where Radovan explains that
>>         is was designed but not implemented.
>>
>>         Regarding the Radovan explanation I am not sure if we should
>>         extend the AssociationType to add custom parameters or if we
>>         should define role parameters (couldn't find any example on
>>         the documentation).
>>
>>         On the UI when and end-user request a new role, he can define
>>         properties on the assignment (parameters) for each role,
>>         but... is there any way to define that some properties /
>>         parameters are required so the user can't request the role
>>         without specifying some value for that parameter ?
>>
>>         I apologize in advance for the lengthy e-mail
>>
>>         Thanks,
>>
>>
>>         Ing Nicolás Rossi
>>         Identicum S.A.
>>         Jorge Newbery 3226
>>         Tel: +54 (11) 4552-3050
>>         www.identicum.com <http://www.identicum.com>
>>
>>
>>         _______________________________________________
>>         midPoint mailing list
>>         midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>         http://lists.evolveum.com/mailman/listinfo/midpoint
>
>         -- 
>         Ivan Noris
>         Senior Identity Engineer
>         evolveum.com <http://evolveum.com>
>
>         _______________________________________________
>         midPoint mailing list
>         midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>         http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> 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/20180702/ce0d761c/attachment.htm>


More information about the midPoint mailing list