Security Providers

Security providers are basically modules that plug in to the WebLogic Security Framework to provide security services to applications. After receiving a security- related request, the WebLogic Security Framework manages security processing by delegating request processing to a WebLogic, third-party, or custom security service provider through the corresponding SPI. This delegated approach to security enables WebLogic Server to route all information necessary to each kind of service provider so that applications can take full advantage of the available specialized security services.

The following sections describe the types of security providers you can use with WebLogic Server and the WebLogic security providers that are bundled, by default, with WebLogic Server.

Authentication Providers

WebLogic Server users must be authenticated whenever they request access to a protected WebLogic resource. The objective of Authentication providers is to validate the identity of these connecting users, thus establishing trust with their identities. The typical types of authentication schemes that Authentication providers use include the following:

• Username and password authentication.

• Certificate-based authentication directly with WebLogic Server.

• HTTP certificatebased authentication proxied through an external Web serverthis is called perimeter authentication .

The WebLogic Authentication provider supports delegated username/password authentication and leverages the embedded WebLogic LDAP server to store associated user and group information.

Note

WebLogic Server does provide a set of LDAP Authentication providers that can access external LDAP servers, such as Open LDAP, iPlanet, and Active Directory. However, the default security realm (myrealm) is not configured to use these LDAP servers.

The Authentication Process

During a simple authentication process, a user provides a username and password combination to WebLogic Server. This authentication request is then delegated through the WebLogic Security Framework to the PrincipleAuthenticator component of the Authentication provider, which serves as the policy enforcement point for all authentication and identity assertion requests . As illustrated in Figure 26.6, the PrincipleAuthenticator leverages three additional components to authenticate a user's identity.

Figure 26.6. The authentication process.

The LoginModule

A LoginModule , which is based on the JAAS, is responsible for authenticating all username/proof-based authentications (for example, username/password or username/secure-id) and populating a subject with the necessary principals (users and groups).

As illustrated in Figure 26.7,

Figure 26.7. The relationship between a JAAS subject and principal.

• A principal is an identity assigned to a user or group as a result of authentication.

• Subjects are considered containers for all authentication information, including principals.

As part of a successful authentication, principals are signed and stored in a subject for future use via subjects.

Note

If multiple Authentication providers are configured in a security realm, each Authentication provider's LoginModules store associated principals within the same subject.

The PrincipalValidator

Because subjects need to be propagated between one process boundary and the next , when this subject propagation occurs, it is important that the subject's principals are not tampered with. For example, LoginModule s can be executed remotely on behalf of RMI clients , and the client's application code can retain the authenticated subject between programmatic server invocations.

To provide additional security protection for principals contained in the subject, a PrincipalValidator is used to digitally sign each principal within a subject. Hence, when a caller attempts to access a principal within a subject, the PrincipalValidator is used to verify that the principal has not been altered since it was signed.

Note

WebLogic Server includes a WebLogic PrincipalValidator , which signs and verifies WebLogic Server principals onlyfor example, WebLogic Server users or groups.

The IdentityAsserter

The process of identity assertion involves establishing a client's identity by using client-supplied tokens that can exist outside the request, such as Kerberos, Security Assertion Markup Language (SAML) assertions, Checkpoint's OPSEC, and Microsoft Passport.

When used in concert with the JAAS LoginModule , an IdentityAsserter provides single sign-on (perimeter-based authentication), in which the IdentityAsserter 's function is to validate and map a token to a username. After this mapping is complete, the LoginModule can be used to convert the username to principals, populate the JAAS subject, and, therefore, tie the identity of the user together.

Note

Unlike in a simple authentication situation, the LoginModule s in this scenario do not verify proof material, such as usernames and passwords; they simply verify that the user exists.

Role Mapping Providers

In the previous version of WebLogic Server, role definitions were contained in J2EE-compliant deployment descriptors and stored in the WebLogic container. Hence, these role definitions were static and required re-editing the deployment descriptors and redeploying the application for new roles to be activated. Therefore, WebLogic administration needed to understand not only J2EE, but also XML to enforce new role definitions for users.

The objective of the Role Mapping provider is to determine the dynamic roles associated with a specific user (a JAAS subject) who has requested access to a protected WebLogic resource in the Web or EJB container. This information is supplied to the Authorization provider, which decides, based on receiving this security role information, whether the user is granted or denied access to the requested resource.

Note

