I attended the CIO Forum a several months ago and sat in on a presentation on Identity Management, which is considered by C-level executives one of the hot technologies. From a C-level executive’s perspective, this presentation falls generally under the domain of Identity Management. At the Forum, the speaker briefly discussed RBAC (Role Base Access Control) and anecdotally mentioned that it is a “hard nut to crack.”
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
This article is an extension of a recent article I published on TheServerSide.com, Exploring J2EE Security for Applications using LDAP. That article identified key interfaces within a J2EE compliant application server that need to be configured in order to build secure applications focusing on RBAC, which is an integral part of Identity Management.
However, the article did not discuss, in detail, alternatives to using LDAP directly for Java Authentication and Authorization Service (JAAS) security, such as a Trust Association, one of the more popular system alternatives. Essentially, the power of JAAS is in its ability to use almost any underlying security system. One of those approaches is to use a Trust Association Interceptor (TAI) instead of direct LDAP access.
Security System Alternatives
A TAI is used to connect reverse proxies, such as IBM WebSeal or Oblix NetPoint (recently acquired by Oracle) to a J2EE application server. A TAI allows for single sign-on (SSO) and management privileges within J2EE resources: for example, authentication, authorization and policy-based security. The NetPoint platform, so to speak, can be used for WebSphere, Orace9iAS and BEA WebLogic to provide many of the enterprise-wide security services listed in Figure 1. The focus of this article is to understand how to architect for RBAC within an environment centered on J2EE using a TAI.
Figure 1 - Enterprise-wide security services
JAAS and TAI Configuration
Within WebSphere Application Server (WAS), a TAI is configured using the application server console (see Figure 2). It is important to point out that the TAI is an interface to the underlying security system; security behavior is implemented using JAAS for object method level security. Security-aware objects use a guard block before executing potentially dangerous code. Without this guard block, a method is security-agnostic, able to be executed by any client code at any time.
JAAS is a set of packages that augments the core Java 2 platform with the means to authenticate and enforce access controls upon users. JAAS is a feature included in most J2EE-compliant application servers and was mandated by the J2EE 1.3 Specification. As mentioned, JAAS is able to use almost any underlying security system or can be extended through a TAI to external security subsystems.
JAAS implements a pure Java version of the standard PAM (Pluggable Authentication Module) framework, and extends the access control architecture of the Java 2 Platform to support role-based and user-based SSO through third party TAIs.
Figure 2 - Trust Association is used to connect reverse proxies
Trust Association Interceptor Architecture
Here are the Trust Association Interceptor-based login processing (see Figure 3) steps:
- A user tries to access a WebSphere resource through a browser.
- WAS forwards the user’s request to the NetPoint Connector for WebSphere.
- The NetPoint Connector for WebSphere checks with the Access Server and authenticates the user using the Access Gate.
- If single sign-on is enabled in the WAS, an LTPA (Lightweight Third Party Authentication) token, an IBM proprietary token for security, is generated.
- The NetPoint Connector for WebSphere queris the COREid Server via WebGate for a list of groups to which the user belongs. The COREid Server checks the LDAP directory and returns the information to the NetPoint Connector for WebSphere.
- The NetPoint Connector for WebSphere returns this information to the WAS.
- WAS checks the deployment descriptor for a user-security or group-security role mapping (i.e. application.xml, ejb_jar.xml and web.xml). If the user or group belongs to a security role that is allowed to access the resource, the WAS allows the user to access the resource.
Figure 3 - Integrating the Application Server with a TAI for Oblix, NetPointWASRegistry
TAI Component Interaction
WAS, using the TAI/AccessGate, authenticates a user through the Access Server. In turn, the TAI/AccessGate retrieves group-level privileges through WebPass from the COREid Server policy-based authorization. Access and COREid servers use LDAP to contain user identity information.
NetPoint protects J2EE resources, such as admin tools, servlets, passwords, JDBC connection pools, JMS destinations and JNDI contexts.
Declarative security is available only for HTTP servlet and EJB methods defined in Web.xml and EJB_JAR.xml files, respectively.
URL secure access is available using WebGate for servlet and JSP page security.
More granular page security needs to be programmed into tag libraries that use JAAS or the AccessGate Java API.
Design Patterns and Security
The well-known Model-View-Controller pattern splits applications into three distinct roles. The RBAC security pattern can be implemented within all layers of the MVC pattern -- URL access for JSP, servlet and EJB access (see Figure 4).
In order to run a secure application, the client must have the required role. A servlet typically runs with the identity of the client. When the servlet calls an EJB method, a check is made to see if the servlet identity has the required role. EJB methods can run with the identity of the caller, the server or an identity associated with a role.
A user’s identity is passed in the request from the Web application to the EJB container, to a connector. Connectors provide a standard way to communicate with existing information systems. When an EJB method uses a connector, an identity is provided. With Web application-only “style” applications, (a.k.a. Model 2 JSP architectures) fine-grained access control requires programmatic security:
The identity depends on the type of connector being used. As discussed in the Trust Association Interceptor architecture, a token or cookie is created using the TAI/Access server for SSO functionality.
Figure 4 - Design Patterns for a medium performance OLTP application
The securing system accessed through the J2EE application server or a TAI could have been the local operating system, LDAP, RACF or Oblix NetPoint. For WebSphere users, Oblix NetPoint represents an alternative to Tivoli.
From an open system or Java perspective, JSR 196 Authentication Service Provider Interface for Containers and JSR 115 Authorization Contract should be evaluated, as well as the vendors that support those specifications.
Although application security remains a programmatic area where creativity seems to rule the day, letting programmers proceed with their own application security constructs is always an option. Again, based on a discussion I had at the CIO Forum, some IT managers believe that application security beyond SSO should be left up to the individual devices of the application developers.
About the Author
Frank Teti is an industry analyst and principal architect. He can be reached at email@example.com.