[midPoint] Authorizations not being inherited

Rodrigo Yanis ryanis at identicum.com
Mon Apr 3 18:40:11 CEST 2017


Pavol,

That is exactly the case I was describing, yes. Thanks for you thorough
explanation. I tried your recommendation by configuring the inducement to
the role with an unbounded max order, as well as the minimum order with 1 -
unfortunately this didn't work. We are currently running under midpoint 3.5.
I've been trying a few other scenarios too, and I was able to successfully
propagate authorizations inheritance under the following model:

OrgA (Root Org)
 |
[A]
 |
OrgB-----[I]----->OrgA
 |
[A]
 |
User

Only by inducing OrgA into OrgB the inheritance worked. I also tried adding
a new OrgC as a child to OrgB, and authorizations would work only after
inducing OrgB into OrgC.

Thanks again



*Rodrigo Yanis.*
Identicum S.A.
Jorge Newbery 3226
Tel: +54 (11) 4824-9971
ryanis at identicum.com
www.identicum.com

2017-03-31 18:01 GMT-03:00 Pavol Mederly <mederly at evolveum.com>:

> Hello Rodrigo,
>
> so you have something like this
>
> OrgA -----[I]-----> RoleA
>   ^
>   |
>   |
> OrgB
>   ^
>   |
>   |
> user
>
> "I" means inducement. Unlabeled edges are assignments. Although it may
> seem strange to you, imagine the same situation, but this time dealing with
> roles and metaroles:
>
> MetaroleA -----[I]-----> MetaroleB        .... "level 2"
>    ^
>    |
>    |
>  Pirate                                   .... "level 1"
>    ^
>    |
>    |
>  jack                                     .... "level 0"
>
> Now it's quite clear that the content (constructions, focus mappings, ...)
> attached to MetaroleB via simple inducements should not be applied to jack,
> but to the Pirate role. The reason is:
>
>    1. They reside at the level of "evaluation order 2".
>    2. The inducement itself is a standard one (with the order=1).
>    3. So the content of the inducement (constructions, focus mappings,
>    ...) applies to level 2-1 = 1, i.e. role Pirate.
>
> In the second case you'd need to use <order>2</order> for inducements to
> apply them to level 0, i.e. jack.
>
> But what about your original case with organizations?
>
> Here the situation is more complex, because you don't know the resulting
> level of RoleA: it depends on the number of organizational levels. However,
> for such cases midPoint provides "orderConstraint" element for inducements.
> In 3.5, you could specify your RoleA inducement with:
>
> <orderConstraint>
>   <minOrder>1</minOrder>
>   <maxOrder>unbounded</maxOrder>
> </orderConstraint>
> <focusType>UserType</focusType>            <!-- to disallow applying
> Role1 to organizations -->
>
> As far as I know, this should work.
>
> In 3.6 there are some changes, fixes, and clarifications for this
> mechanism, so minor changes would be needed.
>
> If you'd want more technical description (relevant to 3.6), here it is:
> https://github.com/Evolveum/midpoint/blob/master/model/
> model-impl/src/main/java/com/evolveum/midpoint/model/impl/lens/
> AssignmentPathSegmentImpl.java#L72
>
> Hope this helps,
>
> Pavol Mederly
> Software developerevolveum.com
>
> On 31.03.2017 22:41, Rodrigo Yanis wrote:
>
> Hello Pavol,
>
> Furthering on this issue - while removing *<focusType>UserType</focusType>
> *from the inducement definition solves authorization inheritance for when
> the user is assigned to the Org in which the inducement is defined, this
> doesn't seem to apply to assignment of Orgs that are child of this Org.
>
> For example, Org A defines inducement to role A with authorization
> definitions, Org B is then set to be child of Org A, Org B is then assigned
> to user. User is indirectly assigned to role A, but authorization does not
> work.
>
> Furthermore, if we define authorizations directly into Org A, and then
> assign Org B (child of A) to user, authorizations are not inherited.
>
> Do you think of any workaround for this scenario?
>
> Thanks,
>
>
> *Rodrigo Yanis.*
> Identicum S.A.
> Jorge Newbery 3226
> Tel: +54 (11) 4824-9971
> ryanis at identicum.com
> www.identicum.com
>
> 2017-01-10 10:08 GMT-03:00 Martin Marchese <mmarchese at identicum.com>:
>
>> Thanks Pavol for your answer. I just created a JIRA for this.
>>
>> *Ing. Martín Marchese*
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4552-3050
>> mmarchese at identicum.com
>> www.identicum.com
>>
>> On Mon, Jan 9, 2017 at 10:45 AM, Pavol Mederly <mederly at evolveum.com>
>> wrote:
>>
>>> Well... to be more precise: focusType check at that line expects that
>>> the focus type is present in LensContext. But, for the purpose of
>>> evaluation of user assignments during login, the focus type in LensContext
>>> is not filled-in.
>>>
>>> Please write the JIRA and we'll fix that.
>>>
>>> Pavol Mederly
>>> Software developerevolveum.com
>>>
>>> On 09.01.2017 14:41, Pavol Mederly wrote:
>>>
>>> Martin,
>>>
>>> I've played with your case for a while and it seems that
>>> *<focusType>UserType</focusType>* is the problem. After removing it,
>>> the authorizations are propagated correctly.
>>>
>>> I'm not sure why it is so; as it should work, as far as I know. I
>>> suspect a bug at AssignmentEvaluator:682, but I'm not sure.
>>>
>>> Maybe you could file a JIRA for this.
>>>
>>> Pavol Mederly
>>> Software developerevolveum.com
>>>
>>> On 03.01.2017 19:10, Martin Marchese wrote:
>>>
>>> Hi All,
>>>
>>> Within our MidPoint 3.5 deployment, we have created an Org Structure
>>> which induces a role to users.
>>>
>>> This role, contains all kind of authorizations for users (REST acccess,
>>> GUI access, etc).
>>>
>>> Once the organization is assigned to a user, it gets the role assigned
>>> but not the authorizations. However, if we assign the role directly to the
>>> user, all the authorizations are assigned OK.
>>>
>>> I was wondering if there is not any kind of order for authorizations (as
>>> it is for inducements). Or anything that we might be missing in our objects?
>>>
>>> Below, I send the examples of how our Org and Role look like:
>>>
>>>
>>> Org:
>>> -----
>>> <org oid="00000000-0000-1de4-0009-000000000001">
>>>    <name>MEGC</name>
>>> ...
>>>     <inducement id="6">
>>>       <targetRef oid="00000000-0000-1de4-0003-000000000001"
>>> type="RoleType"></targetRef>
>>>       <orderConstraint>
>>>         <orderMax>unbounded</orderMax>
>>>       </orderConstraint>
>>>       <focusType>UserType</focusType>
>>>      </inducement>
>>> ...
>>> </org>
>>>
>>> Role:
>>> -------
>>>
>>> <role oid="00000000-0000-1de4-0003-000000000001"
>>>       xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/c
>>> ommon-3">   <name>MidPoint Custom User</name>
>>>   <roleType>APPLICATION</roleType>
>>> <authorization>
>>> <description>Permisos GUI</description>
>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>> authorization-ui-3#selfDashboard</action>
>>> <action>http://midpoint.evolveum.com/xml/ns/public/security/
>>> authorization-ui-3#selfCredentials</action>
>>> </authorization>
>>> ...
>>> </role>
>>>
>>> Thanks in Advance
>>>
>>> *Ing. Martín Marchese*
>>> Identicum S.A.
>>> Jorge Newbery 3226
>>> Tel: +54 (11) 4552-3050
>>> mmarchese at identicum.com
>>> www.identicum.com
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>> _______________________________________________ midPoint mailing list
>>> midPoint at lists.evolveum.com http://lists.evolveum.com/mail
>>> man/listinfo/midpoint
>>
>> _______________________________________________ midPoint mailing list
>> midPoint at lists.evolveum.com http://lists.evolveum.com/mail
>> man/listinfo/midpoint
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> _______________________________________________
> 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/20170403/79f99002/attachment.htm>


More information about the midPoint mailing list