<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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:<br>
<br>
IdentityObject - this table would contain both User and Group
records<br>
IdentityObjectRelationship - models the relationship between User
and Group, i.e. Group memberships<br>
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.<br>
<br>
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:<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER<br>
GROUP<br>
ROLE<br>
<br>
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:<br>
<br>
1. John is a part of the accounting group.<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = John (User)<br>
GROUP = accounting<br>
ROLE = null<br>
<br>
2. The Manager group is a subgroup of the Employee group.<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Manager (Group)<br>
GROUP = Employee<br>
ROLE = null<br>
<br>
3. Kevin is an administrator for the Manager group<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Kevin (User)<br>
GROUP = Manager<br>
ROLE = Admin<br>
<br>
4. Kelly is a superuser (which is an application role)<br>
<br>
IdentityMembership<br>
-------------------------<br>
MEMBER = Kelly (User)<br>
GROUP = null<br>
ROLE = Superuser<br>
<br>
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.<br>
<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model">http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model</a><br>
[2]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342">http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342</a>
</body>
</html>