Article

J2EE Security Architecture Implementation with the SAP J2EE Engine

With the Java 2 Enterprise Edition (J2EE) platform, a worldwide community
has been involved in the development of a new environment for designing,
implementing, deploying, and running highly available, secure, reliable,
and scalable business applications. With the SAP Web Application Server
6.20, SAP provides a J2EE-compliant Java application server, the SAP J2EE
Engine. This article provides a brief overview of the J2EE security model,
including J2EE terminology that will be helpful to security and IT teams
looking to secure their J2EE-based programs using the SAP Web AS platform.
It also introduces some of the features that support three central aspects
of J2EE security — secure transport, user authentication, and authorization
— as implemented and administered in SAP’s J2EE engine.

Key Background on the J2EE Platform

Understanding SAP’s approach to security for the J2EE engine starts,
of course, with the J2EE specification itself,1 which delineates
the roles and responsibilities of all involved in setting up and maintaining
a J2EE-based application, along with the basic principles of J2EE security.

Roles and Responsibilities Specified in the J2EE Standard

Keeping any operational business application up and running requires
a number of players — tool providers, developers, and administrators,
just to name a few. The J2EE platform specification has taken pains to
make their roles very explicit, which helps clarify the responsibilities
you and your partners hold in everything from installation to security.
Admittedly, these roles might seem rather academic and theoretical at
first, but they appear throughout this article and are handy for delineating
the steps, phases, and responsibilities required over the lifecycle of
a business application.

According to the J2EE specification:

A J2EE Product Provider is the implementer and supplier of
the tools, runtime and management infrastructure components, J2EE platform
APIs, and other features as defined by the J2EE specification. SAP is
one such J2EE Product Provider. Note that runtime components include
a number of containers, which provide the required support for different
types of J2EE applications, such as web or Enterprise JavaBean (EJB)
applications.

Application Component Providers include the HTML document designers,
document programmers, and EJB developers who use the tools that produce
J2EE applications and components.

The Application Assembler is a developer responsible for grouping
and combining those application components with each other to form a
single J2EE application.

Finally, the Deployer is responsible for deploying web and
EJB applications into a specific operational environment as provided
by a J2EE product. The Deployer might be the system or application administrator.

So, where do these players fit into the
security of your applications?

According to J2EE specifications, the Application
Component Provider or Application Assembler is required to specify the
application component’s security requirements, along with environment
parameters and resource requirements, to the Deployer. This is communicated
via the deployment descriptor2 that comes with the application
components and is key to secure transport, authentication, and authorization.

The J2EE Product Provider is required to
provide the deployment tool that interprets these J2EE deployment descriptors
and to allow the Deployer to map the application component’s requirements
onto the capabilities of a specific J2EE product.

J2EE’s Container-Based Approach to Security

The central concept behind J2EE security is this: the security of application
components is provided by their containers. A container supports two complementary
approaches to security:

Programmatic security, where requirements within the application are
handled by method calls and coding inside the application programs

When using declarative security,
the application’s deployment descriptor expresses the security requirements,
including security roles, access control, and authentication, externally.
The deployment descriptor can express:

It’s then up to the Deployer to take
the security requirements expressed in the deployment descriptor and map
them to the security functions in the environment of the J2EE product.
At runtime, the container uses the security policy, as derived from the
deployment descriptor and configured by the Deployer, to enforce the application’s
security requirements.

Programmatic security is a secondary
approach to application security. It refers to security checks and decisions
explicitly made inside the application coding, and is useful when a declarative
approach is insufficient for an application’s security requirements.
If programmatic security is used, the Application Component Provider is
responsible for adding these checks to the program code. The J2EE Platform
standard APIs for Enterprise JavaBeans (EJB) and for web applications
(servlet) specify methods that support programmatic security for the EJBContext
interface and for the servlet HttpServletRequest interface.
For each of these two standard interfaces, there is one method for checking
the security roles and another for retrieving the principal name3
of the caller (authenticated user):

IsCallerInRole (EJBContext)

GetCallerPrincipal (EJBContext)

IsUserinRole (HttpServletRequest)

GetUserPrincipal (HttpServletRequest)

These methods can be used by application
component developers to enforce programmatic security in their programs.
Each J2EE Product Provider has to provide implementations for these methods
in the web and EJB containers of the product.

The SAP J2EE Engine allows you to
work with both the declarative and programmatic approaches and supports
each actor’s role in ensuring that J2EE-based applications are secure.
Figure 1 indicates how the J2EE specifications divide tasks among
the Application Component Provider, Application Assembler, and the Deployer.

Figure 1

Responsibilities Supporting Security in J2EE

Authorization: SAP’s J2EE Engine and the Visual Administrator
Tool

For user authorization, the J2EE specifications lay out three specific
sets of tasks (see Figure 2).

The Application Component Provider declares security role references
as used for the Application Component in its deployment descriptor.
These role references specify authorization constraints for access to
web resources or for calling EJB methods. They can also be used with
the programmatic security approach in the Application Component’s
program coding.

The Application Assembler is responsible for pulling these parts together,
by putting together several application components and defining security
roles for use by the application overall. To describe the application’s
authorization requirements, access to URLs and/or EJB methods are constrained
to the security roles the callers need. The Application Assembler links
each security role reference (in the application components) to one
of the application’s security roles.

Once the application itself is deployed on a specific J2EE product,
the Deployer assigns actual users and/or user groups on the J2EE server
to the application’s security roles.

