You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Jencks <da...@yahoo.com> on 2004/09/05 00:55:58 UTC
Question about this: [jira] Created: (JS2-114) Provide a More Modular Security Implementation
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, jetspeed-dev@jakarta.apache.org 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Question about this: [jira] Created: (JS2-114) Provide a More Modular Security Implementation
Posted by David Le Strat <dl...@yahoo.com>.
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 <da...@yahoo.com> 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,
> jetspeed-dev@jakarta.apache.org 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:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
>
>
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org