Security

The following sections discuss WebLogic J2EE Connector Architecture security:

• Container-Managed and Application-Managed Sign-on
• Password Credential Mapping Mechanism
• Using Container-Managed Sign-On
• Default Resource Principal
• Security Policy Processing

 

---

Container-Managed and Application-Managed Sign-on

As specified in the J2EE Connector Specification, Version 1.0 Final Release, the WebLogic J2EE Connector Architecture implementation supports both container-managed and application-managed sign-on.

At runtime, the Weblogic J2EE Connector Architecture implementation determines— based upon the specified information in the invoking client component's deployment descriptor—the chosen sign-on mechanism. If the Weblogic Server J2EE Connector Architecture implementation is unable to determine what sign-on mechanism is being requested by the client component—typically due to an improper JNDI lookup of the resource adapter Connection Factory—the Connector Architecture attempts container-managed sign-on.

Note: Note that even in this case, if the client component has specified explicit security information, this information is also presented on the call to obtain the connection.

For related information, see Obtaining the ConnectionFactory (Client-JNDI Interaction) in Client Considerations.

Application-Managed Sign-on

With application-managed sign-on, the client component provides the necessary security information (typically a username and password) when making the call to obtain a connection to an Enterprise Information System (EIS). In this scenario, the application server provides no additional security processing other than to pass this information along on the request for the connection. The provided resource adapter uses the client component provided security information to perform the EIS sign-on in a resource adapter implementation specific manner.

Container-Managed Sign-on

With container-managed sign-on, the client component does not present any security information, and the container must determine the necessary sign-on information and provide this information to the resource adapter when making a call to request a connection. In all container-managed sign-on scenarios, the container must determine an appropriate Resource Principal and provide this Resource Principal information to the resource adapter in the form of a Java Authentication and Authorization Service (JAAS) Subject.

 

---

Password Credential Mapping Mechanism

The J2EE Connector specification, Version 1.0 Final Release requires storage of credentials in a javax.security.auth.Subject; the credentials are passed to either the createManagedConnection() or matchManagedConnection() methods of the ManagedConnectionFactory object.

To comply with this, the WebLogic Server J2EE Connector Architecture builds the Subject and stores the credentials by performing the following steps:

1. Instantiate a weblogic.security.Service.EISResource object as follows:

   EISResource(java.lang.String applicationName, java.lang.String moduleName, java.lang.String eisName)

2. Obtain the Initiating Principal for the connection request.
3. Obtain the Credentials for that Initiating Principal as follows:

   weblogic.security.Service.PrincipalAuthenticator(String initiatingPrincipal, weblogic.security.Service.Resource eisResource)

4. Instantiate a javax.security.auth.Subject.
5. Add the Credentials to the private set in the Subject as follows:

   Subject.getPrivateCredentials().add(Credential)

Authentication Mechanisms

WebLogic Server users must be authenticated whenever they request access to a protected WebLogic Server resource. For this reason, each user is required to provide a credential (a username/password pair or a digital certificate) to WebLogic Server. The following types of authentication mechanisms are supported by WebLogic Server:

• Password authentication—a user ID and password are requested from the user and sent to WebLogic Server in clear text. WebLogic Server checks the information and if it is trustworthy, grants access to the protected resource.

The SSL (or HTTPS) protocol can be used to provide an additional level of security to password authentication. Because the SSL protocol encrypts the data transferred between the client and WebLogic Server, the user ID and password of the user do not flow in the clear. Therefore, WebLogic Server can authenticate the user without compromising the confidentiality of the user's ID and password.

• JAAS authentication—JAAS is a standard extension to the security in the Java Software Development Kit version 1.3. JAAS provides the ability to enforce access controls based on user identity. JAAS is provided in WebLogic Server as an alternative to the JNDI authentication mechanism.

WebLogic Server uses the authentication portion of the standard JAAS. The JAAS LoginContext provides support for the ordered execution of all configured authentication provider LoginModule instances and is responsible for the management of the completion status of each configured provider.

