Security Concerns
The security contract ensures secure access to an EIS from application components. The contract itself incorporates the Java Authentication and Authorization Service into the connection management interfaces used by the resource adapter.
Security-Related Terms
Before going over the mechanisms of authentication available with WebLogic, we first need to define a number of security-related terms that are used extensively in the security contract. Authentication mechanisms make use of the following elements:
Principals Credentials Subjects
Principal
A principal gives an entity an identity for the purposes of secure authentication in the enterprise. The methods and vehicles providing authentication can vary throughout the enterprise, but the principal itself can remain the same. An initiating principal is a security principal used by a client application interacting with a particular EIS. Through a generic credential interface, the embedded credentials of a principal can be retrieved and then used to authenticate the principal. For example, the resource adapter uses the credentials passed to it from the application server during the process of authentication. Security attributes are associated with a security principal. They provide information about the authentication and authorization mechanisms containing permissions and credentials.
Credential
A credential is provided by a subject and contains a reference to the security-related information used to authenticate a principal. Credentials are acquired during the authentication process or through what is called a principal delegation, where a principal grants another principal rights to use its credential. A Password credential class is used to wrap the username and password to be passed from the app server to the resource adapter. It has the get and set assessor methods to retrieve the username and password as well as getManagedConnectionFactory and setManagedConnectionFactory methods to specify the connection factory instance for which a username and password have been set up by the application server.
Subject
WebLogic Server bundles up security information into what is known as a subject. The subject contains the complete set of information required to describe an entity. It includes embedded principal and credential data that is passed by the WebLogic Server to the resource adapter for the purposes of authentication and authorization.
Before users are granted access to WebLogic Server–protected resources, they must provide a valid form of identification. Information identifying a particular user is passed to WebLogic Server in the form of a credential. Credentials may contain either a username and password or a digital certificate, which in turn are processed by one of the two types of authentication mechanisms supported by WebLogic Server.
Password Credential Mapping Mechanisms
The J2EE Connector Specification, Version 1.0 Final Release defines two types of credentials that resource adapters can use during the process of authentication:
Generic credentials Password credentials
When using generic credentials, the GenericCredential interface defines how to access the security credentials of a principal. Through this interface, the resource adapter is able to retrieve the credentials passed from the application server.
When using password credentials, the PasswordCredential class is used to encapsulate a username and password, which is passed from the application server to the resource adapter. The class provides get methods for retrieving the values of the username and password. It also provides a getManagedConnectionFactory and a setManagedConnectionFactory that can be used to get or set the managed connection factory instance that WebLogic sets up for the username and password.
The security policy used by a resource adapter in accordance with the specification can be provided by the WebLogic Server runtime environment housing the resource adapter or within the resource adapter itself. In the latter scenario, WebLogic Server provides a standard method for deployed resource adapters to plug their own authorization and authentication mechanism into WebLogic's own storage mechanism.
WebLogic Authentication Mechanisms
Applications typically have to authenticate with an EIS before they can successfully connect and access the resources of the EIS. The J2EE Connector Architecture defines two types of authentication mechanisms for this purpose: password authentication and certificate authentication.
Password Authentication
With password authentication, the principal identification information of username and password are sent to WebLogic Server in clear text format. If so desired, this information can be encrypted through SSL or HTTPS protocol.
Certificate Authentication
With certificate authentication, an SSL or HTTPS client requests connections to WebLogic Server by presenting a digital certificate. In return, WebLogic Server presents its own digital certificate to the client. The client then verifies it and an SSL connection is established. The CertAuthenticator class is used to determine which WebLogic Server user owns the certificate. It does so by examining the provided digital certificate and then using this information to authenticate the user from the WebLogic Server security realm.
A mechanism known as mutual authentication is available as well. With mutual authentication, WebLogic Server requires authentication for itself and from the requesting client. Through this mechanism, access can be restricted to trusted clients who present a digital certificate issued by a trusted certificate authority.
Sign-on Mechanisms
WebLogic's implementation of the Java Connector Architecture supports both authentication schemes defined in the specification. They are
When a J2EE component is deployed, a reference element describing the type of authentication requested by the component lies within its deployment descriptor. Specifically, the resource-ref element declares the resources used by the component and the res-auth sub-element defines the chosen authentication method: container managed or application managed. WebLogic defaults to container-managed sign-on in the event it cannot determine the security mechanism chosen.
Container-Managed Sign-on
J2EE components often take advantage of different security providers and operate in different protection domains than the EIS systems they access. Under such conditions, the J2EE container in which the client resides can be configured to manage the authentication process on behalf of the client. This form of authentication is known as container-managed resource manager sign-on.
In the case of container-managed sign-on, the container provides security information to the resource adapter in the form of a resource principal, which is provided to the resource adapter wrapped as a JAAS subject. A resource principal is a security principal that references a security context in a session with an EIS. All sign-on information is handled by the container on behalf of the component. Here is a sample credential mapping:
<security-principal-map>
-<map-entry>
<initiating-principal>rauser</initiating-principal>
<initiating-principal>unleashedclient</initiating-principal>
-<resource-principal>
<resource-username>scott</resource-username>
<resource-password>tiger</resource-password>
</resource-principal>
</map-entry>
Application-Managed Sign-on
Under different circumstances, it might be important for a component to manage the process of authentication more directly. The Java Connector Architecture provides application-managed resource manager sign-on in these cases. In this scenario, the client application itself is able to manipulate the authentication details of the sign-on process. The WebLogic application server passes connection requests directly to the resource adapter in their unaltered state. The resource adapter then handles the call using the client-provided authentication information for sign-on to the EIS. In this scenario, security information is passed through the getConnection method of the connection factory encapsulated in a ConnectionRequestInfo object. A typical example of such an object is
public class customConnectionRequestInfo implements ConnectionRequestInfo {
private String username;
private String password;
...
}
Note that ConnectionRequestInfo is an empty interface used to pass the object references around the connector's framework.
| 
