[midPoint] Role template "role-sailor"

[Radovan Semancik]

Hi Salim,

On 07/18/2013 03:57 PM, Salim Boulkour wrote:
> I've read from the 
> https://wiki.evolveum.com/display/midPoint/Advanced+RBAC page that 
> midpoint implements parametric roles.
>
> This is pretty convenient from our point of view and it is the first 
> time we see it implemented in an IM product without having to use 
> custom code everywhere.
>

Good to see that. This is exactly our long-term goal with midPoint: more 
configuration, less coding. Efficient deployment and maintenance. I'm 
glad that you like it.

> From my comprehension, those role parameters are listed somewhere to 
> give role/parameter association, and limit parameter permitted values.
>

Yes and no. The parameter values are currently taken from either static 
schemas (usually schema for UserType object) or schema extensions along 
the role hierachy (user extension, assignment extension, inducement 
extension). This works great in reducing the number of roles in RBAC 
structure and fighting the role explosion problem. It was designed 
primarily for roles that will be assigned automatically using rules (in 
a RB-RBAC fashion).

The interactive side of parametric roles is still slightly unfinished. 
The role has no way how to specify what parameters it needs. This was 
not needed for the automatic approach but it is definitely needed for 
advanced RBAC GUI. We have quite concrete design for this aspect: adding 
a parameter schema to the role. And I can assure you that it is no kind 
of afterthough but quite an integral part of the entire solution. We 
have spend a lot of time designing it but we haven't spend much time on 
implementing it yet. There was a very limited customer demand and 
therefore we have problems justifying the development cost. Even the 
current parametric RBAC design seems to be too advanced for many 
engineers that are used to work with other IDM products. Yet the plans 
may change if there is sufficient motivation ... as always :-)

Which also means that there is currently no convenient way how to 
specify permitted values for these parameters. This should be possible 
with the introduction of role parameter schema and some dynamic schema 
definition improvements. This is quite advanced stuff and therefore we 
do not have a concrete plan when to implement it. However if you have an 
idea how to fund this part of the development we definitely can talk 
about it.

> Then, how much parameter lists can I associate to a role ? Lets take 
> an example.
>
> Imagine we have a team of sales men. They have different access right 
> in the sale app depending on their geographic area, on their type of 
> clients and on their line of products.
>
> Then I would have one role : role_salesman
>
> And three parametric lists : [area][client][product]
>
> So, is it possible to have multiple parameters associated to a role ?
>

Yes, this is possible even now. The number of parameters is not limited.

> And is it possible to have multiple values ? Like vendor to both EMEA 
> and ASIA areas, and 3 or 4 different lines of products ?
>

I don't think I completely understand this question. Currently there is 
no list of permitted values as stated above. But even if there would be 
a list of permitted values then each of the parameters is independent. 
Therefore you could have vendor with values  [ACME, Example, 
Whatchacalit], area with values [EMEA, ASIA] and products [foo, bar, 
baz, foobar]. Any combination of these could be assigned. The schema 
will not limit the combinations. That would be perhaps too much to ask 
from a schema. However, if you want to limit possible combinations that 
might be possible by using two approaches:

1) conditions and expressions in role definition. These may throw an 
error if a "bad" combination is present. Not very convenient from GUI 
perspective but quite simple to do and quite secure (e.g. even 
webservice/rest invocation will be unable to set incorrect combination).

2) some tweaks in the GUI. This may be convenient for the user. But 
currently it means modifying the GUI code. midPoint is opensource so 
this is not such a big obstacle when compared to commercial products. We 
have a plan to have flexible forms similar to those used in Sun IDM 
(Waveset), but this is also quite a distant future. But whatever method 
you use it is still just a check in the presentation logic and can be 
theoretically circumvented.

So in practice you probably would need both. I recommend starting with 
method 1) if your deployment strategy alllows that and then improve it 
with convenience in next deployment phases.


-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20130719/196a12aa/attachment.htm>