On Oct 16, 2012, at 9:44 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
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/jav...
>>
>> 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.
+1. I think it is really worth considering. And from experience I think it can be
justifiable to require providing parent during group creation. This means that there would
be no move operation and changing parent group would be not supported in the API - just
remove/add way. I can't recall hearing such requirement to be honest - or at least not
frequent enough to remember. What people were really asking for was to support user and
group renaming - but this should be still achievable with such design.
Hardcoding parent in the schema will give huge perf gain and significantly reduce number
design and implementation issues. Obviously it reduces flexibility however I really
believe it can be justifiable.
>
>>
>> Bolek.
>>
>> On Oct 15, 2012, at 10:27 AM, Shane Bryzak <sbryzak(a)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/Ref...
>>>> [2]
http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/Ref...
>>>>
>>>> _______________________________________________
>>>> security-dev mailing list
>>>> security-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>>>
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/security-dev
>>
>
>
>
>
> _______________________________________________
> security-dev mailing list
> security-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/security-dev