Essentials Overview Features License Installation FAQ Sample Sites Resources Todo Changes Download Binaries Source Code Supporting Projects Documentation Configuration Guide Javadocs Development Jetspeed Tutorial Portlet Catalog Components Registry Security Syndication WAP Customization Cache PSML Forwards Get Involved Contributors CVS Repository View CVS CVS Branches Coding Spec Bug Database |
Table of Contents
Security Overview Security Implementations Registry Access Control Extending Jetspeed User Configuring Default Security Constraints Turbine Access Controller
Security Overview
> 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.
Security Implementations
> 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
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 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 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
> role | Defines the security role 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)
> | print | 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>
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 build/torque/security_schema.xml, adding the new columns to the Torque XML schema. 2. Modify build/torque/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 to the org/apache/jetspeed/om/security/turbine package. The destination package is configurable in build/torque/build.properties. The DDL script is written to src/sql/security-schema.sql. 4. Extend JetspeedUser to, for ex, MyUser, and cast to it whenever you need to access your new columns 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
Copyright © 1999-2002, Apache Software Foundation