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]
