Jetspeed Proposal: Portal Security 1.4 LAST MODIFIED: $Date$ AUTHOR: taylor@apache.org, paulsp@apache.org 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 ----------------- 2.1 Permissions ----------------- The Turbine Permission class will not be used in the interfaces. Permissions can be checked with the Jetspeed Security API ----------------- 2.2 Access Control ----------------- The Turbine AccessControl class will not be used in the interfaces. Permissions can be checked with the Jetspeed Security API ------------------------------------------------------------------------------------------------------- (3) Specification for Portal Security Implementor ------------------------------------------------------------------------------------------------------- ------------------- 3.1 Security Model ------------------- In sections 3.1.x, the security model objects are described. The security service implementor must support the interfaces and concepts when used in any of the four sets of service interfaces described in section 3.4 ----------- 3.1.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); String getUserId(); } ----------------- 3.1.2 Groups ----------------- Groups are represented as a String. Definition: An abstract logical grouping of Jetspeed users. ----------------- 3.1.3 Roles ----------------- Roles are represented as a String. Definition: An abstract logical grouping of Jetspeed users (yes, this is the same as groups) --------------------------- 3.3 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 exception will be thrown. 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.4 Security Service Interfaces --------------------------------- ------------------------------ 3.4.1 Authentication (Required) ------------------------------ Defines the contract between the portal and security provider required for authentication a Jetspeed User. interface PortalAuthentication { User login( String username, String password ); User login( Principal principal ); User getAnonymousUser(); void logout(); } ----------------------------------------------- 3.4.2 User Management (Optional) ----------------------------------------------- Defines the contract between the portal and security provider required for managing users. interface UserManagement { User getUser( String username ); Iterator getUsers( String filter ); Iterator getUsers(); void saveUser( User user ); void addUser( User user ) ; void removeUser( User user ); } ----------------------------------------------- 3.4.3 Credentials (Optional) ----------------------------------------------- Defines the contract between the portal and security provider required for managing credentials. interface CredentialManagement { void changePassword( String username, String oldPassword, String newPassword ) void forcePassword( String username, String password ); } ------------------------------------ 3.4.4 Authorization (Required) ------------------------------------ interface PortalAccessController { boolean checkPermission(User user, Entry entry, String action); boolean checkPermission(User user, Portlet portlet, String action); boolean checkPermission(User user, String resource, String action); } -------------------------------------------- 3.4.5 Security Entity Maintenance (optional) -------------------------------------------- interface RoleManagement { Iterator getRoles(String username); Iterator getRoles(); void addRole(String role); void removeRole(String role); grantRole(String username, String role); revokeRole(User user, String role); } interface GroupManagement { Iterator getGroups(String username); Iterator getGroups(); void addGroup(String group); void removeGroup(String group); joinGroup(String username, String group); unjoinGroup(String username, String group); } interface SecurityActionManagement { Iterator getActions(); void addAction(String action); void removeAction(String action); } ------------------------------------------------------------------------------------------------------- (4) Deployment -- Jetspeed Security Tags in Registry and PSML ------------------------------------------------------------------------------------------------------- --------------------------------------- 4.1 Jetspeed 1.3 Security Descriptors --------------------------------------- In Jetspeed 1.3, security access to portlets and portlet instances is controlled via the registry and PSML files respectively. In the registry, this was accomplished with a security element and a single role attribute: … In PSML, it is similar yet multiple roles are allowed: manager clerk … -------------------------------------- 4.2 Jetspeed 1.4 Declarative Security -------------------------------------- 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 tags. All entries are allow only. 2. The 'everyone' attribute is dropped 3. The permission tag dropped 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 4. PSML files using the Profile locator format 5. Any arbitrary resource string that the Security service knows about -------------------------------------- 4.2.1 Security Constraints References -------------------------------------- Security Constraints are specifically supported by Jetspeed in two places: 1. The Portlet Registry 2. PSML In both cases, the security tag is defined as: - where parent is a unique identifier, specific to the Security service provider, identifying a security constraint. - the parent attribute is required Example of a Portlet Registry entry: --------------------------------------- ... --------------------------------------- Example of a PSML entry: --------------------------------------- ... --------------------------------------- See the next section on how the referenced constraints are defined in the default implementation. -------------------------------------------------------------- 4.4 The Security Constraint Registry -------------------------------------------------------------- The default Jetspeed security service stores its security constraints in a Jetspeed registry. New security constraints are deployed in to Jetspeed as XREG files. They are standalone, high level registry elements like . Constraints list the valid roles and users for the constraint, and the action for which we are allowing (granting) access on the resource. ----------------------------------------- ---------------------------------------- Attributes 1. name (required) Elements 1. If no element is specified, then everyone is denied access. ----------------------------------------- ----------------------------------------- ----------------------------------------- Attributes 1. action Elements 1. allow-if 2. allow-if-owner If no action attribute is specified, then the rule applies to all actions. If no allow-if element is specified, then access is denied to everyone. ----------------------------------------- ----------------------------------------- ----------------------------------------- Attributes 1. role 2. user 3. group Elements (none) If no attributes are specified, the rule applies to all security types(role, user, group) ----------------------------------------- ----------------------------------------- Attributes (none) Elements (none) ----------------------------------------- ----------------------------------------- Example: ----------------------------------------- ------------------------------------------------------------- The security-entry is implementation specific for the default Jetspeed security. Other security service providers will determine where its constraints are stored. Other security service providers may optionally (for example): 1. Use the Security Registry files for importing into their own store 2. Use the default Security Registry files as the constraints persistence store 3. Use its own policy or other repository 4. Dynamically load and check constraints from the Jetspeed Security Registry These master constraints can be referenced by security constraints in PSML or other registry entries. When implementing your own Jetspeed Security, entry ids can be used with external, centralized policy managers. The name can be used to uniquely reference a security constraint in an external security policy. -------------------------------------- 4.5 Default Behavior of Descriptors -------------------------------------- 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. By default, authentication is not needed to access resources. -------------------------------------------------------------- 5. Jetspeed Configuration -------------------------------------------------------------- Services will be configured in the JetspeedSecurity.properties file as Turbine services. The services are defined in section 3.4 above.