@supporting tree-structures: +1 (that was one reason for my comment [1] about the usage of strings.)
@definition of a role: imo it's easier to collect basic use-cases and ideas in a wiki and discuss them step by step (>similar< to [2]). it also provides an overview of the basic decisions and in- and excluded parts. regards, gerhard [1] http://s.apache.org/Myi [2] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking 2012/2/13 Boleslaw Dawidowicz <boleslaw.dawidow...@gmail.com> > > 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 > >
