3:27 a.m.
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