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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________