[jira] Moved: (KI-20) Group support

["Alan Cabrera (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alan Cabrera moved JSEC-1 to KI-20:
-----------------------------------

    Fix Version/s:     (was: 1.0)
      Component/s:     (was: Specification API)
                       (was: Authorization (access control))
              Key: KI-20  (was: JSEC-1)
          Project: Ki  (was: JSecurity)

> Group support
> -------------
>
>                 Key: KI-20
>                 URL: https://issues.apache.org/jira/browse/KI-20
>             Project: Ki
>          Issue Type: New Feature
>            Reporter: Alan Cabrera
>            Assignee: Les Hazlewood
>
> 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)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.