Security Deployment Configuration

This section of the guide provides deployers with several quick deployment configuration options for Jetspeed Security.

Authorization: Permissions vs Constraints

Jetspeed supports two different kinds of authorization policies:

  1. Permissions - use a standard Java Security Policy. Jetspeed stores this policy in a relational database
  2. Constraints - Jetspeed specific Constraint-based Security

By default, Jetspeed uses constraints as shown in the service configuration for the Security Access Controller bean shown below, from the Spring configuration file administration.xml. Constraints are usually defined on the resource itself in the Jetspeed site, such as on pages or folders. See the Constraints guide as well as the for more information on constraints-based security.

Java Security policies are a little more advanced. See the JAAS Security Policy Guide for more information on configuring Jetspeed's JAAS Security Policy in a relational database

    	
<bean id="org.apache.jetspeed.security.SecurityAccessController"
      class='org.apache.jetspeed.security.impl.SecurityAccessControllerImpl'>
    	<constructor-arg index='0'>
    		<ref bean="org.apache.jetspeed.page.PageManager"/> 
    	</constructor-arg>
    	<!--
    	   Security Mode:
    	      1 = Permissions = use Jetspeed Java Security Policy
    	      2 = Constraints = use Jetspeed (PageManager) Constraint-based Security  
    	 -->
    	 <constructor-arg index="1">
            <value>2</value>
        </constructor-arg>
</bean>

Login and Authorization Options

Jetspeed provides some general Login and Authorization options to help you customize the behavior of your portal. The service configuration for the Portal Authentication Configuration bean shown below, from the Spring configuration file administration.xml is used to customize two key behaviors of the portal.

  1. Create New Sessions upon Login - When a user authentications (logs in) with one of the Jetspeed login portlets, by default, a new session is not created. The session of the guest user is carried over to the authenticated user. If you want to change this behavior to create a new session, set this value to true. The reason this setting is false, is to simulate a online store, where you buy things and then login at the end.
  2. Hard Session Timeouts - For configurations where you need to set the hard session timeout limit in seconds, regardless of (in)activity. Setting to 0 turns off this feature. Note:this feature should be used with 'create new session upon authentication' feature

    	

<bean id='org.apache.jetspeed.administration.PortalAuthenticationConfiguration'
	class='org.apache.jetspeed.administration.PortalAuthenticationConfigurationImpl'>

   <!--  create new session upon authentication -->   
   <constructor-arg index='0'>
   		<value>false</value>
   </constructor-arg>	
   <!--  hard session timeout limit in seconds, regardless of (in)activity, setting to 0 turns off this feature 
   		 note:this feature should be used with 'create new session upon authentication' feature 
   -->   
   <constructor-arg index='1'>
   		<value>0</value>
   </constructor-arg>
   <!--  redirect location for hard session expiration -->   
   <constructor-arg index='2'>
   		<value>/login/logout</value>
   </constructor-arg>
</bean>

Jetspeed Security Spring Configuration

The files that are involved when configuring Jetspeed security are located under ${jetspeed-source-home}/portal/src/webapp/WEB-INF/assembly/. This section introduces you to these deployment descriptor files. In normal usage, you will not need to modify these files. This documentation is provided for advanced usage of Jetpeed security such as replacing the default Security implementations with your own.

security-atn.xml

This configuration file provides the login module configuration. Not everyone needs this, as some application may decide to use another login module other than the one provided.

security-atz.xml

This configuration file configures the authorization policy, in J2's case RdbmsPolicy .

security-managers.xml

This configuration file configures all the managers for security purpose.

security-providers.xml

This configuration file configures the various providers and weaves the SPI together.

  • AuthenticationProviderProxy : Configures the list of AuthenticationProvider and the default authenticator. 
                                
<bean id="org.apache.jetspeed.security.AuthenticationProviderProxy" 
   class="org.apache.jetspeed.security.impl.AuthenticationProviderProxyImpl">  	   
   <constructor-arg >
      <list>
         <ref bean="org.apache.jetspeed.security.AuthenticationProvider"/>
      </list>
   </constructor-arg>
  <constructor-arg><value>DefaultAuthenticator</value></constructor-arg>
</bean>
  • AuthenticationProvider : Configures the authentication providers for the current portal implementation. The example below configures the default authenticator that uses the RDBMS to manage/store user information. 
                                
<bean id="org.apache.jetspeed.security.AuthenticationProvider" 
  	   class="org.apache.jetspeed.security.impl.AuthenticationProviderImpl">  	   
   <constructor-arg index="0"><value>DefaultAuthenticator</value></constructor-arg>
   <constructor-arg index="1"><value>The default authenticator</value></constructor-arg>
   <constructor-arg index="2"><value>login.conf</value></constructor-arg>
   <constructor-arg index="3">
      <ref bean="org.apache.jetspeed.security.spi.CredentialHandler"/>
   </constructor-arg>
   <constructor-arg index="4">
      <ref bean="org.apache.jetspeed.security.spi.UserSecurityHandler"/>
   </constructor-arg>
