[midPoint] Authorizations not being inherited
Pavol Mederly
mederly at evolveum.com
Mon Apr 3 19:37:00 CEST 2017
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 developer
evolveum.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 <mailto:ryanis at identicum.com>
> www.identicum.com <http://www.identicum.com/>
>
> 2017-03-31 18:01 GMT-03:00 Pavol Mederly <mederly at evolveum.com
> <mailto: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
> <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 developer
> evolveum.com <http://evolveum.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 <mailto:ryanis at identicum.com>
>> www.identicum.com <http://www.identicum.com/>
>>
>> 2017-01-10 10:08 GMT-03:00 Martin Marchese
>> <mmarchese at identicum.com <mailto: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 <mailto:mmarchese at identicum.com>
>> www.identicum.com <http://www.identicum.com>
>>
>> On Mon, Jan 9, 2017 at 10:45 AM, Pavol Mederly
>> <mederly at evolveum.com <mailto: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 developer
>> evolveum.com <http://evolveum.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 developer
>>> evolveum.com <http://evolveum.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/common-3
>>>> <http://midpoint.evolveum.com/xml/ns/public/common/common-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
>>>> <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
>>>> <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 <mailto:mmarchese at identicum.com>
>>>> 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
>>>> <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
>>> <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
>> <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
>> <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
>> <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
> <http://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/2747185f/attachment.htm>
More information about the midPoint
mailing list