The SAP J2EE Engine provides the
functions to support all three of these processes with the Deploy Tool,
part of the SAP J2EE Engine’s Visual Administrator client. As shown
in Figure 3, the Deploy Tool visual interface displays three views
— J2EEComponents, Assembler, and Deployer. The application component’s
security role references are visible in the J2EEComponents view. When
an application component is deployed on the SAP J2EE Engine, security
role references are linked to security roles of the application from the
Assembler view. In the Deployer view, users and/or user groups can be
assigned to security roles.

Figure 3

The Assembler and Deployer Views in the Deploy Tool

Integrated Management of Java and ABAP Users
Available with SAP Web AS 6.20’s J2EE Engine

It is the Deployer’s task to assign security roles, but to
which users or groups? What about users of ABAP applications? With
SAP Web Application Server Release 6.20, there are two possibilities
for configuring the user store of the SAP J2EE Engine:

You can take advantage of integrated user management with the
ABAP side of the SAP Web Application Server (default). Known ABAP-based
transactions for user management (SU01, etc.) are then used for
the administration of users for both ABAP and J2EE applications.

You can use local user management, where users and/or user groups
are created and administered using the security service views
in the Visual Administrator. These users are stored persistently
in the local file system.

In addition, all SAP authorization roles created using transaction
PFCG (profile generator) are also available as user groups in the
SAP J2EE Engine, and can be used to assign J2EE security roles.
This provides for role integration between ABAP and J2EE applications
on the SAP Web Application Server. For more details, please see
the online documentation.4

User Authentication: Login Mechanisms and Login Modules

As prescribed by the J2EE Specification, the SAP J2EE Engine supports
the three login mechanisms:

The J2EE v1.3 specification also
demands that J2EE Product Providers support the Java Authentication and
Authorization (JAAS) API5 for the web and EJB containers. This
is fully supported by SAP’s J2EE Engine. The authentication process,
as defined by the JAAS specification, follows the concept of a “login
context” object, created by the container implementations,6
with a configured stack of “login modules” (see Figure 4).
Several login modules can be flexibly plugged into the common login context,
where they can store information about authentication success or failure
and the authenticated user principal. The login modules can check different
authentication against various sources of user information, declaring
the strength of the authentication, for example, REQUIRED, SUFFICIENT,
or OPTIONAL. With a REQUIRED authentication status, for instance, the
login module is required to succeed. Whether it succeeds or fails, authentication
still continues to proceed down the login module stack. Alternatively,
with a SUFFICIENT status, the login module is not required to succeed.
If it does succeed, control immediately returns to the application, and
authentication does not proceed down the login module list. If it fails,
authentication continues down the login module stack.

Figure 4

JAAS Login Modules

This offers the flexibility to define
a range of authentication policies for the applications running on the
J2EE server.

Secure Transport: SSL Protocol and SAP Java Cryptography Toolkit

J2EE applications describe their requirements for secure transport in
their deployment descriptor. Here, “secure transport” means
either integrity protection or confidentiality protection (via encryption),
or both. Usually this is achieved by the SSL protocol.

The SAP J2EE Engine fully supports
these requirements. Due to export controls, the SAP Java Cryptography
Toolkit is required, and is available from the SAP Service Marketplace
(http://service.sap.com/swcenter).
This is a free download for authorized SAP customers and partners who
have an SAP Web Application Server license.

Terminology

Application Assembler Takes
a set of components and assembles them into a complete J2EE application.
Provides assembly instructions describing external dependencies
of the application that the Deployer must resolve in the deployment
process.

DeployerDeploys web applications and EJBs into an operational environment.

Deployment descriptor “Contract”
between the Application Component Provider or Assembler and the
Deployer. The Application Component Provider or Assembler is required
to specify the Application Component’s external resource requirements,
security requirements, environment parameters, and so forth in the
component’s deployment descriptor. The J2EE Product Provider
is required to provide a deployment tool that interprets the J2EE
deployment descriptors and allows the Deployer to map the Application
Component’s requirements to the capabilities of a specific
J2EE product and environment.

Principal name Identifies a
principal, an entity that can be authenticated by an authentication
protocol. The content and format of the principal name and authentication
data depends on the authentication protocol.

Future Directions of Security for the SAP J2EE Engine

A number of security aspects are not yet fully standardized in the J2EE
platform specification. The specification document itself does not include
standards for auditing, management, instance-based access control, and
user registration,7 and currently, the whole area of user and
identity management is not yet addressed by the J2EE platform API or protocol
specifications. Thus, these security requirements have to be addressed
in a non-standard way today by J2EE applications. However, these aspects
are covered by other standardization activities in OASIS, W3C, and the
SUN/Liberty alliance, for example. SAP is actively participating in these
activities in order to bring open, recognized standards to the full gamut
of security activities in J2EE-based applications in the SAP Web Application
Server.

In an upcoming issue of SAP Insider,
look for the results of these activities and for extended functionality
for the SAP Web Application Server 6.30 and its SAP J2EE Engine. Stay
tuned!

Dr.
Jürgen Schneider has been
involved in the design and implementation
of SAP security functions since 1996.
Since 1998, he has been the Development
Manager for Security in SAP’s Technology
Development. He can be reached at j.schneider@sap.com.

More from SAPinsider

As digital technologies have expanded their reach, the task of ensuring secure authentication and identity management within business processes has become more complex. Employees are no longer the only users...