On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote: > Some particular points to review: > > 1. Should we attempt to use the security classes provided by Java SE, such as > Principal, Subject, etc or use our own User API - this will affect what is > returned by the getUser() method above. Keep in note that we will have at > least a simple User/Role/Group API as part of Identity Management. In Seam 2 > we originally used the built-in Java classes (which made more sense because > the authentication process was based on JAAS), however in Seam 3 (where we > removed JAAS because it doesn't support asynchronous authentication as > required by OpenID etc) we based the security module on the PicketLink User > API. IMHO, this is not a critical choice either way - the Java security > classes have the advantage of being familiar to many users, while on the > flipside if we provide our own User API we have the flexibility of being able > to extend it in the future. So both options have their own advantages. > > 2. The addRole() and addGroup() methods are intended to be only used during > the authentication process to grant particular user memberships for the > duration of their session only. A few users have found this a little > confusing, as they were using identity management, and expected these methods > to grant a permanent membership for the user. One solution may be to simply > rename these methods to addSessionRole() and addSessionGroup() - thoughts?
This implies question if API related to authentication and IDM operations should be de coupled or not - as this would be side effect of relying on Java SEE security classes. > > 3. We're touching a little bit on the authorization API here also with the > hasRole() / inGroup() methods. I'll provide a quick description of these > core security API concepts here: > > * User - represents an individual user of an application. Can either be > human or non-human, and can represent either a user managed locally (i.e. > through the IDM API) or an externally authenticated User, such as one that > has logged in with OpenID. > * Group - a collection of users and other groups. The intent is that > privileges can be either assigned to individual users, groups or roles. > Groups have a hierarchical structure and can be a member of zero or more > other groups. I would personally vote for having clear three structure - so group can belong to zero (under root) or 1 other group (parent). Having flexible hierarchy leads to fairly complex structure. This can easily lead to more cluttered API. From my observations tree structure covers 95% of use cases and many organizations need to integrate with their LDAP which is exactly this kind of shape. > * Role - represent a particular real life role of a user. Roles are defined > as a three-way relationship between user, group and role type. For example, > user "Bob" might be an "accounts clerk" (the role type) at "head office" (the > group). It is also possible for a user to have a role in a group, without > being a member of that group. Does it imply having separate notion of membership between user and group? For me it is the same as "Bob" being "member" (the role type) at "employees" (the group). One thing less to cover in the API which can make it simpler. > > > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-76 > [2] > https://github.com/seam/security/blob/develop/api/src/main/java/org/jboss/seam/security/Identity.java >
