> -----Original Message-----
> From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 23, 2002 1:43 AM
> To: 'Jetspeed Developers List'
> Subject: RE: cvs commit: jakarta-jetspeed/proposals Security.txt
>
>
> Hi David,
>
> It looks very good ! Only one point I don't clearly
> understand is why you don't want to go for JASS right now ...
> Everyone is doing that and most containers have already moved
> to JASS (even if they still support JDK 1.3). I'm not a JAAS
> expert but I think there is no issue to use it with JDK 1.3,
> is there ?
The issue with 1.3 is the dependency on an external package.
I stated in the proposal:
<from security proposal>
An original goal was to base this service on the Java Security
Architecture and JAAS standards.
We have since decided to scale back this proposal and to implement a
simple security service that is
not tied to any optional Java packages. JAAS is only a part of the JDK
starting with version 1.4.
In the spirit of Jetspeed's easy installation and deployment, a security
system with minimal configuration
is the best starting point for a default implementation.
After the default implementation is completed, we hope to soon have
interest in creating both LDAP and JAAS solutions.
</from security proposal>
Also, JAAS requires configuration outside of the Jetspeed web
application, which further complicates Jetspeed's deployment for novice
users.
Keeping in mind the Jetspeed user base, simplicity of deployment is an
important issue.
>
> It seems to me a pity to have to do 2 hops to get to the
> right solution instead of one ... :-)
Hopefully the hop will be a short one :-)
I think that we are doing the right solution, maybe not for you the
first time, but we do have to try to meet the needs of the entire user
base.
David
>
> But obviously I don't know Jetspeed well enough to know the
> ins and out of this decision and I trust your judgement. I'm
> just curious I guess ...
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 23 May 2002 07:40
> > To: [EMAIL PROTECTED]
> > Subject: cvs commit: jakarta-jetspeed/proposals Security.txt
> >
> > taylor 02/05/22 23:40:13
> >
> > Added: proposals Security.txt
> > Log:
> > YASP! Yet another security proposal.
> >
> > Reviewed by Busby. http://www.bluesunrise.com/busby.inc/Certified-
> > Busby.JPG
> >
> > Revision Changes Path
> > 1.1 jakarta-jetspeed/proposals/Security.txt
> >
> > Index: Security.txt
> >
> ===================================================================
> > Jetspeed Proposal: Portal Security 1.4
> > LAST MODIFIED: $Date: 2002/05/23 06:40:13 $
> > AUTHOR: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > STATUS:
> >
> > =============================
> > Jetspeed Portal Security 1.4
> > =============================
> >
> > This document is a proposal for a new Jetspeed Security
> Service for
> > Jetspeed 1.4,
> > replacing Jetspeed's current security service, along with the
> Turbine
> > Security Service (which is extended by the
> > Jetspeed Security Service)
> >
> > The goal of this proposal is to:
> >
> > 1. Describe general requirements of Portal Security for Jakarta
> > Jetspeed.
> > 2. Replace Turbine Security with a more pluggable Security System
> for
> > portals
> > - Separate the authentication and authorization interfaces.
> > - Make it easy for Jetspeed to swap out security backends and
> > to facilitate integrating to other security implementations
> > - With specific intent to support JAAS and LDAP
> implementations
> > - Facilitate the extension and customization of the
> basic User
> > model
> > 3. Specification for new Security interfaces
> > 4. Specification for Jetspeed Security Deployment Descriptors
> > 5. Specification for Default Implementation.
> >
> > An original goal was to base this service on the Java Security
> > Architecture and JAAS standards.
> > We have since decided to scale back this proposal and to
> implement a
> > simple security service that is
> > not tied to any optional Java packages. JAAS is only a part of the
> JDK
> > starting with version 1.4.
> > In the spirit of Jetspeed's easy installation and deployment, a
> security
> > system with minimal configuration
> > is the best starting point for a default implementation.
> >
> > After the default implementation is completed, we hope to
> soon have
> > interest in creating both LDAP and JAAS solutions.
> >
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> > (1) Requirements for Portal Security
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> >
> > A web application contains resources that can be accessed by many
> users.
> > The general security requirements of a web application are: (from
> the
> > servlet specification):
> >
> > o Authentication:
> >
> > The means by which communicating entities prove to one
> another that
> they
> > are acting on behalf of specific identities that are
> > authorized for access.
> >
> > o Access control for resources:
> >
> > The means by which interactions with resources are limited to
> > collections of users or programs for the purpose of
> > enforcing integrity, confidentiality, or availability constraints.
> >
> > o Confidentiality or Data Privacy:
> >
> > The means used to ensure that information is made
> available only to
> > users who are authorized to access it.
> >
> > In addition to the standard web application security
> requirements,
> > portals may often have unique security requirements:
> >
> > � A single point of sign-on and authentication.
> > � Separation of authentication service from
> authorization service.
> > � A standardized security model in order to enable
> interchangeable
> > security constraints shared amongst diverse portlets.
> > � Portal-specific declarative security
> > � A more refined Permission model to provide
> fine-grained control
> to
> > specific portal entities (portlets, portlet instances)
> >
> > Jetspeed obviously has a lot in common with the security model of
> web
> > applications.
> > There are users and roles (principals) like in a
> servlet-based web
> > application.
> > Whereas a web application will define permissions to
> resources and
> > files, a portal system must also define permissions to Portlet
> resources.
> >
> >
> --------------------------------------------------------------
> ----------
> > ---------
> > 1.2 Declarative Security and Deploying Security Constraints to a
> > Jetspeed Webapp
> >
> --------------------------------------------------------------
> ----------
> > ----------
> >
> > Jetspeed's architecture is designed as a Web Application-based
> Portal
> > server.
> >
> > The current version of Jetspeed does not have a
> standardized method
> of
> > importing portlet applications.
> > In order to import an application, one must package
> registry files,
> > class and jar files, PSML and templates so
> > that they match the Jetspeed web application format. In
> the registry
> and
> > PSML files, security may be defined
> > declaratively in a non-standard format. For Jetspeed 1.3, the
> registry
> > is like a deployment descriptor and the
> > current Jetspeed Security service, based on Turbine
> Security model,
> is
> > the programmatic interface to security.
> >
> > In this proposal, we will continue to use this deployment
> model. For
> the
> > default implementation,
> > declarative security will go in the registry and PSML files.
> However,
> > this is not a requirement for all
> > implementations. The API defined here will (hopefully) enable
> Security
> > service developers to define their own
> > security constraints which are possibly external from the
> Jetspeed
> > resources.
> >
> >
> --------------------------------------------------------------
> ----------
> > ---------
> > 1.3 Programmatic Security
> >
> --------------------------------------------------------------
> ----------
> > ----------
> >
> > Jetspeed 1.3 also supports programmatic security, based on the
> Turbine
> > Security Model.
> > This document proposes the replacement of the Turbine Security
> Model.
> >
> > The replacement will be based upon a refactoring of the interfaces
> along
> > the lines of:
> >
> > 1. Authentication
> > 2. Credentials and User Management
> > 3. Authorization
> > 4. Security Entity Maintenance
> >
> > See section 3 below for details
> >
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> > (2) Turbine Security
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> >
> > The current Jetspeed Security System is based on Turbine
> 2 Security
> > Model.
> > Turbine 2 is tightly coupled to its security model, and it is
> difficult
> > to replace Turbine Security and its backend
> > datastore with a different security backend. The proposed solution
> will
> > facilitate the integration of pluggable security backends
> > without being tied to the Turbine 2 Security Model.
> >
> > Turbine Security provides for a basic object model for a web
> > application. This model consists of:
> >
> > � Users
> > � Roles
> > � Groups
> > � Permissions
> > � Access Controls
> >
> > Turbine also provides a security service:
> > org.apache.turbine.services.security.TurbineSecurity for
> authentication,
> > authorization,
> > and general security maintenance (user, role, ACL management).
> >
> > Jetspeed's current security service extends it:
> > org.apache.jetspeed.services.JetspeedSecurity
> >
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> > (3) Specification for Portal Security
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> >
> > --------
> > 3.1 User
> > ---------
> > The org.apache.turbine.om.security.User interface will be
> difficult
> to
> > replace, since it is used
> > throughout Turbine, and Jetspeed is still highly dependent on
> Turbine.
> > For example, the User interface is coupled
> > to RunData interface, which is ubiquitous both in Turbine and
> Jetspeed.
> > For these reasons, its
> > required that all Jetspeed 1.4 security implementation must
> implement
> > the User interface. The User interface
> > will be the mimimal interface which can be extended. The Turbine
> team
> > purposely defined a User interface with
> > minimal requirements for a web application that should
> fit the needs
> of
> > all security implementations.
> >
> > The default interface will be JetspeedUser, which extends User.
> >
> > interface JetspeedUser extends User
> > {
> > boolean getDisabled();
> >
> > void setDisabled(boolean disabled);
> > }
> >
> >
> > -----------------
> > 3.2 Permissions
> > -----------------
> > The Turbine Permission class will not be used in the interfaces.
> > Permissions can be checked with the Jetspeed Security API
> >
> > -----------------
> > 3.3 Access Control
> > -----------------
> > The Turbine AccessControl class will not be used in the
> interfaces.
> > Permissions can be checked with the Jetspeed Security API
> >
> > -----------------
> > 3.4 Groups
> > -----------------
> > Groups, as a security element, will be dropped from Jetspeed 1.4
> > Groups are only valid in a profile locator in the default
> Jetspeed
> > profiler.
> > In order to provide security to a group profile, simply place a
> security
> > constraint on the root portlet set of that resource.
> >
> > As a security element, it would be useful to have groups of users
> that
> > can be assigned roles.
> > This feature is tabled for a future rev.
> >
> > -----------------
> > 3.5 Roles
> > -----------------
> >
> > Same as Turbine's, different om package.
> >
> > ---------------------------
> > 3.6 Conformancy
> > ---------------------------
> >
> > The security interfaces are grouped by:
> >
> > 1. Authentication
> > 2. Credentials and User Management
> > 3. Authorization
> > 4. Security Entity Maintenance
> >
> > The security service implementation can be conformant on two
> levels:
> >
> > 1. Level One Conformant - implements required interfaces
> > 2. Level Two Conformant - implements all interfaces
> >
> > A Level One Conformant service provide implements the required
> > interfaces:
> >
> > � Authentication
> > � Authorization
> >
> > A Level Two Conformant service provide implements the required
> > interfaces:
> >
> > � Credentials and User Management
> > � Security Entity Maintenance
> >
> > If your service does not provide a requested method, a <TBD>
> exception
> > will be thrown.
> >
> >
> > -----------------------------------------
> > 3.6 The Default Implementation
> > ------------------------------------------
> > The default implementation will conform to all levels.
> >
> > If you have an authentication server, and only want to
> implement the
> > authentication interfaces with your server, you can
> > extend the default implementation and override the authorization
> > interfaces.
> > Likewise, delegating to the default implementation where necessary
> is
> > allowed, and disabling of the default implementation for
> > any optional interfaces. Required interfaces may not be disabled.
> >
> >
> > ---------------------------
> > 3.8 Authentication (Required)
> > ---------------------------
> >
> > interface PortalAuthentication
> > {
> > login( String username, String password );
> > login( Principal principal );
> > boolean accountExists( String username );
> > }
> >
> > ------------------------------------
> > 3.9 Credentials and User Management (Optional)
> > ------------------------------------
> >
> > interface UserManagement
> > {
> > User getUser( String username );
> >
> > Iterator getUsers( Criteria criteria );
> >
> > User getAnonymousUser();
> >
> > void saveUser( User requestor, JetspeedUser user );
> >
> > void addUser( User requestor, User user ) ;
> >
> > void removeUser( User requestor, User user );
> >
> > grantRole(User requestor, User user, Role role);
> >
> > revokeRole(User requestor, User user, Role role);
> > }
> >
> > interface CredentialManagement
> > {
> > void changePassword( User requestor,
> > User user,
> > String oldPassword,
> > String newPassword )
> >
> > void forcePassword( User requestor, User user, String password
> );
> >
> > }
> >
> > ------------------------------------
> > 3.10 Authorization (Required)
> > ------------------------------------
> >
> > interface PortalAccessController
> > {
> > boolean checkPermission(User user, Entry entry,
> String action);
> > boolean checkPermission(User user, Portlet portlet, String
> action);
> > }
> >
> > ------------------------------------
> > 3.11 Security Entity Maintenance (optional)
> > ------------------------------------
> >
> > interface RoleManagement
> > {
> > Role getRole( User user, String name );
> > Iterator getRoles( User user );
> > Iterator getRoles();
> > void saveRole(User requestor, Role role );
> > Role addRole(User requestor, Role role );
> > void removeRole(User requestor, Role role );
> > }
> >
> > interface SecurityActionManagement
> > {
> > SecurityAction getSecurityAction( User user, String name );
> > Iterator getSecurityActions( User user );
> > Iterator getSecurityActions();
> > void saveSecurityAction(User requestor,
> SecurityAction action );
> > SecurityAction addSecurityAction(User requestor,
> SecurityAction
> > actoin );
> > void removeSecurityAction(User requestor,
> SecurityAction action
> );
> > }
> >
> > // In the default implementation constraints are stored in the
> security
> > registry
> >
> > interface SecurityConstraintManager
> > {
> > SecurityConstraint getSecurityConstraint( User user,
> String name
> );
> > Iterator getSecurityConstraints( User user );
> > Iterator getSecurityConstraints();
> > void saveSecurityConstraint(User requestor,
> SecurityConstraint
> > constraint);
> > SecurityConstraint addSecurityConstraint(User requestor,
> > SecurityConstraint constraint );
> > void removeSecurityConstraint(User requestor,
> SecurityConstraint
> > constraint );
> >
> > }
> >
> >
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> > (4) Deployment -- Security Tags in Registry and PSML
> >
> --------------------------------------------------------------
> ----------
> > -------------------------------
> >
> > In Jetspeed 1.3, security access to portlets and
> portlet instances
> is
> > controlled via the registry and
> > PSML files respectively. In the registry, this is
> accomplished with
> a
> > security element and a single role
> > attribute:
> >
> > <portlet-entry �>
> > <security role="clerk"/>
> > �
> >
> >
> > In PSML, it is similar yet multiple rows are allowed:
> >
> >
> > <entry �>
> > <security>
> > <role>manager</role>
> > <role>clerk</role>
> > �
> >
> >
> > This proposal deprecates the old format, and proposes a new format
> based
> > on the security descriptor format
> > proposed a while back by Marcus Schwarz of SAP in
> Proposal 0004.txt.
> > However some differences:
> >
> > 1. There will be no <allow> or <deny> tags. All entries
> explicitly
> > mean allow.
> > 2. The 'access' tag renamed to 'action'.
> > 3. The everyone attribute is dropped
> > 4. The permission tag dropped
> >
> > -------------------------------
> > 4.1 Authorization Constraints
> > -------------------------------
> >
> > An authorization constraint is defined as a security element in
> either a
> > PSML element or in a Registry.
> > Constraints are applied to Portlet Resources. The types
> of resources
> > that may have security constraints are:
> >
> > 1. Portlet entries in the Registry
> > 2. Portlet entries in PSML
> > 3. Portlet sets in PSML
> >
> > Since the top level portlet set in a PSML 'file' is
> required, access
> to
> > a PSML file can be controlled
> > by entering a security check on the top level portlet set in the
> PSML
> > file.
> >
> > Authorization constraints are role-based. If the current subject
> doesn't
> > have the allowed role,
> > the user must be denied access. If the authorization constraint
> defines
> > no roles, no user is allowed access
> > to the resource defined by the security constraint.
> >
> > --------------------------------------
> > 4.2 The Security Constraint Registry
> > --------------------------------------
> >
> > Security constraints can be deployed in a XREG files as common
> > constraints.
> > They are standalone, high level registry elements like
> <portlet-entry>.
> > They list the valid roles for the constraint, and the action for
> which
> > we are allowing (granting) access
> > on the resource.
> >
> > <security-entry id='23923'>
> > <role>manager</role>
> > <role>clerk</role>
> > <user>john</user>
> > <action>view</action>
> > <action>edit</action>
> > <!-- Only managers and clerks can view or edit. No one can
> > customize,... -->
> > </security-entry>
> >
> > The security-entry is implementation specific for the default
> Jetspeed
> > security.
> > These entries may be stored by other implementations in policy
> > repository for example.
> >
> > These master constraints can be referenced by security constraints
> in
> > PSML or other registry entries. For example:
> >
> >
> > <portlet-entry>
> > ...
> > <security-ref parent='23923'/>
> > </portlet-entry>
> >
> >
> >
> > When implementing your own Jetspeed Security, entry ids
> can be used
> with
> > external, centralized policy managers.
> > The id can be used to uniquely reference a security
> constraint in an
> > external security policy.
> >
> > -----------------------------------------
> >
> > <security-entry> - Attributes
> >
> > 1. id (required)
> >
> > <security-entry> - Elements
> >
> > 1. <role>name</role>
> > 2. <user>user</user>
> > 3. <action>name</action>
> >
> > -----------------------------------------
> >
> > <security-ref> - Attributes
> >
> > 1. parent (required)
> >
> > <security-ref> - Elements
> >
> > None
> >
> >
> >
> > --------------------------------------
> > 4.3 Default Behavior
> > --------------------------------------
> >
> > It may not be clear what happens when no security descriptor is
> > supplied.
> > In this case, like the Servlet 2.3 specification, the lack of a
> security
> > descriptor implies granting access
> > to everyone, and that no permission checks will be executed.
> >
> > To state it clearly:
> >
> > By default, authentication is not needed to access resources.
> >
> > To summarize: if you do not specify a security descriptor, by
> default,
> > everyone is granted access.
> > If you specify a security descriptor without any
> roles(principals),
> > everyone is denied.
> >
> > --------------------------------------
> > 4.4 Uniqueness of entries
> > --------------------------------------
> >
> > In order for all entries to be uniquely identifiable in the portal
> by
> > the Security Manager, security ids must be unique
> > to the security system implementation.
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:jetspeed-dev-
> > [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:jetspeed-dev-
> > [EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:jetspeed-dev-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
