<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 16, 2012, at 9:18 PM, Shane Bryzak <<a href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 17/10/12 03:43, Boleslaw Dawidowicz
wrote:<br>
</div>
<blockquote cite="mid:CA1BC6D8-FEBE-415B-8741-3AC6E570D621@redhat.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I like this. One of biggest mistakes I made in the original model
was to define separate notion of user-group relationship. Design
where direct relationship is just another type of role (either
'member' or null) is much more elegant.
<div><br>
</div>
<div>The only concern is to keep Group tree and LDAP use case in
mind.</div>
<div><br>
</div>
<div><a moz-do-not-send="true" href="https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/model/Group.java">https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/model/Group.java</a></div>
<div><br>
</div>
<div>Path id is in place to ensure name uniqueness in the tree.
You can have a/b/a/b/a - which result in 3 groups with name "a"
and 2 groups with name "b". Then question is if this path should
be resolved on the fly from IdentityMembership (huge performance
cost and implementation nightmare) or stored as an id in
IdentityObject table during object creation. Second option is
better however name also persists relationships between groups
from the start. I have chosen first approach in PLIDM 1.x and
this was my second biggest regret - mostly because of
performance cost.</div>
</blockquote>
<br>
The LDAP use case is a good point - I'll need to think about it some
more, but I think we can make the path validation an implementation
detail. I agree we should go with the second option for the LDAP
implementation (because of it's strict tree structure), however I'm
thinking for JPA (in which we don't have the same restrictions) we
should possibly allow a Group to be a member of more than one parent
group. It's conceivable that there's use cases that require this,
however I'm not totally sold on the idea and would like to hear some
feedback.<br></div></blockquote><div><br></div>There are few other issues to keep in mind. </div><div><br></div><div>Like I tried to explain before in separate email I suggest to not decouple LDAP and JPA use cases too much. From my experience LDAP store is too limited to be used in separation. Then identity store federation is a bad idea - it seems flexible but has significant cost. Good approach is to just use LDAP identity store implementation to pull data and sync into. Then just query RDBMS implementation - because SQL is way more flexible and efficient to do complex queries. Actually often use case is that even if you have data in LDAP you still want to store in DB some info that doesn't fit LDAP schema.</div><div><br></div><div>All in all don't think about separate LDAP use case - assume that you will want to sync LDAP data into JPA store and map same structure there. Safest and most typical structure is probably 2-3 levels deep tree.</div><div><br></div><div>Another point for LDAP to JPA synchronisation. There is no way to implement LDAP store with efficient support of some queries. Some of operations that are easy to optimise in SQL will force you to download whole directory content and filter locally in case of LDAP. </div><div><br></div><div>For graph group structure (many parents) I really beg you to not do this… This is officially my third biggest regret in 1.x design ;) I'm still eager to see any good real life use case. And even if you identify one this has significant cost. Having just a tree structure makes the whole model LDAP compatible which is huge gain.</div><div><br></div><div>Additionally when considering group path resolution remember about complex queries. Even simple role resolutions can easily lead into significant number of subqueries. If you add store federation or any additional constraints it gets worse. </div><div><br></div><div><br></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote cite="mid:CA1BC6D8-FEBE-415B-8741-3AC6E570D621@redhat.com" type="cite">
<div><br>
</div>
<div>Bolek. <br>
<div>
<div><br>
<div>
<div>On Oct 15, 2012, at 10:27 AM, Shane Bryzak <<a moz-do-not-send="true" href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I should clarify
something. It is entirely possible for a user to
have a role in a group without being a member of
that group. One of the good use cases that someone
from the team informed me about previously is an
administrator for a group of doctors. The
membership scenario would look like this:<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Bill (User)<br>
GROUP = Doctors<br>
ROLE = Admin<br>
<br>
In this case, Bill (the user) would not be a member
of the Doctors group himself, he would simply be an
administrator for the group. If he were to be a
member of the group (as well as an Administrator)
then that would require the following additional
record:<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Bill (User)<br>
GROUP = Doctors<br>
ROLE = null<br>
<br>
So, in a nutshell - if a Role is specified, it means
the member has that role for the specified group,
however the member is not an actual member of the
group themselves. Hope that makes sense!<br>
<br>
<br>
On 15/10/12 18:19, Shane Bryzak wrote:<br>
</div>
<blockquote cite="mid:507BC72E.8020105@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
No, not that kind. I'm currently reviewing the
database schema for the identity management module -
in the previous version of PicketLink we had quite a
good design [1] that was a little abstract, but met
all the requirements well. Here's a summary of the
key tables:<br>
<br>
IdentityObject - this table would contain both User
and Group records<br>
IdentityObjectRelationship - models the relationship
between User and Group, i.e. Group memberships<br>
IdentityObjectRelationshipName - this table is a
special one that contained the names for "named
relationships". A named relationship can
effectively be thought of as a Role, (and was also
modelled in the IdentityObjectRelationship table)
for example "John" (User) is a "Manager" (Role, the
"named" bit of the relationship) in "Head Office"
(Group) - see [2] for more details.<br>
<br>
With the introduction of application roles we need
to jig this design a little bit. I was thinking of
keeping IdentityObject essentially the same, with
the exception that it would also be used to contain
Roles, as well as Users and Groups. Instead of the
IdentityObjectRelationship table though, I propose
we go with the following slightly less abstract
design:<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER<br>
GROUP<br>
ROLE<br>
<br>
This basically allows us to make any IdentityType
(User, Group or Role) a member of a Group or Role,
or both. Here's a few scenarios:<br>
<br>
1. John is a part of the accounting group.<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = John (User)<br>
GROUP = accounting<br>
ROLE = null<br>
<br>
2. The Manager group is a subgroup of the Employee
group.<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Manager (Group)<br>
GROUP = Employee<br>
ROLE = null<br>
<br>
3. Kevin is an administrator for the Manager group<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Kevin (User)<br>
GROUP = Manager<br>
ROLE = Admin<br>
<br>
4. Kelly is a superuser (which is an application
role)<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Kelly (User)<br>
GROUP = null<br>
ROLE = Superuser<br>
<br>
With the above examples in mind, this now leads into
the "meaningful relationships" theme - can anyone
think of any other meaningful security relationships
that cannot be modelled with this design? I'm not
really looking to make the design "future proof" as
such, but I would like to ensure we cover all
currently known scenarios / use cases. Comments and
feedback welcome of course.<br>
<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true" href="http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model">http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model</a><br>
[2]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true" href="http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342">http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342</a>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
security-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
</pre>
</blockquote>
<br>
<br>
</div>
_______________________________________________<br>
security-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
</div>
</blockquote></div><br></body></html>