deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Sabot-Durand <anto...@sabot-durand.net>
Subject Re: [DISCUSS] Identity API
Date Mon, 13 Feb 2012 15:00:11 GMT
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 <boleslaw.dawidowicz@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
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message