deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boleslaw Dawidowicz <>
Subject Re: [DISCUSS] Identity API
Date Mon, 13 Feb 2012 09:47:56 GMT

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
> * 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]
> [2]

View raw message