Skip to main content

Cocoon authentication

This article will guide you through the steps showing how to use the Authentication Framework in a Cocoon 2.2 application.
  1. Maven dependencies.
  2. Spring configuration.
  3. Sitemap.
  4. Login page and controls.
Maven dependencies
You need the following dependency in your pom.xml:
<dependency>
  <groupId>org.apache.cocoon</groupId>
  <artifactId>cocoon-auth-impl</artifactId>
  <version>1.0.0</version>
</dependency>

Spring configuration
Authentication Framework has a flexible configuration based on a concepts of applications and security handlers. There can be several applications defined and running at the same that are simply independent security zones of your web application. The security details of an application are specified using a security handler. There are several implementations provided and you're free to implement your own. Here is the SimpleSecurityHandler used that takes the hardcoded credentials:
<?xml version="1.0"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
       http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

  <!-- This is a simple security handler -->
  <bean name="org.apache.cocoon.auth.SecurityHandler/handler"
        class="org.apache.cocoon.auth.impl.SimpleSecurityHandler">
    <property name="userProperties">
      <value>
        admin=password
      </value>
    </property>
  </bean>

  <!-- This is the standard application -->
  <bean name="org.apache.cocoon.auth.Application/myapp"
        class="org.apache.cocoon.auth.impl.StandardApplication">
    <property name="securityHandler" ref="org.apache.cocoon.auth.SecurityHandler/handler"/>
  </bean>
</beans>
You can protect your functionality with authentication using different ways. Below is the most straightforward way represented using the protected URI space that requires authentication.

Sitemap
Below are two pipelines managing the authentication process and the protected functionality. The pipeline delete/item is made internal-only, so it can be externally accessed only via the protected area: protected/delete/item. The request parameter destination is used to redirect back to the protected area once a user passes the authentication successfully.
<map:pipeline id="authentication">
  <!-- Simple login page -->
  <map:match pattern="login">
    <!-- if we are already logged in, redirect to destination -->
    <map:act type="cauth-is-logged-in">
      <map:parameter name="application" value="search"/>
      <map:redirect-to uri="{request-param:destination}"/>
    </map:act>
    <map:generate src="cocoon:/page/login.jx"/>
    <map:serialize type="xhtml"/>
  </map:match>

  <!-- Form target which performs auth service -->
  <map:match pattern="do-login">
    <!-- try to login -->
    <map:act type="cauth-login">
      <map:parameter name="application" value="search"/>
      <map:parameter name="name" value="{request-param:username}"/>
      <map:parameter name="password" value="{request-param:password}"/>
      <map:redirect-to uri="{request-param:destination}"/>
    </map:act>
    <!-- something was wrong, try it again -->
    <map:redirect-to uri="login?{request:queryString}"/>
  </map:match>

  <!-- Logout link which invalidates the session -->
  <map:match pattern="do-logout">
    <map:act type="cauth-logout">
      <map:parameter name="application" value="search"/>
      <map:redirect-to uri="{request-param:destination}"/>
    </map:act>
    <map:redirect-to uri="login?{request:queryString}"/>
  </map:match>

  <!-- Protected area -->
  <map:match pattern="protected/**">
    <map:act type="cauth-is-logged-in">
      <map:parameter name="application" value="search"/>
      <map:generate src="cocoon:/{../1}"/>
      <map:serialize type="xhtml"/>
    </map:act>
    <!-- something was wrong, redirect to login page -->
    <map:redirect-to uri="{request:contextPath}{request:servletPath}/login?destination={request:requestURI}?{request:queryString}"/>
  </map:match>
</map:pipeline>

<map:pipeline id="protected" internal-only="true">
  <!-- example of protected pipeline -->
  <map:match pattern="delete/item">
    <map:call function="deleteItem"/>
  </map:match>
</map:pipeline>
You can find three authentication actions used above: cauth-is-logged-in, cauth-login and cauth-logout. They are provided as a part of Authentication Framework, thus, do not require additional configuration.

