Table of Contents

Do NOT report security vulnerabilities through Bugzilla or mailing lists! Send all security vulnerability reports via email to security@apache.org or to one of the developers.

Security Overview

The Jetspeed Security Services are based on the following component interfaces:

InterfaceDescription
PortalAuthenticationDefines the contract between the portal and security provider required for authentication a Jetspeed User.
PortalAccessControllerDefines the contract between the portal and security provider required for authorized access control for priveleged portal actions.
UserManagementDefines the contract between the portal and security provider required for managing users.
RoleManagementDefines the contract between the portal and security provider required for managing roles.
GroupManagementDefines the contract between the portal and security provider required for managing groups.
PermissionManagementDefines the contract between the portal and security provider required for managing permissions.
CredentialsManagementDefines the contract between the portal and security provider required for managing credentials.

Each of these component interfaces are pluggable. Jetspeed provides one or more default implementations. Most of the default implementations are based on a database security system which emulates the old security object model provided in Jetspeed versions 1.3a3 and before: the Turbine Security model. (The database model is generated from a Torque schema.) However Jetspeed is no longer coupled to the Turbine Security service. The security service works with a set of interfaces to define the standard, base security object model in a portal server. These objects are:

InterfaceDescription
JetspeedUserDefines the minimal attributes of a user in the portal system.
RoleDefines the minimal attributes of a role in the portal system.
GroupDefines the minimal attributes of a group in the portal system.
PermissionDefines the minimal attributes of a permission in the portal system.

The default Jetspeed deployment comes with a populated sample database of users, roles, groups and permissions. This database is conveniently distributed with the webapp to simplify the first time experience. The database is Hypersonic SQL. For production systems, it is recommended to switch to a more robust database.

Security Implementations

The following implementations are provided out of the box:

Default ImplementationDescription
TurbineAuthentication (Default)Uses Torque to authenticate users against the old Turbine database schema.
RegistryAccessController (Default)Uses a Jetspeed Security Registry to define and control access to critical portal resources.
TurbineAccessControllerUses Torque to authorize access against ACLs defined in the old Turbine database schema.
NoSecurityAccessControllerAll authorization access control checks return true, always granting access.
TurbineUserManagement (Default)Manages users with Torque and the old Turbine database schema.
TurbineRoleManagement (Default)Manages roles with Torque and the old Turbine database schema.
TurbineGroupManagement (Default)Manages groups with Torque and the old Turbine database schema.
TurbinePermissionManagement (Default)Manages permissions with Torque and the old Turbine database schema.

The services are pluggable. The configuration is done in the JetspeedSecurity.default:

#########################################
# Authentication Service                #
#########################################

services.PortalAuthentication.classname=org.apache.jetspeed.services.security.turbine.TurbineAuthentication

#########################################
# Authorization Service                 #
#########################################

services.PortalAccessController.classname=org.apache.jetspeed.services.security.registry.RegistryAccessController
#services.PortalAccessController.classname=org.apache.jetspeed.services.security.turbine.TurbineAccessController
#services.PortalAccessController.classname=org.apache.jetspeed.services.security.nosecurity.NoSecurityAccessController

#########################################
# User Management Service               #
#########################################

services.UserManagement.classname=org.apache.jetspeed.services.security.turbine.TurbineUserManagement

#########################################
# Role Management Service               #
#########################################

services.RoleManagement.classname=org.apache.jetspeed.services.security.turbine.TurbineRoleManagement

#########################################
# Group Management Service              #
#########################################

services.GroupManagement.classname=org.apache.jetspeed.services.security.turbine.TurbineGroupManagement

#########################################
# Security Cache Service                #
#########################################

services.SecurityCache.classname=org.apache.jetspeed.services.security.SecurityCacheImpl

Registry Access Control

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

In both cases, the security tag is defined as:

  <security-ref parent='some-security-definition'/>

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:

<portlet-entry type="instance" name="VerySecurePortlet" >
  <security-ref parent='top-secret'/>
</portlet-entry>

Example of PSML, a portlet set and a portlet entry:

    <portlets>
        <security-ref parent="user-only"/>

        <entry parent="HelloSecureWorld">
              <security-ref parent='super-users-only'/>
       </entry>
     </portlets>

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 a portlet-entry. Constraints list the valid roles, groups and users for the constraint, and the action for which we are allowing (granting) access on the resource. The tables below defines the valid attributes and elements of a security entry:

