Exploring J2EE Security for Applications using LDAP

Overview

This article is loosely based on prototyping a number of J2EE applications constructs, such as servlets, EJB, MDB (Message-driven Beans) and JSP implemented using LDAP (Lightweight Directory Access Protocol) for application authorization. The applications were built in order to understand standard J2EE security and IBM WebSphere extensions. The article identifies key interfaces within WebSphere Application Server Version 5.x (WAS) or any J2EE compliant application server that need to be configured in order to build secure applications.

The EJB prototype used implemented the Façade Design Pattern. This pattern provides a unified interface to a set of interfaces in a subsystem that makes the subsystem easier to use. From a J2EE, perspective this usually means implementing a set of JSPs and servlets in conjunction with one to many EJBs. Implementing this design for enterprise-wide applications requires services above and beyond business logic. That is, infrastructure services, such as, authorization, authentication and encryption services need to be designed for and eventually configured or programmed into the application. The intention of the prototypes is to use declarative application security not programmatic.

J2EE Security

J2EE uses the same authorization model for both web-based components (servlets and JSPs) and enterprise components (EJBs). The specification requires transparent propagation of security credentials within the J2EE environment, so that once a user has authenticated to any J2EE component, the same security information is used by all other components. The model provides a solid framework for implementing a secure Façade Design Pattern.

source: Hype Cycle for Application Development, Theresa Lanowitz, June 2004

According to Gartner’s “Hype Cycle”, security at the application level has two to five years before the real-world benefits of the technology are demonstrated and accepted. The report further comments that application development organizations do not have the appropriate skills to deliver source-code security. Tools delivering security content are crucial. Application security is critical to the success of other emerging and embryonic technologies.

Key LDAP Terms

The following LDAP terms are used in this article:

directory information tree (DIT)
The hierarchical organization of entries that make up a directory.

distinguished name (DN)
A distinguished name uniquely identifies an entry in the directory. A DN is made up of “relative” distinguished names of the entry and each of the entry's parent entries, up to the root of the directory tree. These names are usually separated by commas and optional spaces. For example: 'uid=JohnDoe, ou=People, dc=company, dc=com'.

objectclass
An objectclass is a formal definition of a specific kind of objects that can be stored in the directory. An objectclass is a distinct, named set of attributes that represents something concrete, such as a user, a computer, or an application.

LDAP URL
LDAP URL is a string that specifies the location of an LDAP resource. An LDAP URL consists of server host and port, search scope, baseDN, filter, attributes and extensions.

schema
An LDAP schema defines a set or rules that specifies the types of objects that a directory may contain and the required and optional attributes that entries of different types should have.

The Enabling Technologies

The technologies utilized were:

• WebSphere Studio Application Developer Integration Edition Version 5.0.1 (WSAD);
• Rational XDE 1.5 (XDE);
• WebSphere Application Server 5.0;
• LDAP Browser Version 2.8.1 (by Jarek Gawor);
• IBM Tivoli Directory Server Configuration Tool ;
• Tivoli Directory Server Version 5.2.

Requirements

The basic requirements were:

• To establish a schema and specify objectclasses in order to contain a user/group hierarchy or DIT;
• Add test users in two groups an administrator group and a user group;
• Build and configure test J2EE applications that enforce group permissions represented in the schema.

Test users were associated with the LDAP Groups listed below.

LDAP Group (J2EE Role) *
Users
Admins
User and Admins
not in a group

* Note that a J2EE Role is equivalent to an LDAP Group.

Prototype Sequence Diagram

UML Specification

Based on UML theory, a Sequence diagrams represents the realization of (Use Case) requirements. The prototype depicted above specifies a JSP that integrates with a servlet that invokes a local session EJB. Access to the servlet and the EJB is based on declarative security. HTTP Session state is maintained within the servlet and forwarded to the JSP page using a Java bean maintained in a JSP tag. These infrastructure implementation details are not specified in the diagram, since the purpose of the Sequence diagram is to specify the application security model.

