Re: Re: Users and Roles Confusion

--94eb2c1ce1a641551c0558c425e7
Content-Type: text/plain; charset="UTF-8"

Oh you're looking at the "relational rbac" (a term I made up) problem,
which rbac explicitly didn't handle as a security problem. This is
basically where you need to combine an RBAC, with another security model
such as DAC. In some ways ABAC is supposed to be this, but, I haven't found
a great definition of ABAC that's not "do what you need".

Another thing I've noticed, and I'm not sure on the chicken and the egg,
but is that business people have started pulling the security domain into
their business terminology. Security Terminology they don't understand and
doesn't always fit the actuality of either security needs or business
needs. An example of ours is business people know about roles, but have
never seemed to learn that the real security behind roles is permissions,
so we have permissions, but when they talk to us they ignore them.

Firstly, you can do a lot of things through your "security session", or in
combination with accessing your security session. For example we have a
problem where our "field level" view is restricted based on business logic
that is centered on the principal's organization. At one time this was a
nasty if && || && || chain. It was replaced by a strategy pattern, where
the strategy was set up based on your principal's org type, then the
internal implementation could vary. This particular implementation is
neither with the security domain, or called out by business people, but
after looking at how it was thought about, it became the cleanest way to
implement it.

Another example in our app is when the business people wanted a way to
"fake" being certain users. After listening to the problem I realized, they
don't want to fake being a certain user, what they want is to be that users
Role, and appear as within their Org, but our existing model had no way to
have an "active role", since it's an incomplete RBAC impl, also RBAC has no
actual concept of Organization. So what we ended up doing was adding
"Active Role/Active Org" to our security session. They had wanted to
restrict this to a specific org type, and we did that, but a few months ago
they wanted more, fortunately for us we had built this around the general
RBAC design, and it was easy remove/add more org types, without changing a
lot of code.

You'll notice multiple times we're accessing an organization in our
security session, but it's also important to realize that the
"organization" in our security session is a lighter, serializable,
replicated class from our entity version. This lends itself further to the
"bounded context" aspect of the security domain.

Spring Security ACL uses provides an interesting way of dealing with
hierarchies of objects with permissions and ownership. Using that
implementation may not work for you, but the database tables might provide
some inspiration on top of using roles.

There is no silver bullet to Authorization Access models, especially in a
rich domain. However understanding existing models and solutions will help
you build one that fits you.

On Fri, Sep 8, 2017 at 4:23 PM chambrenoire [email protected]
[domaindrivendesign] <[email protected]> wrote:

> I guess I'm just used to (probably naively) baking these things into the
> domain. I've been reading up on rbac/abac/instance-based ac and whilst I
> understand grouping activities/permissions into roles/profiles and testing
> against activities etc... it's how this relates/replaces/complements
> relationships between entities which confuses me. For instance, in my
> simple
> scenario, if I'm testing whether the user (an Assistant) can view a Client,
> I iterate through the Assistant's assigned Managers and in turn iterate
> though their associated (owned) Clients until I find a match. No
> permissions
> involved. This seems clunky and whilst I'm interested in adopting more
> virtuous domain modelling practices (such as ddd) I'm getting blocked on
> this.
>
>
>
> --
> Sent from: http://domain-driven-design.3010926.n2.nabble.com/
>
>
> ------------------------------------
> Posted by: chambrenoire <[email protected]>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
> --
Caleb Cushing

http://xenoterracide.com

--94eb2c1ce1a641551c0558c425e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





<head>

<style type=3D"text/css">
<!--