Security Ref Base Attributes
AttributeDescription
nameRequired. The unique name of the security reference.


Security Ref Base Elements
ElementDescription
access0..n access elements may be defined. If no element is specified, then everyone is denied access.


Access Attributes
AttributeDescription
actionDefines the action which we are controlling access to. '*' represents all actions.


Access Elements
ElementDescription
allow-ifDefines which role/group/user will be granted access for the associated action. If not defined, access is denied to everyone for the associated action.
allow-if-ownerDefines the owner granted access for the associated action.


Allow-if Attributes
AttributeDescription
userDefines the security username required for this security constraint.
roleDefines the security role required for this security constraint.
groupDefines the security group required for this security constraint.


The tables below defines default access actions and their corresponding icons (as shown in the TitlePortletControl):

Access Actions
IconActionDescription
N/AviewAllows to select a portlet in customizer and view its contents
customizeAllows to customize a portlet once selected in profile
infoAllows to view any additional information about a portlet
maximizeAllows to view portlet in full screen mode
minimizeAllows to minimize portlet (hide its content) and display its caption only
closeAllows to temporarily close a portlet (hide its caption and content)
printAllows to display current portlet in "print friendly format" (without navigation and portlet control). Note that the default screen template/layout used may be overriden by setting action.print.template property in jr.props to your custom screen template.


Here is some examples:

<registry>
    <security-entry name="admin-only">
        <meta-info>
            <title>Admin-only</title>
            <description>Full access to user with the admin role.</description>
        </meta-info>
        <access action="*">
            <allow-if role="admin"/>
        </access>
    </security-entry>
    <security-entry name="user-only">
        <meta-info>
            <title>User-only</title>
            <description>Full access to users with the user role.</description>
        </meta-info>
        <access action="view">
            <allow-if role="user"/>
        </access>
    </security-entry>

Extending Jetspeed User

Often you may need to extend the Jetspeed User to support extra columns for your own database implementation. Here are the steps to do so:

  • 1. Modify src/torque-schema/security_schema.xml, adding the new columns to the Torque XML schema.
  • 2. Modify project.properties (or your $HOME/build.properties) to generate DDL for your particular database (database=)
  • 3. Rebuild Jetspeed to auto-generate the DDL script for your db, and generate the OM objects The OM objects are generated by default to the org/apache/jetspeed/om/security/turbine package. The destination package is configurable in src/torque-schema/security-schema.xml under the database tag, package attribute. The DDL script is written to target/classes/sql/security-schema.sql.
  • 4. Extend BaseJetspeedUser to, for ex, MyUser, and cast to it whenever you need to access your new columns
  • 5. Modify services.JetspeedSecurity.user.class in JetspeedSecurity.properties to point to your new user class

For an overview of modifying Torque schemas, see: Torque Schemas

Configuring Default Security Constraints

When new portal resources are created, it is possible to automatically assign a default security constraint. The following settings in JetspeedSecurity.properties control this feature (shown here with default values):

services.PortalToolkit.default.user.security.ref = owner-only
services.PortalToolkit.default.anon.security.ref = anon-view_admin-all
services.PortalToolkit.default.role.security.ref =
services.PortalToolkit.default.group.security.ref =

For example, when user creates new pane, the security ref for the pane will be automatically set to "owner-only". When new portlet is added, its security ref will also be set to "owner-only". Also, selecting "-- Default --" will now set the security ref to "owner-only". Please note that default security constraint will be used ONLY if there's no security ref defined at the registry level. Care must be taken with the anonymous profile as "owner-only" is not an appropriate security constraint here. This feature was added in release 1.4b4.

Turbine Access Controller

The Turbine Access Controller is no longer used as the default Access Controller and will be deprecated in a future release. The Turbine Access Controller makes use of the deprecated security tag in portlets and PSML. It does not recognize security-ref tags. Thus if you are going to use the Turbine Access Controller, make sure to put security tags on your portlets and PSML resources to secure your portal resources. The Turbine Access Controller is configured in the JetspeedSecurity.properties by:

services.PortalAccessController.classname=org.apache.jetspeed.services.security.turbine.TurbineAccessController