A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access by using security roles and security policies. Examples of WebLogic resources include administration, application, EJB, JDBC, Java Naming and Directory Interface (JNDI), and Web services resources.

Figure 26.8 illustrates the following mechanics and internals of the Role Mapping provider:

Figure 26.8. The mechanics of the Role Mapping provider.

• A resource request comes into WebLogic container and issues getRole() on the RoleManager within the Security Service.

• The RoleManager delegates the request to the appropriate RoleMapper that has been installed and configured.

• The RoleMapper pulls role information associated with the request from a variety of sources, such as the following:

  • From the associated subject, it can extract the user and group principals formed during the authentication process.

  • From a role entitlement policy engine, it can review the rules for generating roles for the subject.

  • Via the ContextHandler , it can review the context of the request object.

  Note

  The ContextHandler interface enables an internal WebLogic container to pass additional information to a WebLogic Security Framework call. This allows a security provider to obtain context information beyond what arguments to a particular method provide.

  
  

• Based on the retrieved information, the RoleMapper issues a set of roles, if any, that the Authorization provider will use for authorization decisions.

This new approach to role assignment allows the following:

• The consumption of all security role information from deployment descriptors into the Security Service, which then makes role information available to the service providers, thus preserving existing efforts in J2EE compliancy.

  Note

  This consumption occurs at deployment time and can also be disabled to leverage the security providers completely.

  
  

• The management of role definitions and assignments without editing deployment descriptors.

• Role assignments to be based on contextfor example, real-world conditions of business.

The default WebLogic Role Mapping provider leverages the same security policy engine as the WebLogic Authorization provider and supports the dynamic deployment and undeployment of roles within the WebLogic Security Framework.

Authorization Providers

The Authorization provider controls interactions between users and WebLogic resources based on the user's identity (subject). In the previous version of WebLogic Server, all decisions on granting or denying access to container objects were held and made in the WebLogic container (Web or EJB). Access decisions to external container resources, such as JNDI, JMS, and JDBC, were made in other parts of WebLogic Server via access control lists (ACLs) in the respective realm.

Note

ACLs are Java classes that were used to control access to computer resources. Each entry in the ACL contained a set of permissions associated with a particular principal that represented an individual user or a group of users.

In this release of WebLogic Server 7, all resource object authorization decisions are delegated to the security service from the container, which provides a unified role-based authorization scheme for all WebLogic resources.

Figure 26.9 illustrates the following mechanics and internals of the Authorization provider:

Figure 26.9. The mechanics of the Authorization provider.

• Whenever a WebLogic container needs to make an authorization decision, the container delegates the authorization request to the Authorization Manager of the Security Service via isAccessAllowed() .

  All authorization requests are managed by the Authorization Manager component of the Authorization provider, which serves as a policy enforcement point for all authorization decisions.

  Note

  The information passed to the Authorization Manager includes who the caller is, what roles are assigned to the caller, and what target resource the caller is requesting access to.

  
  

• The Authorization Manager then calls the RoleMapper to retrieve what roles are assigned to the caller.

• This role information is then passed to the Access Decisions. Similar to LoginModules for Authentication providers, an Access Decision is an Authorization provider component used to determine whether a subject is entitled to perform an operation on a WebLogic resource. Similar to a RoleMapper , an Access Decision can do the following:

  • Look into the subject (who the user is) and what groups the user belongs to.

  • Look into the initial request via the ContextHandler .

  • Retrieve rules for making decisions from the authorization policies database.

  • Given this information, the Access Decision responds with a result of PERMIT, DENY, or ABSTAIN.

• If more than one Authorization provider is configured in a security realm, the Adjudication component is then used to resolve any authorization conflicts. An Adjudication provider can also specify what should be done when an answer of ABSTAIN is returned from a single Authorization provider's Access Decision.

The default security realm for WebLogic Server includes a WebLogic Authorization provider that uses a policy-based authorization engine to return Access Decisions. It also includes a WebLogic Adjudication provider, but because the default security realm has only one Authorization provider, only one Access Decision is produced, so the WebLogic Adjudication provider is not used.

Note

Along with the WebLogic Authorization provider, the WebLogic Authentication provider replaces the functionality of the File realm that was available in 6.x releases of WebLogic Server.

Auditing Provider

