8 min read

(For more resources related to this topic, see here.)

Introduction

This article discusses the configurations aimed at providing security features to portals and all the related components. We will see that we can work using either the web console or the XML configuration files. As you would expect, the latter is more flexible in most instances.

Many of the configuration snippets shown in the article are based on Enterprise Deployment Descriptors (DD). Keep in mind that XML always remains the best option for configuring a product. We will configure GateIn in different ways to show how to adapt some of the internal components for your needs.

Enterprise Deployment Descriptors (DD) are configuration files related to an enterprise application component that must be deployed in an application server.

The goal of the deployment descriptor is to define how a component must be deployed in the container, configuring the state of the application and its internal components.

These configuration files were introduced in the Java Enterprise Platform to manage the deployment of Java Enterprise components such as Web Applications, Enterprise Java Beans, Web Services, and so on.

Typically, for each specific container, you have a different definition of the descriptor depending on vendors and standard specifications.

Typically, a portal consists of pages related to a public section and a private section. Depending on the purpose, of course, we can also work with a completely private portal.

The two main mechanisms used in any user-based application are the following:

  • Authentication
  • Authorization

In this article we will discuss authorization: how to configure and manage permissions for all the objects involved in the portal. As an example, a User is a member of a Group, which provides him with some authorizations. These authorizations are the things that members of the Groups can do in the portal.

On the other side, as an example, a page is defined with some permissions, which says which Groups can access it. Now, we are going to see how to configure and manage these permissions, for the pages, components in a page, and so on in the portal.

Securing portals

The authorization model of the portal is based on the association between the following actors: groups, memberships, users, and any content inside the portal (pages, categories, or portlets).

In this recipe, we will assign the admin role against a set of pages under a specific URL of the portal. This configuration can be found in the default portal provided with GateIn so you can take the complete code from there.

Getting ready

Locate the web.xml file inside your portal application.

How to do it…

We need to configure the web.xml file assigning the admin role to the following pages under the URL http://localhost:8080/portal/admin/* in the following way:

<security-constraint>
<web-resource-collection>
<web-resource-name>
admin authentication
</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>

The role must be declared in a different section under the security-constraint tag through the security-role tag. The role-name tag defines the id of the role:

<security-role>
<description>the admin role</description>
<role-name>admin</role-name>
</security-role>

How it works…

GateIn allows you to add different roles for every sections of the portal simply by adding a path expression that can include a set of sub-pages using wildcard notation (/*).

This is done by first defining all the needed roles using the security-role element, and then defining a security-constraint element for each set of pages that you want to involve.

PicketLink is also for users and memberships, and can manage the organization of the groups.

There’s more…

Configuring GateIn with JAAS

GateIn uses JAAS (Java Authentication Authorization Service) as the security model.

JAAS (Java Authentication Authorization Service) is the most common framework used in the Java world to manage authentication and authorization. The goal of this framework is to separate the responsibility of users’ permissions from the Java application. In this way, you can have a bridge for permissions management between your application and the security provider.

For more information about JAAS, please see the following URL: http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html

Java EE Application servers and JSP/servlet containers, such as JBoss and Tomcat, also support JAAS with specific deployment descriptors.

The default JAAS module implemented in GateIn synchronizes the users and roles from the database. In order to add your portal to a specific realm, add the following snippet in web.xml:

<login-config>
. . .
<realm-name>gatein-domain</realm-name>
. . .
</login-config>

Notice that a realm can be managed by JAAS or another authorization framework—it is not important which is used for the Java Enterprise Edition.

gatein-domain is the ID of the default GateIn domain that we will use as the default reference for the following recipes.

See also

  • The Securing with JBoss AS recipe

  • The Securing with Tomcat recipe

Securing with JBoss AS

In this recipe, we will configure GateIn with JAAS using JBoss AS (5.x and 6.x).

Getting ready

Locate the WEB-INF folder inside your portal application.

How to do it…

Create a new file named jboss-web.xml in the WEB-INF folder with the following content:

<jboss-web>
<security-domain>
java:/jaas/gatein-domain
</security-domain>
</jboss-web>

How it works…

This is the JNDI URL where the JAAS module will be referenced. This URL will automatically search the JAAS modules called gatein-domain.

The configuration of the modules can be found inside the file gatein-jboss-beans.xml. Usually, this file is inside the deployed <PORTAL_WAR_ROOT>/META-INF, but it could be placed anywhere inside the deploy directory of JBoss, thanks to the auto-discovery feature provided by the JBoss AS.

Here is an example:

<deployment >
<application-policy

name="gatein-domain">
<authentication>
<login-module code=
"org.gatein.wci.security.WCILoginModule"
flag="optional">
<module-option name="portalContainerName">
portal
</module-option>
<module-option name="realmName">
gatein-domain
</module-option>
</login-module>
<login-module code=
"org.exoplatform.web.security.PortalLoginModule" flag="required">
………..
</application-policy>
</deployment>

JAAS allows adding several login modules, which will be executed in cascade mode according to the flag attribute. The following represents a description of the valid values for the flag attribute and their respective semantics as mentioned in the Java standard API:

  • Required: The LoginModule is required to succeed. If it succeeds or fails, authentication still continues to proceed to the next LoginModule in the list.

  • Requisite: The LoginModule is required to succeed. If it succeeds, authentication continues on the next LoginModule in the list. If it fails, the control immediately returns to the application and the authentication process does not proceed to the next LoginModule.

  • Sufficient: The LoginModule is not required to succeed. If it does succeed, the control immediately returns to the application and the authentication process does not proceed to the next LoginModule. If it fails, authentication continues forward to the next LoginModule

  • Optional: The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed to the next LoginModule.

Look at the recipe Choosing the JAAS modules for details about each login module.

See also

  • The Securing portals recipe

  • The Securing with Tomcat recipe

  • The Choosing the JAAS modules recipe

Securing with Tomcat

In this recipe, we will configure a JAAS realm using Tomcat 6.x.x/7.x.x.

Getting ready

Locate the declaration of the realm inside <PORTAL_WAR_ROOT>/META-INF/context.xml.

How to do it…

  • Change the default configuration for your needs, as described in the previous recipe. The default configuration is the following:

    <Context path='/portal' docBase='portal' debug='0'
reloadable='true' crossContext='true'
privileged='true'>
<Realm className=
'org.apache.catalina.realm.JAASRealm'
appName='gatein-domain'
userClassNames=
'org.exoplatform.services.security.jaas.UserPrincipal'
roleClassNames=
'org.exoplatform.services.security.jaas.RolePrincipal'
debug='0' cache='false'/>
<Valve
className=
'org.apache.catalina.authenticator.FormAuthenticator'
characterEncoding='UTF-8'/>
</Context>
;

  • Change the default configuration of the JAAS domain that is defined in the TOMCAT_ HOME/conf/jaas.conf file. Here is the default configuration:

    <gatein-domain {
org.gatein.wci.security.WCILoginModule optional;
org.exoplatform.services.security.jaas.SharedStateLoginModule
required;
org.exoplatform.services.security.j2ee.TomcatLoginModule
required;
};

How it works…

As we have seen in the previous recipe, we can configure the modules in Tomcat using a different configuration file. This means that we can change and add login modules that are related to a specific JAAS realm.

The context.xml file is stored inside the web application. If you don’t want to modify this file, you can add a new file called portal.xml in the conf folder to override the current configuration.

See also

  • The Security with JBoss AS recipe

  • The Choosing the JAAS modules recipe

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here