David, The security service tries to leverage J2EE security as much as possible. Suggestions to improve the current implementation are more than welcome.
The current security implementation leverage JAAS for authentication (login module) and authorization (policy implementation). Regarding authorization, only J2EE 1.4 clearly addresses authorization through JACC and the management of multiple policies. The current J2 security implementation should be able to plug-in quite well with JACC for those who use a J2EE 1.4 compliant app server. For authentication, the current implementation for instance maps to Tomcat JAASRealm. J2 authorization basically introduces an Rdbms backed policy for managing association between permissions and resources/principal. J2 has portal specific permissions such as PortletPermission, PagePermission, etc. Those permission are mapped to capabilities/actions and principals for authorization. This is all handled through J2's RdmsPolicy. The default file based implementation that most app servers provide as a default policy (prior to J2EE1.4) is not sufficient for J2's authorization needs. Because, J2's authorization scheme is policy based, users can (in theory) freely switch to use an app server policy if available. Authorization checks in J2 are basically Java Security checks. The rest of the security layer is mostly to provide aggregate services for: 1. Managing users where a user is broken into his/her security component and profile attributes. The security component essentially maps a subject (Principals + Credentials) and the profile attribute is back by the Preferences Java API. J2 provides a User interface that provide access to the Subject or the Preferences for that user. 2. Managing roles and groups. The default implementation goes against a relational store. 3. Managing the security mapping and the association between roles, groups and users. 4. Managing permissions or the association of permissions to resources. 5. Additionally, J2 support multiple role hierarchies by aggregation or generalization. A J2 hierarchy resolver maps the proper roles to the subject based on the hierarchy resolution strategy. Through this feature, J2 also supports hierarchical declarative security through the portlet.xml. For instance: <security-role-ref> <description lang="en">This is the admin role</description> <role-name>admin</role-name> <role-link>users.admin</role-link> </security-role-ref> Where the role hierarchy is users/admin. I have found it difficult to find consistency on the 5 points above from various app server which is the reason why we created those services. JS2-114 is aimed at allowing multiple backing stored for user, roles, groups, and mapping. It proposes to use an SPI to provide implementation for the security handler and ideally would provide a bridge between J2 security and the various app servers implementations. I have not been able to find a standard way to do so and am looking forward to your input on this. Basically, we are trying to make it as easy as possible to leverage the app server security model and filling in the gaps where the services are not consistently provided by the app servers. Regards, David Le Strat. --- David Jencks <[EMAIL PROTECTED]> wrote: > This brings to mind something I am very confused > about: > > My understanding is that Jetspeed runs inside a > servlet container or > j2ee application server. These containers are > required to supply > security services. Why does Jetspeed need to > supply any additional > security services rather than relying on those > provided by the > container? > > I understand that the container security service is > not likely to > directly support management of all the user profile > info required by > the portlet spec, but this is a considerably > different area in my mind > from security itself. > > Any comments on this would be most welcome. > > Many thanks, > David Jencks > > > On Sep 4, 2004, at 3:14 PM, > [EMAIL PROTECTED] wrote: > > > Message: > > > > A new issue has been created in JIRA. > > > > > --------------------------------------------------------------------- > > View the issue: > > http://issues.apache.org/jira/browse/JS2-114 > > > > Here is an overview of the issue: > > > --------------------------------------------------------------------- > > Key: JS2-114 > > Summary: Provide a More Modular Security > Implementation > > Type: Improvement > > > > Status: Open > > Priority: Major > > > > Project: Jetspeed 2 > > Components: > > Security > > Fix Fors: > > 2.0-dev/cvs > > Versions: > > 2.0-dev/cvs > > > > Assignee: David Le Strat > > Reporter: David Le Strat > > > > Created: Sat, 4 Sep 2004 3:12 PM > > Updated: Sat, 4 Sep 2004 3:12 PM > > > > Description: > > The current security implementation makes it > difficult to swap the > > default implementation for another implementation. > Based on the > > security requirements, J2 users may want to: > > > > - Persist users in various datastore. This affect > user security as > > well as user attributes. > > - Persist role and group in various datastore. > > - Map to multiple credentials. > > - Change the default security mapping > implementation. > > > > Proposal: > > > > - Provide a more modular security approach based > on handlers for > > principals and credentials. The new security SPI > model will introduce > > and AuthenticationProvider and a SecurityProvider. > The > > AuthenticationProvider is essentially a > utility/bridge class for the > > LoginModule. The SecurityProvider provides access > through an SPI > > model to a UserSecurityHandler, CredentialHandler, > RoleHandler, > > GroupHandler, and SecurityMappingHandler. The > SecurityProvider is > > used by the aggregate services (UserManager, > RoleManager and > > GroupManager) and therefore allow substitution of > the backing store at > > the aggregate level. The default implementation > will essentially > > provide the current implementation behavior but > will facilitate the > > introduction of new backing stores. > > > > - The second step of this rework will address user > attribute and > > provide the support for multiple backing stores as > well. This will > > essentially require the ability to use a specific > Prefs implementation > > backing store. > > > > > > > --------------------------------------------------------------------- > > JIRA INFORMATION: > > This message is automatically generated by JIRA. > > > > If you think it was sent incorrectly contact one > of the administrators: > > > http://issues.apache.org/jira/secure/Administrators.jspa > > > > If you want more information on JIRA, or have a > bug to report see: > > http://www.atlassian.com/software/jira > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
