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 ?
It seems to me a pity to have to do 2 hops to get to the right solution instead of one ... :-) 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
