Shouldn't we try to contact JSR 351 EG[1] to brainstorm with them and try to see if our identity management module could implement this spec ?
[1] http://jcp.org/en/jsr/detail?id=351 Antoine SABOT-DURAND Le 13 févr. 2012 à 11:19, Gerhard Petracek a écrit : > @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 <[email protected]> > >> >> 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 >> >>
