Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
We already support the concept of roles and permissions. The framework should also support the concept of 'groups' as well, but we need to clearly define what we mean by group.
Although simplified, I define them as the following:
Permission - an atomic representation of ability to perform some action on a given target. A permission has nothing to do with a user - e.g. open a file, access a menu, etc.
Role - a named collection of permissions. A user "gains" permissions implicitly by having roles (which contain permissions).
Group - an tertiary association construct - A group has 1 collection of users and 1 collection of roles. That is, I view a group as a convenience mechanism - a user has the group's roles by implicit association - i.e. a user is in 1 or more groups, and each group has one or more roles, therefore by transitive association, a user has these roles (which in turn have permissions).
The good thing about JSecurity is that, even if other people's definitions of these constructs differ, JSecurity doesn't require the above definitions to be true - that is up to the application. It only provides methods for hasPermission/checkPermission, hasRole/checkRole, and with this task being complete, hasGroup/checkGroup. The underlying Realm implementation actually interprets what those calls mean, so application-specific Realms still have the final say as to what those calls actually do.
Upon adding hasGroup/checkGroup implementations, supporting framework needs to be implemented as well (e.g. tag libs)