[security-dev] Meaningful relationships

Tue Oct 16 15:18:16 EDT 2012

On 17/10/12 03:43, Boleslaw Dawidowicz wrote:
> 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.
>
> The only concern is to keep Group tree and LDAP use case in mind.
>
> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/model/Group.java
>
> 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.

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.

>
> Bolek.
>
> On Oct 15, 2012, at 10:27 AM, Shane Bryzak <sbryzak at redhat.com 
> <mailto:sbryzak at redhat.com>> wrote:
>
>> 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:
>>
>> IdentityMembership
>> -------------------------
>> MEMBER = Bill (User)
>> GROUP = Doctors
>> ROLE = Admin
>>
>> 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:
>>
>> IdentityMembership
>> -------------------------
>> MEMBER = Bill (User)
>> GROUP = Doctors
>> ROLE = null
>>
>> 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!
>>
>>
>> On 15/10/12 18:19, Shane Bryzak wrote:
>>> 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:
>>>
>>> IdentityObject - this table would contain both User and Group records
>>> IdentityObjectRelationship - models the relationship between User 
>>> and Group, i.e. Group memberships
>>> 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.
>>>
>>> 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:
>>>
>>> IdentityMembership
>>> -------------------------
>>> MEMBER
>>> GROUP
>>> ROLE
>>>
>>> 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:
>>>
>>> 1. John is a part of the accounting group.
>>>
>>> IdentityMembership
>>> -------------------------
>>> MEMBER = John (User)
>>> GROUP = accounting
>>> ROLE = null
>>>
>>> 2. The Manager group is a subgroup of the Employee group.
>>>
>>> IdentityMembership
>>> -------------------------
>>> MEMBER = Manager (Group)
>>> GROUP = Employee
>>> ROLE = null
>>>
>>> 3. Kevin is an administrator for the Manager group
>>>
>>> IdentityMembership
>>> -------------------------
>>> MEMBER = Kevin (User)
>>> GROUP = Manager
>>> ROLE = Admin
>>>
>>> 4. Kelly is a superuser (which is an application role)
>>>
>>> IdentityMembership
>>> -------------------------
>>> MEMBER = Kelly (User)
>>> GROUP = null
>>> ROLE = Superuser
>>>
>>> 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.
>>>
>>>
>>> [1] 
>>> http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model
>>> [2] 
>>> http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342 
>>>
>>>
>>>
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org <mailto:security-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/security-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121017/69c206fa/attachment-0001.html 