[midPoint] Role Explosion and Role Parameters
Ivan Noris
ivan.noris at evolveum.com
Mon Jul 2 16:57:07 CEST 2018
Hi Nicolas,
as I said, this was the customer scenario and you are right that the
number of groups was still high - but that was because the underlying
systems usign that groups were not directly "tenant-oriented". This was
the way which was (is) possible usign standard means, standard connectors.
In the described scenario customer was also creating the entitlements
(groups) for e.g. AD. But there were other applications, where the roles
were created in the application automatically and they were just
returned by the connectors using the search, so for each found tenant
entitlement a shadow was created in midPoint. Maybe the roles were not
actually created - but connector was programmed to return a shadow so
that it can be used.
I will think of more possibilities, or some of my coleagues mat fill the
gaps in this tenant-oriented scenario; but some of the coleagues are
certainly on their vacations. If I come with something, I will share.
Regarding sponsorship/subscription: feel free to contact Martina, she
will be certainly more capable in answering this aspect.
Best regards,
Ivan
On 02.07.2018 15:01, Nicolas Rossi wrote:
> 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 <http://www.identicum.com>
>
>
> On Mon, Jul 2, 2018 at 4:13 AM Ivan Noris <ivan.noris at evolveum.com
> <mailto: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 <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 <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/597aa421/attachment.htm>
More information about the midPoint
mailing list