In the WebLogic Server security architecture, an Auditing provider is used to provide auditing services. As illustrated in Figure 26.10, the Auditor is the interface of the WebLogic Security Framework that calls into each Auditing provider (audit channels) and enables audit event recording. For example, the WebLogic Security Framework can call an Auditor before and after security operations (such as authentication or authorization) have been performed.

Figure 26.10. The Auditing provider.

The decision to audit an event based on specific audit criteria, including audit severity levels, are made by one or more audit channels. All audited events report to one or more configured audit channels. These audit channels can write audit information to output repositories, such as an LDAP back end, a database, or a simple text file.

WebLogic Server comes bundled with a default Auditing provider that administrators can configure to detect and log authentication attempts, access attempts, and other significant security events. Because the WebLogic Security Framework supports simultaneous use of multiple audit channels, integrating more sophisticated auditing schemes with third-party auditing tools is easy.

Credential Mapping Provider

To provide seamless interoperability, WebLogic applications that interact with external Enterprise Information Systems (EISs) with built-in security systems, such as back-end databases, packaged applications, or legacy mainframe systems, need to associate a WebLogic Server user to the credentials required to access that EIS.

The Credential Mapping provider's role is to provide these credential mapping services and, therefore, bring new types of credentials into the WebLogic Server environment. These credential maps basically allow JAAS subjects that have already been authenticated to log in to a remote system.

In general, the credential mapping process (shown in Figure 26.11) is initiated as follows :

Figure 26.11. The Credential Mapping provider.

1. An application component, such as Resource Adapters, JSP, servlets, or EJBs, makes a call through its container to the Credential Manager of the WebLogic Security Framework. The information passed to the Credential Manager includes the JAAS subject making the request, the WebLogic Server resource identifier, and the type of credentials required to access the external system.

2. The Credential Manager sends the application component's request for credentials to a configured Credential Mapping provider that handles the type of credentials requested by the application component.

3. The Credential Mapping provider consults the legacy system's database to obtain a set of credentials that match those requested by the application component.

4. The Credential Mapping provider returns the credentials to the Credential Manager.

5. The WebLogic Security Framework passes the credentials back to the requesting application component through the resource container.

6. The application component uses the credentials to access the external system.

A Credential Mapping provider can handle several different types of credentials, such as username/password combinations, Kerberos tickets, and public key certificates, which can be set through the Resource Adapter's deployment descriptor (the weblogic-ra.xml file) or the Administration Console.

If you decide to specify credential mapping via the weblogic-ra.xml file, the mapping is specified in the <security-principal-map> element, which provides the association between credentials used to log in to the EIS and credentials used to authenticate to WebLogic resources. Listing 26.1 shows a sample credential map between raruser (a WebLogic user) and a ResourceID (an EIS remote user) in the weblogic-ra.xml file.

Listing 26.1 A Sample Credential Map

 <security-principal-map>       <map-entry>         <initiating-principal>raruser</initiating-principal>         <resource-principal>           <resource-username>ResouceID</resource-username>           <resource-password>ResourcePW</resource-password>         </resource-principal>       </map-entry>     </security-principal-map> <initiating-principal>raruser</initiating-principal>         <initiating-principal>javajoe</initiating-principal>         -<resource-principal>             <resource-username>scott</resource-username>             <resource-password>tiger</resource-password>         </resource-principal> 

However, this deployment descriptor technique for creating credential maps is deprecated in this release of WebLogic Server. Instead, you should use the Administration Console to create credential maps, which are persisted to the WebLogic LDAP server. To configure WebLogic Server Resource Adapter to authenticate to an EIS using the Administration Console, follow these steps:

1. In the left pane of the Administration Console, expand the Connectors node.

2. Right-click your Resource Adapter and click the CredMaps link. The Cred Maps tab appears, which displays all credential maps defined in the configured Credential Mapper.

3. Click the Configure a New Cred Map link.

4. Enter a user's name and password in the remote application.

5. Click Apply to store the information in the embedded LDAP server.

6. Right-click your Resource Adapter and click the RoleMaps link.

7. Click the Configure a New Role Map link.

8. In the displayed Role Map tab, enter the following:

   • The WebLogic Server username for the remote user.

   • The username you defined when creating the credential map.

9. Click Apply.