</bean>
  • AuthorizationProvider : Configures the policies and instantiates the SecurityPolicies that are used for enforcing permissions. By default, Jetspeed 2 does not load any other security policies that may have been configured. In order to use default policies, set useDefaultPolicy to true
                                
<bean id="org.apache.jetspeed.security.AuthorizationProvider" 
  	  class="org.apache.jetspeed.security.impl.AuthorizationProviderImpl">  	   
    <constructor-arg index="0">
        <ref bean="org.apache.jetspeed.security.impl.RdbmsPolicy"/>
    </constructor-arg>
    <!-- Does not use the default policy as a default behavior -->
    <constructor-arg index="1"><value>false</value></constructor-arg>   
</bean>

security-spi.xml

This configuration file contains configuration that are common to the authentication and authorization SPIs.

Bean Description
org.apache.jetspeed.security.spi.SecurityAccess Used internally by the default OJB based SPI. Provide access to common action/methods for the various SPI implementations. The SecurityAccess bean is used by both the Authentication and Authorization SPIs.

security-spi-atn.xml

This configuration file contains all the configurations for configuring the authentication SPI.

Bean Description
org.apache.jetspeed.security.spi.CredentialHandler The CredentialHandler encapsulates the operations involving manipulation of credentials. The default implementation provides support for password protection as defined by the PasswordCredentialProvider ; as well as lifecycle management of credentials through InternalPasswordCredentialInterceptor which can be configured to manages parameters such as maximum number of authentication failures, maximum life span of a credential in days and how much history to retain for a given credential.
org.apache.jetspeed.security.spi.UserSecurityHandler The UserSecurityHandler encapuslated all the operations around the user principals.

The following simple CredentialHandler configuration is currently provided by default with Jetspeed:

<!-- require a non-empty password -->
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordValidator" 
     class="org.apache.jetspeed.security.spi.impl.DefaultCredentialPasswordValidator"/>

<!-- MessageDigest encode passwords using SHA-1 -->
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordEncoder" 
     class="org.apache.jetspeed.security.spi.impl.MessageDigestCredentialPasswordEncoder">
     <constructor-arg index="0"><value>SHA-1</value></constructor-arg>       
</bean>       

<!-- allow multiple InternalPasswordCredentialInterceptors to be used for DefaultCredentialHandler --> 
<bean id="org.apache.jetspeed.security.spi.InternalPasswordCredentialInterceptor"
     class="org.apache.jetspeed.security.spi.impl.InternalPasswordCredentialInterceptorsProxy">
     <constructor-arg index="0">
       <list>
         <!-- enforce an invalid preset password value in the persisent store is required to be changed -->
         <bean class="org.apache.jetspeed.security.spi.impl.ValidatePasswordOnLoadInterceptor"/>

         <!-- ensure preset cleartext passwords in the persistent store  will be encoded on first use -->
         <bean class="org.apache.jetspeed.security.spi.impl.EncodePasswordOnFirstLoadInterceptor"/>
       </list>
     </constructor-arg>
</bean>

<bean id="org.apache.jetspeed.security.spi.PasswordCredentialProvider" 
     class="org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialProvider">
     <constructor-arg index="0">
       <ref bean="org.apache.jetspeed.security.spi.CredentialPasswordValidator"/>
     </constructor-arg>       
     <constructor-arg index="1">
       <ref bean="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"/>
     </constructor-arg>       
</bean>       

<bean id="org.apache.jetspeed.security.spi.CredentialHandler" 
     class="org.apache.jetspeed.security.spi.impl.DefaultCredentialHandler">       
     <constructor-arg index="0">
       <ref bean="org.apache.jetspeed.security.spi.SecurityAccess"/>
     </constructor-arg>       
     <constructor-arg index="1">
       <ref bean="org.apache.jetspeed.security.spi.PasswordCredentialProvider"/>
     </constructor-arg>       
     <constructor-arg index="2">
       <ref bean="org.apache.jetspeed.security.spi.InternalPasswordCredentialInterceptor"/>
     </constructor-arg>
</bean>

The above configuration requires not much more than that a password should not be empty and MessageDigest encode it using SHA-1.

Before the 2.0-M4 release, Jetspeed came configured with a much stricter configuration, but for first time users of the Portal this was a bit overwelming and also quite difficult to configure differently.

With the 2.0-M4 release, the previously provided, and rather complex, InternalPasswordCredentialInterceptor implementations are split up in single atomic interceptors which can much easier be configured indepedently.

An overview of the new interceptors and how related request processing pipeline valves can be configured to provide feedback to the user is provided in the Credentials Management document.