/* start of attachment style */
       .ygrp-photo-title{
         clear: both;
         font-size: smaller;
         height: 15px;
         overflow: hidden;
         text-align: center;
         width: 75px;
       }
       div.ygrp-photo{
         background-position: center;
         background-repeat: no-repeat;
         background-color: white;
         border: 1px solid black;
         height: 62px;
         width: 62px;
       }

       div.photo-title=20
         a,
         div.photo-title a:active,
         div.photo-title a:hover,
         div.photo-title a:visited {
           text-decoration: none;=20
       }

       div.attach-table div.attach-row {
         clear: both;
       }

       div.attach-table div.attach-row div {
         float: left;
         /* margin: 2px;*/
       }

       p {
         clear: both;
         padding: 15px 0 3px 0;
	 overflow: hidden;
       }

       div.ygrp-file {
         width: 30px;
         valign: middle;
       }
       div.attach-table div.attach-row div div a {
         text-decoration: none;
       }

       div.attach-table div.attach-row div div span {
         font-weight: normal;
       }

       div.ygrp-file-title {
         font-weight: bold;
       }
 /* end of attachment style */
        -->
        </style>
        </head>
<html>
<head>
<style type=3D"text/css">
<!--
#ygrp-mkp {
  border: 1px solid #d8d8d8;
  font-family: Arial;
  margin: 10px 0;
  padding: 0 10px;
}

#ygrp-mkp hr {
  border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
  color: #628c2a;
  font-size: 85%;
  font-weight: 700;
  line-height: 122%;
  margin: 10px 0;
}

#ygrp-mkp #ads {
  margin-bottom: 10px;
}

#ygrp-mkp .ad {
  padding: 0 0;
}

#ygrp-mkp .ad p {
  margin: 0;
}

#ygrp-mkp .ad a {
  color: #0000ff;
  text-decoration: none;
}
-->
</style>
</head>
<body>



<!-- |**|begin egp html banner|**| -->

<br><br>

<!-- |**|end egp html banner|**| -->


<div dir=3D"ltr">Oh you&#39;re looking at the &quot;relational rbac&quot; (=
a term I made up) problem, which rbac explicitly didn&#39;t handle as a sec=
urity problem. This is basically where you need to combine an RBAC, with an=
other security model such as DAC. In some ways ABAC is supposed to be this,=
 but, I haven&#39;t found a great definition of ABAC that&#39;s not &quot;d=
o what you need&quot;.=C2=A0<div><br></div><div>Another thing I&#39;ve noti=
ced, and I&#39;m not sure on the chicken and the egg, but is that business =
people have started pulling the security domain into their business termino=
logy. Security Terminology they don&#39;t understand and doesn&#39;t always=
 fit the actuality of either security needs or business needs. An example o=
f ours is business people know about roles, but have never seemed to learn =
that the real security behind roles is permissions, so we have permissions,=
 but when they talk to us they ignore them.<div><br>Firstly, you can do a l=
ot of things through your &quot;security session&quot;, or in combination w=
ith accessing your security session. For example we have a problem where ou=
r &quot;field level&quot; view is restricted based on business logic that i=
s centered on the principal&#39;s organization. At one time this was a nast=
y if &amp;&amp; || &amp;&amp; || chain. It was replaced by a strategy patte=
rn, where the strategy was set up based on your principal&#39;s org type, t=
hen the internal implementation could vary. This particular implementation =
is neither with the security domain, or called out by business people, but =
after looking at how it was thought about, it became the cleanest way to im=
plement it.<br><br>Another example in our app is when the business people w=
anted a way to &quot;fake&quot; being certain users. After listening to the=
 problem I realized, they don&#39;t want to fake being a certain user, what=
 they want is to be that users Role, and appear as within their Org, but ou=
r existing model had no way to have an &quot;active role&quot;, since it&#3=
9;s an incomplete RBAC impl, also RBAC has no actual concept of Organizatio=
n. So what we ended up doing was adding &quot;Active Role/Active Org&quot; =
to our security session. They had wanted to restrict this to a specific org=
 type, and we did that, but a few months ago they wanted more, fortunately =
for us we had built this around the general RBAC design, and it was easy re=
move/add more org types, without changing a lot of code.</div><div><br>You&=
#39;ll notice multiple times we&#39;re accessing an organization in our sec=
urity session, but it&#39;s also important to realize that the &quot;organi=
zation&quot; in our security session is a lighter, serializable, replicated=
 class from our entity version. This lends itself further to the &quot;boun=
ded context&quot; aspect of the security domain.<br><br>Spring Security ACL=
 uses provides an interesting way of dealing with hierarchies of objects wi=
