User Security and Access Control in JBoss portals

6 min read


Authentication in JBoss portal builds on the JEE security provided by the JBoss server. The JEE specification defines the roles and constraints under which certain URLs and components are protected. However, this might not always be sufficient for building enterprise applications or portals. Application server providers such as JBoss supplement the authentication and authorization features provided by the JEE specification with additional features such as role-to-group mapping and session logout.

Authentication in JBoss portal can be divided into configuration files and portal server configuration.

The jboss-portal.sar/portal-server.war file is the portal deployment on the JBoss application server. Assuming that the portal server is like any JEE application deployed on an application server, all user authentication configurations go into the WEB-INF/web.xml and the WEB-INF/jboss-web.xml files.

  1. The WEB-INF/web.xml entry defines the authentication mode, with the default being form-based authentication. This file is also used to define the login and error pages, as defined by the JEE specification.
  2. The default security domain defined by the JBoss application server is java:/jaas/portal for JBoss portal. The security domain maps the JEE security constructs to the operational domain. This is defined in a proprietary file, WEB-INF/jboss-web.xml. The portal security domain authentication stack is defined in the jboss-portal.sar/conf/login-config.xml file, and is deployed along with the portal. Login-config.xml houses the JAAS modules for authentication. Custom modules can be written and added here to support special scenarios. The server provides a defined set of JAAS login modules that can be used for various scenarios. For example, the IdentityLoginModule is used for authentication based on local portal data, SynchronizingLdapLoginModule for authentication using LDAP, and DBIdentityLoginModule for authentication using a database.

Within the jboss-portal.sar/portal-server.war application, all portal requests are routed through a single servlet called org.jboss.portal.server.servlet.PortalServlet. This servlet is defined twice, as follows, in the configuration file WEB-INF/web.xml to ensure that all possible request sources are covered:

  • PortalServletWithPathMapping for path mappings
  • PortalServletWithDefaultServletMapping for the default servlet mapping

The servlet is mapped four times with variations to address a combination of secure SSL access and authenticated URLs, as follows:

  • /*: Default access, and with no security constraint, allows access to everybody
  • /sec/*: All requests to a secure protocol are routed through this path, ensuring SSL transport
  • /auth/*: Authenticated access. Requires user to be authenticated before accessing the content under this tree
  • /authsec/*: An authenticated and secure access

The following snippet from web.xml shows the entries:

<!-- Provide access to unauthenticated users -->
<!-- Provide secure access to unauthenticated users -->
<!-- Provide access to authenticated users -->
<!-- Provide secure access to authenticated users -->

The URL patterns can be changed based on personal preference.


Authorization is the process of determining if an authenticated user has access to a particular resource. Similar to authentication, JBoss portal provides in-built support for authorization, through Java Authorization Contract for Containers(JACC). JACC is a JSR-115 specification for the authorization models of the Java2 and JEE enterprise platforms. In the next few sections, we will look at how JBoss portal facilitates authorization using JACC. However, before we go into the details of access controls and authorization configurations, let’s quickly look at how roles are configured in JBoss Portal.

User and role management

A role is an authorization construct that denotes the group that a user of the portal belongs to. Typically, roles are used to determine the access rights and the extent of these rights for a given resource. We saw in an earlier section how to configured portal assets such as, portals, pages, and portlet instances, to restrict certain actions to specific roles. We used a role called SPECIAL_USER for our examples. However, we never really defined what this role means to JBoss portal.

Let’s use the JBoss portal server console to register this role with the server.

Log in as admin, and then click on the Members tab. This takes us to the User Management and Role Management tabs.

User Security and Access Control in JBoss portals

The User Management tab is used for creating new users. We will come back to this shortly, but for now, let’s switch over to the Role Management tab and click on the Create role link on the bottom right of the page. We can now add our SPECIAL_USER role and provide a display name for it. Once we submit it, the role will be registered with the portal server.

User Security and Access Control in JBoss portals

As we will see later, every attempt by an authenticated user to access a resource that has security constraints through a specific role will be matched by the portal before granting or denying access to the resource.

Users can be added to a role by using the User Management tab. Each user has a role property assigned, and this can be edited to check all of the roles that we want the user to belong to. We can see that for the user User, we now have an option to add the user to the Special User role.

User Security and Access Control in JBoss portals

The portal permission

A permission object carries the relevant permission for a given entity. The object is used to describe permission for the portal. Like all the other entity-specific permission classes, it extends the class, and any permission checked in the portal should extend the PortalPermission as well. Two additional fields of significance are as follows:

  1. uri: A string that specifies the URI of the resource that is described by the permission
  2. collection: An object of class, which is used when the permission acts as a container for other permissions

The authorization provider

The authorization provider is a generic interface of the type, and provides access to several services.

public interface AuthorizationDomain
String getType();
DomainConfigurator getConfigurator();
PermissionRepository getPermissionRepository();
PermissionFactory getPermissionFactory();

Let us look into these classes a bit more in detail:

  • provides configuration access to an authorization domain. The authorization schema consists of bindings between URIs, roles, and permissions.
  • provides runtime access to the authorization domain. It is used to retrieve the permissions for a specific role and URI. It is used at runtime by the framework, to take security decisions.
  • is a factory to instantiate permissions for the specific domain. It is used at runtime to create permission objects of the appropriate type by the security framework.


Please enter your comment!
Please enter your name here