[midPoint] Authorizations not being inherited
Rodrigo Yanis
ryanis at identicum.com
Wed Apr 5 14:38:40 CEST 2017
Pavol,
We've chosen to restrain from implementing org hierarchy until we're in
conditions to migrate to 3.6.
I'll tell you how it goes when that happens!
Thanks for your insights and concern.
Regards,
*Rodrigo Yanis.*
Identicum S.A.
Jorge Newbery 3226
Tel: +54 (11) 4552-3050
ryanis at identicum.com
www.identicum.com
2017-04-03 14:37 GMT-03:00 Pavol Mederly <mederly at evolveum.com>:
> Hello Rodrigo,
>
> I have looked at the source code for 3.5. Your observations correlate well
> with the sources:
>
> https://github.com/Evolveum/midpoint/blob/support-3.5/
> model/model-impl/src/main/java/com/evolveum/midpoint/model/impl/lens/
> AssignmentEvaluator.java#L758
>
> In order to authorizations be applied, summary evaluation order should be
> 1. So now I see why unbounded max order does not work.
>
> Unfortunately, I don't see an easy fix, other than setting <authorization>
> on each org struct element, or inducing a role carrying this
> <authorization> from each org struct element. As far as I know, this could
> be achieved automatically using an object template - not very elegant
> solution, but it might work.
>
> Or, maybe someone else has a nicer workaround for this.
>
> (I briefly thought of fixing this in support branch in 3.5 but - honestly
> - I'm afraid of making any significant changes into non-refactored
> AssignmentEvaluator. In 3.6 this will certainly work.)
>
> Best regards,
>
> Pavol Mederly
> Software developerevolveum.com
>
> On 03.04.2017 18:40, Rodrigo Yanis wrote:
>
> 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/As
>> signmentPathSegmentImpl.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/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/20170405/a9a648f5/attachment.htm>
More information about the midPoint
mailing list