th permissions and ownership. Using that implementation may not work for yo=
u, but the database tables might provide some inspiration on top of using r=
oles.<br><br>There is no silver bullet to Authorization Access models, espe=
cially in a rich domain. However understanding existing models and solution=
s will help you build one that fits you.<br><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Fri, Sep 8, 2017 at 4:23 PM chambrenoire <a href=3D"mai=
lto:[email protected]">[email protected]</a> [domaindrivendesign] &lt;<a =
href=3D"mailto:[email protected]">domaindrivendesign@yahoo=
groups.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess =
I&#39;m just used to (probably naively) baking these things into the<br>
domain. I&#39;ve been reading up on rbac/abac/instance-based ac and whilst =
I<br>
understand grouping activities/permissions into roles/profiles and testing<=
br>
against activities etc... it&#39;s how this relates/replaces/complements<br=
>
relationships between entities which confuses me. For instance, in my simpl=
e<br>
scenario, if I&#39;m testing whether the user (an Assistant) can view a Cli=
ent,<br>
I iterate through the Assistant&#39;s assigned Managers and in turn iterate=
<br>
though their associated (owned) Clients until I find a match. No permission=
s<br>
involved. This seems clunky and whilst I&#39;m interested in adopting more<=
br>
virtuous domain modelling practices (such as ddd) I&#39;m getting blocked o=
n<br>
this.<br>
<br>
<br>
<br>
--<br>
Sent from: <a href=3D"http://domain-driven-design.3010926.n2.nabble.com/" r=
el=3D"noreferrer" target=3D"_blank">http://domain-driven-design.3010926.n2.=
nabble.com/</a><br>
<br>
<br>
------------------------------------<br>
Posted by: chambrenoire &lt;<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>&gt;<br>
------------------------------------<br>
<br>
<br>
------------------------------------<br>
<br>
Yahoo Groups Links<br>
<br>
&lt;*&gt; To visit your group on the web, go to:<br>
=C2=A0 =C2=A0 <a href=3D"http://groups.yahoo.com/group/domaindrivendesign/"=
 rel=3D"noreferrer" target=3D"_blank">http://groups.yahoo.com/group/domaind=
rivendesign/</a><br>
<br>
&lt;*&gt; Your email settings:<br>
=C2=A0 =C2=A0 Individual Email | Traditional<br>
<br>
&lt;*&gt; To change settings online go to:<br>
=C2=A0 =C2=A0 <a href=3D"http://groups.yahoo.com/group/domaindrivendesign/j=
oin" rel=3D"noreferrer" target=3D"_blank">http://groups.yahoo.com/group/dom=
aindrivendesign/join</a><br>
=C2=A0 =C2=A0 (Yahoo! ID required)<br>
<br>
&lt;*&gt; To change settings via email:<br>
=C2=A0 =C2=A0 <a href=3D"mailto:[email protected]" =
target=3D"_blank">[email protected]</a><br>
=C2=A0 =C2=A0 <a href=3D"mailto:domaindrivendesign-fullfeatured@yahoogroups=
.com" target=3D"_blank">[email protected]</a>=
<br>
<br>
&lt;*&gt; To unsubscribe from this group, send an email to:<br>
=C2=A0 =C2=A0 <a href=3D"mailto:domaindrivendesign-unsubscribe@yahoogroups.=
com" target=3D"_blank">[email protected]</a><b=
r>
<br>
&lt;*&gt; Your use of Yahoo Groups is subject to:<br>
=C2=A0 =C2=A0 <a href=3D"https://info.yahoo.com/legal/us/yahoo/utos/terms/"=
 rel=3D"noreferrer" target=3D"_blank">https://info.yahoo.com/legal/us/yahoo=
/utos/terms/</a><br>
<br>
</blockquote></div></div></div></div><div dir=3D"ltr">-- <br></div><div cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
Caleb Cushing<div><br></div><div><a href=3D"http://xenoterracide.com">http:=
//xenoterracide.com</a></div></div></div>




<!-- |**|begin egp html banner|**| -->

<br>


<br>

<!-- |**|end egp html banner|**| -->


