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.
The Jetspeed Security Services are based on the following component interfaces:
Interface | Description |
---|---|
PortalAuthentication | Defines the contract between the portal and security provider required for authentication a Jetspeed User. |
PortalAccessController | Defines the contract between the portal and security provider required for authorized access control for priveleged portal actions. |
UserManagement | Defines the contract between the portal and security provider required for managing users. |
RoleManagement | Defines the contract between the portal and security provider required for managing roles. |
GroupManagement | Defines the contract between the portal and security provider required for managing groups. |
PermissionManagement | Defines the contract between the portal and security provider required for managing permissions. |
CredentialsManagement | Defines 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:
Interface | Description |
---|---|
JetspeedUser | Defines the minimal attributes of a user in the portal system. |
Role | Defines the minimal attributes of a role in the portal system. |
Group | Defines the minimal attributes of a group in the portal system. |
Permission | Defines 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.
The following implementations are provided out of the box:
Default Implementation | Description |
---|---|
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. |
TurbineAccessController | Uses Torque to authorize access against ACLs defined in the old Turbine database schema. |
NoSecurityAccessController | All 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
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:
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 | |
Attribute | Description |
---|---|
name | Required. The unique name of the security reference. |
Security Ref Base Elements | |
Element | Description |
---|---|
access | 0..n access elements may be defined. If no element is specified, then everyone is denied access. |
Access Attributes | |
Attribute | Description |
---|---|
action | Defines the action which we are controlling access to. '*' represents all actions. |
Access Elements | |
Element | Description |
---|---|
allow-if | Defines 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-owner | Defines the owner granted access for the associated action. |
Allow-if Attributes | |
Attribute | Description |
---|---|
user | Defines the security username required for this security constraint. |
role | Defines the security role required for this security constraint. |
group | Defines 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 | ||
Icon | Action | Description |
---|---|---|
N/A | view | Allows to select a portlet in customizer and view its contents |
customize | Allows to customize a portlet once selected in profile | |
info | Allows to view any additional information about a portlet | |
maximize | Allows to view portlet in full screen mode | |
minimize | Allows to minimize portlet (hide its content) and display its caption only | |
close | Allows to temporarily close a portlet (hide its caption and content) | |
Allows 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>
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:
For an overview of modifying Torque schemas, see: Torque Schemas
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.
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