Note: JAAS is the preferred method of authentication, however, the WebLogic-supplied LoginModule only supports username and password authentication. Thus, for client certificate authentication (also referred to as two-way SSL authentication), you should use JNDI. To use JAAS for client authentication, you must write a custom LoginModule that does certificate authentication.

For more information, see the following sections in Managing WebLogic Security:

• "Configuring the SSL Protocol"
• "Writing a Client Application using JAAS Authentication"

Defining Users and Groups

The following sections discuss the definition of users and groups. For more information on how to create users and groups, see Managing WebLogic Security

Users

Users are entities that can be authenticated in a WebLogic Server security realm. A user can be a person or a software entity, such as a Java client. Each user is given a unique identity within a WebLogic Server security realm. As a system administrator you must guarantee that no two users in the same security realm are identical.

Defining users in a security realm involves specifying a unique name and password for each user that will access resources in the WebLogic Server security realm in the users window of the Administration Console.

Three special users are provided for use by resource adapters. They are as follows:

• wls_ra_initial—If you define a mapping for this user, the specified credentials are used for the initial connections created when starting the connection pool for this resource adapter. The InitialCapacity parameter on the pool specifies the number of initial connections. If you do not define a mapping for this user the default mapping wls_ra_default (if provided) is used. Otherwise, no credentials are provided for the initial connections.
• wls_ra_anonymous—If you define a mapping for this user, the specified credentials are used when no user is authenticated for the connection request on the resource adapter.
• wls_ra_default—If you define a mapping for this user, the specified credentials are used when no other mapping applies for the current user or when no anonymous mapping is provided in the case where there is no authenticated user.

Groups

A group represents a set of users who usually have something in common, such as working in the same department in a company. Groups are a means of managing a number of users in an efficient manner. You grant users and groups security roles. These security roles are used to create a security policy, which restricts access to server resources. For more information, see "Setting Protections for WebLogic Resources."

 

---

Using Container-Managed Sign-On

To use container-managed sign-on, WebLogic Server must identify a resource principal and then request the connection on behalf of the resource principal. In order to make this identification, WebLogic Server looks for a Security Principal Mapping specified with the security-principal-map element in the weblogic-ra.xml deployment descriptor file.

A security-principal-map element defines the relationship of initiating-principal to a resource-principal.

Each security-principal-map element provides a mechanism to define appropriate resource principal values for resource adapter and EIS sign-on processing. The security-principal-map elements allow you to specify a defined set of initiating principals and the corresponding resource principal's username and password to be used when allocating managed connections and connection handles.

 

---

Default Resource Principal

A default resource principal can be defined for the connection factory in the security-principal-map element. If you specify an initiating-principal value of '*' and a corresponding resource-principal value, the defined resource-principal is utilized whenever the current identity is not matched elsewhere in the map.

This is an optional element, however. You must specify it in some form if container-managed sign-on is supported by the resource adapter and used by any client.

In addition, the deployment-time population of the Connection Pool with Managed Connections is attempted using the defined 'default' resource principal if one is specified.

 

---

Security Policy Processing

The J2EE Connector Specification, Version 1.0 Final Release defines default security policies for any resource adapters running in an application server. It also defines a way for a resource adapter to provide its own specific security policies overriding the default.

In compliance with this specification, WebLogic Server dynamically modifies the runtime environment for resource adapters. If the resource adapter has not defined specific security policies, WebLogic Server overrides the runtime environment for the resource adapter with the default security policies specified in the J2EE Connector Architecture Specification. If the resource adapter has defined specific security policies, WebLogic Server first overrides the runtime environment for the resource adapter first with a combination of the default security policies for resource adapters and the specific policies defined for the resource adapter. Resource adapters define specific security policies using the security-permission-spec element in the ra.xml deployment descriptor file.

For more information on security policy processing requirements, see the "Security Permissions" section of the "Runtime Environment" chapter in the J2EE Connector Specification, Version 1.0 Final Release (http://java.sun.com/j2ee/download.html#connectorspec).