<div width=3D"1" style=3D"color: white; clear: both;"/>__._,_.___</div>

=20=20=20=20=20=20
=20=20

=20=20=20=20
    <div id=3D"fromDMARC" style=3D"clear:both; margin-top: 10px;">
         <hr style=3D"height:2px ; border-width:0; color:#E3E3E3; backgroun=
d-color:#E3E3E3;">
         Posted by: Caleb Cushing &lt;[email protected]&gt;         <=
hr style=3D"height:2px ; border-width:0; color:#E3E3E3; background-color:#E=
3E3E3;">
    </div>
<!-- Start Recommendations -->
<!-- End Recommendations -->



<!-- |**|begin egp html banner|**| -->

  <img src=3D"http://geo.yahoo.com/serv?s=3D97476590/grpId=3D8116923/grpspI=
d=3D1705007181/msgId=3D24835/stime=3D1504976193" width=3D"1" height=3D"1"> =
<br>

<!-- |**|end egp html banner|**| -->

=20=20
<!-- |**|begin egp html banner|**| -->

<br>



=20=20=20
=20=20=20=20=20
=20
        <!-- |**|begin egp html banner|**| -->
        <div id=3D"ygrp-vital" style=3D"background-color: #f2f2f2; font-fam=
ily: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

        <span id=3D"vithd" style=3D"font-weight: bold; color: #333; text-tr=
ansform: uppercase; "><a href=3D"https://groups.yahoo.com/neo/groups/domain=
drivendesign/info;_ylc=3DX3oDMTJldjAxbWNjBF9TAzk3MzU5NzE0BGdycElkAzgxMTY5Mj=
MEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTUwNDk3NjE5Mw--"=
 style=3D"text-decoration: none;">Visit Your Group</a></span>

     <ul style=3D"list-style-type: none; margin: 0; padding: 0; display: in=
line;">
            <li style=3D"border-right: 1px solid #000; font-weight: 700; di=
splay: inline; padding: 0 5px; margin-left: 0;">
      <span class=3D"cat"><a href=3D"https://groups.yahoo.com/neo/groups/do=
maindrivendesign/members/all;_ylc=3DX3oDMTJmNWFiMjM4BF9TAzk3MzU5NzE0BGdycEl=
kAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE1MD=
Q5NzYxOTM-" style=3D"text-decoration: none;">New Members</a></span>
      <span class=3D"ct" style=3D"color: #ff7900;">2</span>
    </li>
                                              </ul>
  </div>


<div id=3D"ft" style=3D"font-family: Arial; font-size: 11px; margin-top: 5p=
x; padding: 0 2px 0 0; clear: both;">
  <a href=3D"https://groups.yahoo.com/neo;_ylc=3DX3oDMTJkbWk0MmlwBF9TAzk3ND=
c2NTkwBGdycElkAzgxMTY5MjMEZ3Jwc3BJZAMxNzA1MDA3MTgxBHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNTA0OTc2MTkz" style=3D"float: left;"><img src=3D"http://l.yimg.com/r=
u/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height=3D"15"=
 width=3D"137" alt=3D"Yahoo! Groups" style=3D"border: 0;"/></a>
  <div style=3D"color: #747575; float: right;"> &bull; <a href=3D"https://i=
nfo.yahoo.com/privacy/us/yahoo/groups/details.html" style=3D"text-decoratio=
n: none;">Privacy</a> &bull; <a href=3D"mailto:domaindrivendesign-unsubscri=
[email protected]?subject=3DUnsubscribe" style=3D"text-decoration: none;">=
Unsubscribe</a> &bull; <a href=3D"https://info.yahoo.com/legal/us/yahoo/uto=
s/terms/" style=3D"text-decoration: none;">Terms of Use</a> </div>
</div>

<!-- |**|end egp html banner|**| -->

  </div> <!-- ygrp-msg -->

=20=20=20


  <br>

<!-- |**|end egp html banner|**| -->


<div style=3D"color: white; clear: both;"/>__,_._,___</div>
</body>

</html>

--94eb2c1ce1a641551c0558c425e7--