Login page and controls
The login page is simple and implemented as a JX template. It takes care of submitting the authentication form properly with the correct destination parameter value. The variable blockPath helps to avoid redirection issues with incorrect relative URLs.
<?xml version="1.0" encoding="UTF-8"?>
<jx:template xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">

  <!-- Import other used templates  -->
  <jx:import uri="page/templates/page.jx"/>

  <jx:set var="blockPath" value="${cocoon.request.contextPath + cocoon.request.servletPath}"/>

  <page-macro>
    <head-macro/>
    <body-macro>
      <h2 id="title">Login</h2>
      <form action="${blockPath}/do-login?destination=${cocoon.request.destination}" method="POST">
        <div>You need to be authenticated to perform upload/remove actions.</div>
        <table>
          <tbody>
            <tr>
              <td>User name:</td>
              <td>
                <input type="text" name="username"/>
              </td>
            </tr>
            <tr>
              <td>Password:</td>
              <td>
                <input type="password" name="password"/>
              </td>
            </tr>
            <tr>
              <td/>
              <td>
                <input type="submit" value="Login"/>
              </td>
            </tr>
          </tbody>
        </table>
      </form>
    </body-macro>
  </page-macro>

</jx:template>
Here is another JX template snippet that shows how to add a common html markup with logged in user name and controls. It also takes care of providing the destination parameter and uses the same blockPath variable as above.
<jx:set var="user" value="${cocoon.session.getAttribute('cauth-user-myapp')}"/>

<jx:choose>
  <jx:when test="${user != null}">
    <span id="logged_in">
      <span id="label_username">${user.getId()}</span>
      <a href="${blockPath}/do-logout?destination=${cocoon.request.requestURI}">
        <img src="${blockPath}/resource/external/icons/logout.png" title="Log out"/>
      </a>
    </span>
  </jx:when>
  <jx:otherwise>
    <span id="not_logged_in">
      <a href="${blockPath}/do-login?destination=${cocoon.request.requestURI}">
        <img src="${blockPath}/resource/external/icons/login.png" title="Log in"/>
      </a>
    </span>
  </jx:otherwise>
</jx:choose>
To conclude, I'll list other useful resources as the online documentation is quite poor:

Comments

Popular posts from this blog

Connection to Amazon Neptune endpoint from EKS during development

This small article will describe how to connect to Amazon Neptune database endpoint from your PC during development. Amazon Neptune is a fully managed graph database service from Amazon. Due to security reasons direct connections to Neptune are not allowed, so it's impossible to attach a public IP address or load balancer to that service. Instead access is restricted to the same VPC where Neptune is set up, so applications should be deployed in the same VPC to be able to access the database. That's a great idea for Production however it makes it very difficult to develop, debug and test applications locally. The instructions below will help you to create a tunnel towards Neptune endpoint considering you use Amazon EKS - a managed Kubernetes service from Amazon. As a side note, if you don't use EKS, the same idea of creating a tunnel can be implemented using a Bastion server . In Kubernetes we'll create a dedicated proxying pod. Prerequisites. Setting up a tunnel. ...

Notes on upgrade to JSF 2.1, Servlet 3.0, Spring 4.0, RichFaces 4.3

This article is devoted to an upgrade of a common JSF Spring application. Time flies and there is already Java EE 7 platform out and widely used. It's sometimes said that Spring framework has become legacy with appearance of Java EE 6. But it's out of scope of this post. Here I'm going to provide notes about the minimal changes that I found required for the upgrade of the application from JSF 1.2 to 2.1, from JSTL 1.1.2 to 1.2, from Servlet 2.4 to 3.0, from Spring 3.1.3 to 4.0.5, from RichFaces 3.3.3 to 4.3.7. It must be mentioned that the latest final RichFaces release 4.3.7 depends on JSF 2.1, JSTL 1.2 and Servlet 3.0.1 that dictated those versions. This post should not be considered as comprehensive but rather showing how I did the upgrade. See the links for more details. Jetty & Tomcat. JSTL. JSF & Facelets. Servlet. Spring framework. RichFaces. Jetty & Tomcat First, I upgraded the application to run with the latest servlet container versio...

Managing Content Security Policy (CSP) in IBM MAS Manage

This article explores a new system property introduced in IBM MAS 8.11.0 and Manage 8.7.0+ that enhances security but can inadvertently break Google Maps functionality within Manage. We'll delve into the root cause, provide a step-by-step solution, and offer best practices for managing Content Security Policy (CSP) effectively. Understanding the issue IBM MAS 8.11.0 and Manage 8.7.0 introduced the mxe.sec.header.Content_Security_Policy   property, implementing CSP to safeguard against injection attacks. While beneficial, its default configuration restricts external resources, causing Google Maps and fonts to malfunction. CSP dictates which domains can serve various content types (scripts, images, fonts) to a web page. The default value in this property blocks Google-related domains by default. Original value font-src 'self' data: https://1.www.s81c.com *.walkme.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' ...