[security-dev] Meaningful relationships

Tue Oct 16 15:44:25 EDT 2012

On 17/10/12 05:18, Shane Bryzak wrote:
> 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.

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.

>
>>
>> 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
>>
>
>
>
>
> _______________________________________________
> security-dev mailing list
> 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/481835da/attachment.html 