An EJB is used primarily because of the inherent capabilities built into the EJB container to support security, such as, granular security at the method level. It is my opinion, that many J2EE architects have issues with EJB complexity; however, some of them are remiss in pointing out that they were designed for robust, enterprise-wide deployments that include container managed transactions, security and object pooling.

WAS Security Extensions to J2EE Security

The prototypes use the IBM implementation of FormLoginServlet. FormLoginServlet uses the J2EE form-based login technology, which provides the ability to customize login pages. The mechanism uses servlet filters to log user information and is an IBM extension to the J2EE specification. The FormLoginServlet authenticates a client by placing an LTPA token in a Cookie also referred to as an SSO Cookie.

FormLogoutServlet is used to initiate logout. A session cannot simply be invalidated, since the user still has an LTPA token in a cookie that can subsequently enable access to secure resources on WAS within another session. The LTPA token is contained in the Request object not the Session object. FormLogoutServlet provides a mechanism to log out without having to close all Web-browser sessions. This feature is not required by J2EE specifications, but is provided as an additional feature in WebSphere security. At the object interaction level, the logout method on the SSOAuthenticator object provides behavior that will logout a user by deleting the LTPA cookie.

Implementation of the FormLogoutServlet mechanism does not require configuration in the deployment descriptor. It requires a JSP with a post action set to “ibm_security_logout” that is included with the Web application. The page must be submitted by the user to initiate the logout operation.

Security Model Traceability

Conceptually, defining roles and constraints in the Web application deployment descriptors and mapping roles to LDAP group entries in the application deployment descriptor should be based on UML Use Case Actors. If this practice is embraced, the security model will be traceable from the code (e.g. web.xml and ejb-jar.xml) to the LDAP DIT to the realized Sequence diagrams of a specific Use Case. Following the RUP (Rational Unified Process) also insures that security is a feature that is considered early in the project lifecycle, not retrofitted in at the end.

WebSphere Roles Map to LDAP Groups

Based on requirements, the following access privileges exist.

1. The User and Administrator roles can access doGet method on the servlet;
2. The User role can access the SquareIt method on the EJB;
3. The Administrator role can access StringIt method on the EJB;
4. The “was” user is in both User and Administrator roles and can access either method.
5. The anonymous user cannot even access the servlet.

Security Exceptions

The security mechanism throws exceptions related to authentication and authorization. For example, if a user is in the “User” group tries to access the StringIt method the following exception is thrown: Authorization failed for fteti while invoking (Bean) ejb/com/qvc/test/TestEJBLocalHome StringIt(String): securityName: fteti;accessID: user: cn=Frank Teti, ou=people is not granted any of the required roles: admins.

Establishing the LDAP Schema and DIT Repository

Setting up a directory infrastructure for J2EE authentication and authorization requires a clear understanding of middleware access privileges. Although, decisions as to which type of structure, that is, deep verses shallow heirarchies is a business process decision and to a degree a technical decision. If possible, to reduce the number of queries that the LDAP must perform when checking to find whether a user is a member of a group, it is best to keep your group hierarchies shallow. From a business perspective, a shallow directory hierarchy is less sensitive to organizational changes than a deep hierarchy. The DIT depicted in above is relatively shallow based on simple prototype requirements

The prototypes relies on LTPA configured to use a basic DIT for a user registry. An LDAP directory stores information in nodes. In this directory, each user has a node that stores unique information. A group has a node that maintains a list of unique members. WebSphere LPTA uses LDAP to map authorization roles to users and groups. The DIT needs to contain a set of user entries and a set of groups. Each group entry refers to a subset of users that belong to that group.

Each person node under the ou=people node contains the object classes person and ePerson. These object classes include optional attributes that can fulfill most anticipated personnel directory requirements. The ePerson object class defines the uid and userPassword attributes that WebSphere will use for authenticating a request having a supplied user ID and password through a JSP.

