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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
