GRC
HR
SCM
CRM
BI


Article

 

J2EE Security Architecture Implementation with the SAP J2EE Engine

by Dr. Jurgen Schneider | SAPinsider

January 1, 2003

by Dr. Jurgen Schneider, SAP AG SAPinsider - 2003 (Volume 4), January (Issue 1)
 

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:

  • Declarative security, which uses deployment descriptors outside the application to express security requirements

  • 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:

  • Whether user data should be transferred with integrity and/or confidentiality protection (user-data-constraint, transport-guarantee)

  • The authentication method to be used (login-config)

  • The security roles required to access web resources or call EJB methods (auth-constraint)

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.

Figure 2 Responsibilities for Setting Authorizations in J2EE-Compliant Applications

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:

  • HTTP Basic Authentication, with or without Secure Sockets Layer (SSL)
  • SSL Mutual Authentication
  • Form-Based Login

HTTP Basic Authentication and Form-Based Login use a username/password combination for authenticating users. Mutual authentication over SSL uses X.509 digital certificates for user authentication.

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.

Application Component Provider For example, HTML document designers, document programmers, and enterprise bean developers using tools to produce J2EE applications and components.

Deployer Deploys 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!


1Java 2 Platform, Enterprise Edition Specification, v1.3, http://java.sun.com/j2ee/docs.html.

2See “Terminology,” at the end of this article.

3See “Terminology.”

4SAP Online Documentation available at http://help.sap.com.

5Java Authentication and Authorization Service (JAAS) 1.0, http://java.sun.com/products/jaas.

6The runtime environment of the J2EE applications creates the login context object.

7Java 2 Platform, Enterprise Edition Specification, v1.3, http://java.sun.com/j2ee/docs.html.


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.

 

 


An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