Each ou=groups node contains the groupOfUniqueNames object class, which specifies a multivalued attribute named uniqueMember. A group entry will use the value list of this attribute to reference the distinguished name (DN) of each user in a given group. WebSphere will use this information to check group membership for a role mapped to a DIT group.

LDAP Interchange Format File

LDAP uses an import and export file format, called LDAP Interchange Format (LDIF), composed of name-value pairs that define and populate nodes in the DIT. An LDIF file was created to initially populate the directory for the prototypes. A DIT resembles a file directory tree, where higher-level nodes contain lower-level nodes.

The DIT root will be the directory suffix o=rogers60,c=us, which needs to be defined in the IBM Directory Server Configuration Tool. The next level defines the people and groups nodes. The user node has a uid attribute set to "was". This defines the user account to be used by the WAS instance when security is enabled.

The userPassord attribute is not encrypted and is sent in clear text on the network. Therefore, an SSL connection to the LDAP Server from the WAS server should be configured which will protect transient data on the the network.

Configurations for Security within the Application Server

The following interfaces need to be configured to enabled security within the applciation server. Other that the LDAP server, the key interfaces are the web.xml, ejb-jar.xml, application.xml and administrative console.

Configuring the Web Application Web Deployment Descriptor

SECURITY ROLES/CONSTRAINTS

Using the Navigator view for WSAD, create roles (e.g. users, admins, etc.) constraints associated with a role.

AUTHENTICATION METHOD

Specify the authentication method for this application by configuring the Pages folder for Form Authentication method.

Configuring the Application Deployment Descriptor

LDAP MAPPING

Map roles to LDAP groups by configuring the Security folder.

Configuring the EJB Deployment Descriptor

EJB PERMISSIONS

Enable application security on EJBs by adding security roles and setting appropriate permissions at the bean or method level on the Assembly Descriptor folder.

Configuring the WAS Application Server

CONFIGURE LTPA

Select the SecurityLTPA tree node enter credentials and generate keys.

CONFIGURE TRUST ASSOCIATION

Under the LTPA folder A Trust Association Interceptor is configured to connect reverse proxies, such as, WebSeal or Netegrity to WebSphere. TAI provides for technologies to allow for SSO within IBM WebSphere environments. With this mechanism a organization can centralized management across enterprise resources reducing the need for multiple security policies and user profiles.

SPECIFY USER REGISTRY

Under the User Registry/LDAP tree node specify the established settings for the LDAP server and DIT.

GLOBAL SECURITY

Under the Security tree node, enable Global Security and select the active authentication to LDAP.

Architectural Implications

Back when I was involved with DCE (The Distributed Computing Environment) and CORBA application development, a colleague of mine remarked that to be initiated into distributed systems engineering a Gestalt Psychology was required. Understanding the J2EE security model is not enough to ensure an iron-clad enterprise-wide, security model. Depending on the Web construct deployed, the mechanisms discussed in this article in addition to other identity management technologies (e.g. WebSEAL, Oblix, Netegrity, etc.) that support JSR 115 and 196 are needed to manage the enterprise.

Additionally, if Internet or SOA deployment is required other standards, such as, SAML (Security Assertion Markup Language) and Web Services Security (WS-Security) need to be added to the mix. WAS Version 6.0 supports WS-Security, which authenticates communications among Web servers; WS-Transactions, which ensures that Web services transactions are delivered consistently; and WS-I Basic Profile 1.1, which enables Web services to work together as a single solution.

References

Understanding LDAP Design and Implementation, IBM Redbook, June 2004
Implementing WebSphere security through LDAP: Security Tutorial, WebSphere Developer's Journal, May, 2003, Lou Mauget

Author Bios

Frank Teti is a Lead Architect and Industry Analyst. He can be reached at [email protected].