The default (active) security realm for WebLogic Server includes a WebLogic Credential Mapping provider that can be used to map a WebLogic user/group to the username-password credentials required to access an EIS. During application deployment, WebLogic Server reads the credential mapping from the weblogic-ra.xml deployment descriptor and populates the default (WebLogic) Credential Mapping provider. At this point, you can manage credential mappings by using the Administration Console. WebLogic Server's embedded LDAP directory stores the encrypted username-password pair for every valid combination of principal and back-end system. However, credential mapping changes made via the Administration Console do not get persisted to deployment descriptors.

Keystore Providers

One of the most crucial concerns in any business transaction is the identity of entities in a transaction. As transactions shift from being paper based to electronic messages and documents, confidence in traditional (human) trust factors must also transition to electronic security measures to authenticate and guarantee confidentiality, integrity, and non- repudiation between transactional entities. WebLogic Server implements this electronic trust mechanism through the use of the PKI cryptography technique via SSL.

Note

Cryptography is fundamentally based on keys used to encrypt and decrypt data with a secret private key (symmetric) or public key (asymmetric).

In public key cryptography, a public and private key are created simultaneously for WebLogic Server by using the same algorithm from a Certificate Authority (CA), such as VeriSign. The public key is embedded into a digital certificate with additional information describing the owner of the public key, such as name, street address, and e-mail address. The data embedded in a digital certificate is also digitally signed with the CA's digital certificate.

Note

A key is typically a variable value applied by using an algorithm on a string of unencrypted text to produce encrypted text or to decrypt encrypted text. The length of the key is a factor in considering how difficult it will be to decrypt text in a message.

Both keys are related so that data encrypted with the public key can be decrypted only by using the corresponding private key. However, it's not computationally feasible to derive the private key from knowledge of the public key. The private key is carefully protected so that only the owner can decrypt messages. Therefore, the private key is never shared with anyone or sent across the Internet and is supplied only to the requesting party (WebLogic Server). The public key is made publicly available (as part of a digital certificate) in a directory that all connecting entities can access.

After you have obtained private keys, digital certificates, and trusted CAs, you need to store them so that WebLogic Server can use them to authenticate SSL connections. Digital certificates can be stored only in a file in the WebLogic domain directory. However, private keys and trusted certificate authorities can be stored in a file in the WebLogic domain directory or in a keystore.

For a description of how to configure SSL for WebLogic Server, see "Configuring the Network Resources for a WebLogic Domain," p. 798 , in Chapter 24, "Administering and Monitoring Your WebLogic Domain."

A keystore is a mechanism designed to create and manage private keys and trusted CA certificates (public keys). To locate a keystore and make it available to WebLogic Server, you need a Keystore provider.

The WebLogic Keystore provider uses the JDK-bundled Java Keystore (JKS) provider, which implements the keystore as a file (one per machine) and protects each private key and keystore with an individual unique password.

The following utilities bundled with WebLogic Server can be used to create a keystore and to load private keys and trusted CA certificates into the keystore:

• The WebLogic ImportPrivateKey utility, which enables you to take private key files and load them into a keystore. This utility creates a keystore if one does not exist.

• Sun Microsystem's keytool utility, which generates a private key/digital certificate pair and then imports the signed private key into the keystore.

Note

WebLogic Server retrieves only private keys from a keystore file, not certificates.

You can create one keystore for both private keys and trusted CA certificates or create two keystoresone for private keys and one for trusted CA certificates. BEA recommends creating two keystores.

By default, WebLogic Server looks for a private key keystore named wlDefaultKeyStore.jks in your WebLogic directory. The keystore for trusted CA certificates can use the demonstration trusted CAs (WL_HOME\server\lib\cacerts) or a trusted CA available from Sun's JDK located at \jre\lib\security\cacerts.

Note

The WL_HOME\server\lib\cacerts file should be used for demonstration or testing purposes, not in a production environment. This file contains trusted certificate authorities in \jre\lib\security\cacerts .

Configuring a WebLogic Keystore provider is an optional step. For example, if private keys and digital certificates are stored in files, you do not need to configure the WebLogic Keystore provider. You can also use a JKS keystore without using a WebLogic Keystore provider by specifying the location in the WebLogic Server startup script.

Realm Adapter Providers

If you are upgrading from WebLogic Server 6.x to WebLogic Server 7, at startup WebLogic Server 7 runs in Compatibility security with the Realm Adapter provider. The Realm Adapter provider provides backward compatibility with 6.x WebLogic security realms by mapping the realm API ( weblogic.security.acl ) used in WebLogic Server 6.x to the APIs used in WebLogic Server 7.