<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Salim,<br>
<br>
On 07/18/2013 03:57 PM, Salim Boulkour wrote:<br>
</div>
<blockquote
cite="mid:6A4871F676BC4A4D881CA53C32575A28031081FC@exbe07.ad.hosteam.fr"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Courier New \;color\:windowtext";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"Préformaté HTML Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texte de bulles Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-priority:99;
mso-style-link:"Préformaté HTML";
font-family:"Courier New";}
span.TextedebullesCar
{mso-style-name:"Texte de bulles Car";
mso-style-priority:99;
mso-style-link:"Texte de bulles";
font-family:"Tahoma","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Tahoma","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:28382959;
mso-list-type:hybrid;
mso-list-template-ids:-269607804 -596084110 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l0:level1
{mso-level-start-at:2013;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Tahoma","sans-serif";
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1"><span style="color:#1F497D" lang="EN-US">I’ve
read from the <a moz-do-not-send="true"
href="https://wiki.evolveum.com/display/midPoint/Advanced+RBAC">https://wiki.evolveum.com/display/midPoint/Advanced+RBAC</a>
page that midpoint implements parametric roles.<o:p></o:p></span>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">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.</span></p>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:6A4871F676BC4A4D881CA53C32575A28031081FC@exbe07.ad.hosteam.fr"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p>From
my comprehension, those role parameters are listed somewhere
to give role/parameter association, and limit parameter
permitted values.</span></p>
</div>
</blockquote>
<br>
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).<br>
<br>
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 :-)<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:6A4871F676BC4A4D881CA53C32575A28031081FC@exbe07.ad.hosteam.fr"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Then,
how much parameter lists can I associate to a role ? Lets
take an example.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">Then
I would have one role : role_salesman<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">And
three parametric lists : [area][client][product]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">So,
is it possible to have multiple parameters associated to a
role ?</span></p>
</div>
</blockquote>
<br>
Yes, this is possible even now. The number of parameters is not
limited.<br>
<br>
<blockquote
cite="mid:6A4871F676BC4A4D881CA53C32575A28031081FC@exbe07.ad.hosteam.fr"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D" lang="EN-US">And
is it possible to have multiple values ? Like vendor to both
EMEA and ASIA areas, and 3 or 4 different lines of products
?</span></p>
</div>
</blockquote>
<br>
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:<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
</body>
</html>