<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 17/10/12 05:18, Shane Bryzak wrote:<br>
</div>
<blockquote cite="mid:507DB2F8.7090703@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
</blockquote>
<br>
Actually after thinking about this I believe it would be
problematic. So unless someone has strong objections, I propose we
make it a restriction across the board that a Group may only have
one parent group. In fact, I'm toying with the idea of actually
hard-coding the parent group as part of the IdentityObject schema,
rather than model it through the IdentityMembership table. <br>
<br>
<blockquote cite="mid:507DB2F8.7090703@redhat.com" type="cite"> <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 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><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
security-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a 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>
</body>
</html>