[midPoint] Role Explosion and Role Parameters
Nicolas Rossi
nrossi at identicum.com
Mon Jul 2 15:01:02 CEST 2018
Hi Ivan, thank you for the information but I think this is not the same
scenario here. You evaluate the assignment parameters to find a role /
group on the target system and the resource always receives an entitlement,
no matter how it was requested. On that way you prevent the role explosion
in midPoint but you have the cartesian product on the resource.
Our customer has lot of applications that use few roles but with several
parameters and we have to provide that context when providing the
entitlement.
It looks like the assignment configuration does not apply to our
requirement and we need parametric roles. The customer has a deployment
subscription not a platform one. We have to explore the sponsoring model to
this feature. Should I contact Martina for that ?
Kind regards,
Ing Nicolás Rossi
Identicum S.A.
Jorge Newbery 3226
Tel: +54 (11) 4552-3050
www.identicum.com
On Mon, Jul 2, 2018 at 4:13 AM Ivan Noris <ivan.noris at evolveum.com> wrote:
> 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
>
>
> On Fri, Jun 29, 2018 at 2:09 PM Nicolas Rossi <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
>>
>>
>> On Fri, Jun 29, 2018 at 4:03 AM Ivan Noris <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
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>> --
>>> Ivan Noris
>>> Senior Identity Engineerevolveum.com
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> --
> Ivan Noris
> Senior Identity Engineerevolveum.com
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180702/22e638b5/attachment.htm>
More information about the midPoint
mailing list