[security-dev] Meaningful relationships
Shane Bryzak
sbryzak at redhat.com
Mon Oct 15 04:19:58 EDT 2012
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121015/973e10b3/attachment.html
More information about the security-dev
mailing list