[midPoint] Authorizations not being inherited
Pavol Mederly
mederly at evolveum.com
Fri Mar 31 23:01:43 CEST 2017
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 developer
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
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170331/920a0acf/attachment.htm>
More information about the midPoint
mailing list