Since the "old" (pre 2.0-M4) interceptors are no longer provided with Jetspeed, the example below shows how to "restore" the old setup using the new interceptors:

<!-- require a password of minimum length 6 and at least two numeric characters -->
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordValidator" 
     class="org.apache.jetspeed.security.spi.impl.SimpleCredentialPasswordValidator">
     <constructor-arg index="0"><value>6</value></constructor-arg>       
     <constructor-arg index="1"><value>2</value></constructor-arg>       
</bean>

<!-- allow multiple InternalPasswordCredentialInterceptors to be used for DefaultCredentialHandler --> 
<bean id="org.apache.jetspeed.security.spi.InternalPasswordCredentialInterceptor"
     class="org.apache.jetspeed.security.spi.impl.InternalPasswordCredentialInterceptorsProxy">
     <constructor-arg index="0">
       <list>
         <!-- enforce an invalid preset password value in the persisent store is required to be changed -->
         <bean class="org.apache.jetspeed.security.spi.impl.ValidatePasswordOnLoadInterceptor"/>

         <!-- ensure preset cleartext passwords in the persistent store  will be encoded on first use -->
         <bean class="org.apache.jetspeed.security.spi.impl.EncodePasswordOnFirstLoadInterceptor"/>

         <!-- remember the last 3 passwords used and require a new password to be different from those -->
         <bean class="org.apache.jetspeed.security.spi.impl.PasswordHistoryInterceptor">
           <constructor-arg index="0"><value>3</value></constructor-arg>       
         </bean>

         <!-- Automatically expire a password after 60 days -->
         <bean class="org.apache.jetspeed.security.spi.impl.PasswordExpirationInterceptor">
           <constructor-arg index="0"><value>60</value></constructor-arg>       
         </bean>

         <!-- Automatically disable a password after 3 invalid authentication attempts in a row --> 
         <bean class="org.apache.jetspeed.security.spi.impl.MaxPasswordAuthenticationFailuresInterceptor">
           <constructor-arg index="0"><value>3</value></constructor-arg>       
         </bean>
       </list>
     </constructor-arg>
</bean>

And, make sure something like the following configuration is set for the security related valves in pipelines.xml:

<bean id="passwordCredentialValve"
      class="org.apache.jetspeed.security.impl.PasswordCredentialValveImpl"
      init-method="initialize">
 <constructor-arg>
   <!-- expirationWarningDays -->
   <list>
     <value>2</value>
     <value>3</value>
     <value>7</value>
   </list>
 </constructor-arg>
</bean> 

<bean id="loginValidationValve"
      class="org.apache.jetspeed.security.impl.LoginValidationValveImpl"
      init-method="initialize">
  <!-- maxNumberOfAuthenticationFailures
       This value should be in sync with the value for
       org.apache.jetspeed.security.spi.impl.MaxPasswordAuthenticationFailuresInterceptor
       (if used) to make sense.
       Any value < 2 will suppress the LoginConststants.ERROR_FINAL_LOGIN_ATTEMPT
       error code when only one last attempt is possible before the credential
       will be disabled after the next authentication failure.
  -->
  <constructor-arg index="0"><value>3</value></constructor-arg>  
</bean>

Also, make sure the above valves are configured in the jetspeed-pipeline bean.

See the Credentials Management document for a description of these valves and their relation to the interceptors configuration.

security-spi-atz.xml

This configuration file contains all the configurations for configuring the authorization SPI.

Bean Description
org.apache.jetspeed.security.spi.RoleSecurityHandler The RoleSecurityHandler encapsulates all the operations around the role principals.
org.apache.jetspeed.security.spi.GroupSecurityHandler The GroupSecurityHandler encapsulates all the operations around the group principals.
org.apache.jetspeed.security.spi.SecurityMappingHandler The SecurityMappingHandler encapsulates all the operations involving mapping between principals. It contains the logic managing hierarchy resolution for hierarchical principals (roles or groups). The default hierarchy resolution provided is a hierarchy by generalization (see overview for definitions). A contructor-arg can be added to the SecurityMappingHandler to change the hierarchy resolution strategy. Jetspeed 2 also support a hierarchy resolution by aggregation.

A sample SecurityMappingHandler configuration could be: 

<!-- Security SPI: SecurityMappingHandler -->
<bean id="org.apache.jetspeed.security.spi.SecurityMappingHandler" 
      class="org.apache.jetspeed.security.spi.impl.DefaultSecurityMappingHandler">  	   
   <constructor-arg >
      <ref bean="org.apache.jetspeed.security.spi.SecurityAccess"/>
   </constructor-arg>
   <!-- Default role hierarchy strategy is by generalization.  
        Add contructor-arg to change the strategy. -->
   <!-- Default group hierarchy strategy is by generalization.  
        Add contructor-arg to change the strategy. -->
</bean>