Security Service

  • UserManager should become a service in it's own right.
  • ACL mechanism should become pluggable. A new interface ACLBuilder must be defined, the interface would have single method of 'Object buildACL(User)' signature. UserManagerService would have a property that would contain *service name* that implements ACLBuilder. buildACL will be an instance not class method, so a concrete instance of the service must be consulted.
  • User object will have method of 'Object getACL()' signature that will delegate to UserManagerService, which in turn delegates to the configured ACLBuilder. It's OK to cache the returned object, since the ACLBuilder will keep references ACL objects internally, to reflect the changes of sercurity information at runtime. (rafal)
  • TurbineSecurityService will be the default ACLBuilder shipped with the system.
  • TurbineSecurityService should have it's OM/Peer classes Torque generated.
  • Group should be could be renamed to 'Realm' or 'Domain'. This should decrease the confusion about it's meaning.
  • Attributes of Roles/Groups/Permissions will be dropped. I don't think the idea catched on.
  • User attributes should be moved into a separate table, or even two tables if we want to store meta information for user attributes. This will require a customized Peer class for User objects, but this will be easy with recent Torque's two-level class generation
  • On session unbind event, only acces counters/timestamps should be updated not the whole data. This should fix the overriding of admin's changes by the unbound session problems. The information which attributes should be updated could be placed in user attribute meta-information table.
  • All references to peers have to be removed from the interfaces. Anything peer specific must be pushed down into DBSecurityService.
  • Allow multiple security service implementations to be run in tandem. This would allow a portion of a site to be controlled by an LDAP security service and another portion to be controlled by DB security services. More info about this is explained in the Policy Service proposal.
  • All the security code has to be grouped together. Right now it's all over the place and rather confusing. The util code should be moved into the security services package, and the om/peer code for the DBSecurityService should be move into the package with the rest of the DBSecurityService code. Here's what I would propose for the new layout. This would require the deprecation of the location of a lot of the classes but I think it would help a lot with the ease of understanding.
.
|-- BaseSecurityService.java
|-- SecurityService.java
|-- TurbineSecurity.java
|-- UserManager.java
|-- entity
|   |-- Group.java
|   |-- Permission.java
|   |-- Role.java
|   |-- SecurityEntity.java
|   `-- User.java
|-- impl
|   |-- db
|   |   |-- DBSecurityService.java
|   |   |-- DBUserManager.java
|   |   `-- entity
|   |       |-- GroupPeer.java
|   |       |-- PermissionPeer.java
|   |       |-- RolePeer.java
|   |       |-- RolePermissionPeer.java
|   |       |-- SecurityObject.java
|   |       |-- TurbineGroup.java
|   |       |-- TurbinePermission.java
|   |       |-- TurbineRole.java
|   |       |-- TurbineUser.java
|   |       |-- TurbineUserPeer.java
|   |       |-- UserGroupRolePeer.java
|   |       `-- UserPeer.java
|   |-- ldap
|   |   |-- LDAPSecurityConstants.java
|   |   |-- LDAPSecurityService.java
|   |   |-- LDAPUser.java
|   |   |-- LDAPUserManager.java
|   |   `-- util
|   |       `-- ParseExceptionMessage.java
|   `-- passive
|       `-- PassiveUserManager.java
`-- util
    |-- AccessControlException.java
    |-- AccessControlList.java
    |-- DataBackendException.java
    |-- EntityExistsException.java
    |-- GroupSet.java
    |-- PasswordMismatchException.java
    |-- PermissionSet.java
    |-- RoleSet.java
    |-- TurbineSecurityException.java
    `-- UnknownEntityException.java