6.9 Security

An enterprise has a critical dependency on its information systems for its business activities. Loss or inaccuracy of information or unauthorized access to an enterprise information system can be extremely costly. So, enterprises require that the security of their enterprise information systems should never be compromised. Applications need to provide access to enterprise information systems without creating security threats to these valuable resources.

Enterprise applications should clearly establish the requirements and architecture for secure enterprise information system integration environment. For example, an application should require only the level of protection needed by the enterprise: reducing the level of protection for less sensitive information or where the system is less vulnerable to threats. The cost of implementing, administering, and running a secure system should also be weighed against the security needs of an application. This trade-off, based on the security benefits and cost, is difficult to make for an enterprise application. However, this trade-off is important to make for the security architecture for enterprise information system integration.

6.9.1 Security Architecture

A security architecture for enterprise information system integration should fulfill a variety of requirements to ensure seamless support for distributed applications:

• Support a consistent end-to-end security architecture across Web, EJB, and enterprise information system tiers for applications based on the J2EE platform.
• Fit with the existing security environment and infrastructure supported by an enterprise information system.
• Support authentication and authorization of users who are accessing enterprise information systems.
• Be transparent to application components. This includes support for enabling end-users to log on only once to the enterprise environment and access multiple enterprise information systems.
• Enable applications to be portable across security environments that enforce different security policies and support different mechanisms.

The relative importance of achieving these goals depends on the cost/benefit trade-off for the security requirements. The more an architecture takes care of these security requirements for the application, the easier the application development effort.

6.9.2 Application Programming Model

While developing and deploying application components, an Application Component Provider follows the security model defined for the corresponding J2EE component--EJB, JSP, or servlet. We recommend the following application programming model for all types of components:

• An Application Component Provider should specify security requirements for an application declaratively in the deployment descriptor. The security requirements include security roles, method permissions, and authentication approach for enterprise information system signon.
• A security-aware Application Component Provider can use a simple programmatic interface to manage security at an application level. This programmatic interface allows the Application Component Provider to make access control decisions based on the security context (principal, role) associated with the caller of a method and to do programmatic signon to an enterprise information system (described in Section 6.9.3.2).
• Other development roles--J2EE Server Provider, Deployer, System Administrator--should satisfy an application's security requirements (as specified in the deployment descriptor) in the operational environment.

6.9.3 Resource Signon

From a security perspective, the mechanism for getting a connection to a resource is referred to as resource signon. A user requests a connection to be established under its security context. This security context includes various attributes, such as role, access privileges, and authorization level for the user. All application-level invocations to the database using this connection are then provided through the security context associated with the connection.

If the resource signon mechanism involves authentication of the user, then an Application Component Provider has the following two choices:

• Allow the Deployer to set up the resource signon information. For example, the Deployer sets the user name and password for establishing the database connection. The container then takes the responsibility of managing the database signon.
• Implement sign on to the database from the component code by providing explicit security information for the user requesting the connection.

We recommend that a component let the container manage resource signon. This takes the burden of managing security information for the signon off of the Application Component Provider. It also enables J2EE servers to provide additional useful security services, such as single signon across multiple enterprise information systems and principal mapping across security domains.

Container-managed resource signon enables the Application Component Provider to avoid hard-coding security details in the component code. A component with hard-coded security logic is less portable because it is difficult to deploy on containers with different security policies and mechanisms. The following sections illustrate how to sign on using both approaches.

6.9.3.1 Container-Managed Signon

In this example, the Application Component Provider delegates the responsibility of setting up and managing resource signon to the container. The Deployer sets up the resource signon so that the user account for connecting to the database is always eStoreUser. The Deployer also configures the user identification and authentication information--user name and password--that is needed to authenticate eStoreUser to the database.

As shown in Code Example 6.2, the component code invokes the connection request method on the javax.sql.DataSource with no security parameters. The component instance relies on the container to do the signon to the database using the security information configured by the Deployer. Code Example 6.3 contains the corresponding connection factory reference deployment descriptor entry, where the res-auth element specifies that signon is performed by the container.

// Obtain the initial JNDI context
Context initctx = new InitialContext();
// Perform JNDI lookup to obtain connection factory
javax.sql.DataSource ds = (javax.sql.DataSource)initctx.lookup(
				"java:comp/env/jdbc/MyDatabase");

// Invoke factory to obtain a connection. The security
// information is not given, and therefore it will be
// configured by the Deployer.
java.sql.Connection cx = ds.getConnection();

<resource-ref>
	<description>description</description>
	<res-ref-name>jdbc/MyDatabase</res-ref-name>
	<res-type>javax.sql.DataSource</res-type>
	<res-auth>Container</res-auth>
</resource-ref>

6.9.3.2 Application-Managed Signon

In this example, the Application Component Provider performs a programmatic signon to the database. The component passes explicit security information (user name, password) to the connection request method of the javax.sql.DataSource.

// Obtain the initial JNDI context
Context initctx = new InitialContext();

// Perform JNDI lookup to obtain factory
javax.sql.DataSource ds = (javax.sql.DataSource)initctx.lookup(
				"java:comp/env/jdbc/MyDatabase");

// Get connection passing in the security information
java.sql.Connection cx = ds.getConnection("eStoreUser", 
					"password"); 

6.9.3.3 Authorization Model

An Application Component Provider relies on the container and enterprise information system for authorizing access to enterprise information system data and functions. The Application Component Provider specifies security requirements for application components declaratively in a deployment descriptor. A set of security roles and method permissions can be used to authorize access to methods on a component. For example, an Application Component Provider declaratively specifies the PurchaseManager role as the only security role that is granted permission to call the purchase method on a PurchaseOrder enterprise bean. The purchase method in turn drives its execution through an ERP Logistics application by issuing a purchase requisition. So in effect, this application has authorized only end-users with the PurchaseManager role to do a purchase requisition. This is the recommended authorization model.

An Application Component Provider can also programmatically control access to enterprise information system data and functions based on the principal or role associated with the client who initiated the operation. For example, the EJB specification allows component code to invoke getCallerPrincipal and isCallerInRole to get the caller's security context. An Application Component Provider can use these two methods to perform security checks that cannot be expressed declaratively in the deployment descriptor.

An application can also rely on an enterprise information system to do access control based on the security context under which a connection to the enterprise information system has been established. For example, if all users of an application connect to the database as dbUser, then a database administrator can set explicit permissions for dbUser in the database security domain. The database administrator can deny dbUser permission to execute certain stored procedures or to access certain tables.