Understanding WebLogic Security
Security Realms
This section covers the following topics:
Introduction to Security Realms
A security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies (see Figure 4-1). A user must be defined in a security realm in order to access any WebLogic resources belonging to that realm. When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular WebLogic resource. Figure 4-1 WebLogic Server Security Realm
Users
Users are entities that can be authenticated in a security realm, such as myrealm (see Figure 4-1). A user can be a person, such as application end user, or a software entity, such as a client application, or other instances of WebLogic Server. As a result of authentication, a user is assigned an identity, or principal. Each user is given a unique identity within the security realm. Users may be placed into groups that are associated with security roles, or be directly associated with security roles.
When users want to access WebLogic Server, they present proof material (for example, a password or a digital certificate) typically through a JAAS LoginModule to the Authentication provider configured in the security realm. If WebLogic Server can verify the identity of the user based on that username and credential, WebLogic Server associates the principal assigned to the user with a thread that executes code on behalf of the user. Before the thread begins executing code, however, WebLogic Server checks the security policy of the WebLogic resource and the principal (that the user has been assigned) to make sure that the user has the required permissions to continue.
When you use the WebLogic Authentication provider and you define a user, you also define a password for that user. WebLogic Server hashes all passwords. Subsequently, when WebLogic Server receives a client request, the password presented by the client is hashed and WebLogic Server compares it to the already hashed password to see if it matches.
All user names and groups must be unique within a security realm.
Groups
Groups are logically ordered sets of users (see Figure 4-1). Usually, group members have something in common. For example, a company may separate its sales staff into two groups, Sales Representatives and Sales Managers. Companies may do this because they want their sales personnel to have different levels of access to WebLogic resources, depending on their job functions.
Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for 50 users at one time by placing the users in a group, assigning the group to a security role, and then associating the security role with a WebLogic resource via a security policy.
All user names and groups must be unique within a security realm.
Security Roles
A security role is a privilege granted to users or groups based on specific conditions (see Figure 4-1). Like groups, security roles allow you to restrict access to WebLogic resources for several users at once. However, unlike groups, security roles:
- Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day.
- Can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain).
Granting a security role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is “in” the security role. Multiple users or groups can be granted a single security role.
In WebLogic Server 6.x, security roles applied to Web applications and Enterprise JavaBeans (EJBs) only. In this release of WebLogic Server, the use of security roles is expanded to include all of the defined WebLogic resources.
Security Policies
A security policy is an association between a WebLogic resource and one or more users, groups, or security roles. Security policies protect the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you create a security policy for it. A policy condition is a condition under which a security policy will be created. WebLogic Server provides a set of default policy conditions. WebLogic Server includes policy conditions that access the HTTP Servlet Request and Session attributes and EJB method parameters. Date and Time policy conditions are included in the Policy Editor.
Security policies replace the access control lists (ACLs) that were used to protect WebLogic resources in WebLogic Server 6.x.
Security Providers
Security providers are modules that provide security services to applications to protect WebLogic resources (see Figure 4-1). You can use the security providers that are provided as part of the WebLogic Server product, purchase custom security providers from third-party security vendors, or develop your own custom security providers. For information on how to develop custom security providers, see Developing security providers for WebLogic Server.
The following topics are discussed in this section.
Security Provider Databases
The following sections explain what a security provider database is and describe how security realms affect the use of security provider databases:
- What Is a Security Provider Database?
- Security Realms and Security Provider Databases
- Embedded LDAP Server
- RDBMS Security Store
What Is a Security Provider Database?
A security provider database contains the users, groups, security roles, security policies, and credentials used by some types of security providers to provide security services (see Figure 4-1). For example: an Authentication provider requires information about users and groups; an Authorization provider requires information about security policies; a Role Mapping provider requires information about security roles, and a credential mapping provider requires information about credentials to be used to remote applications. These security providers need this information to be available in a database in order to function properly.
The security provider database can be the embedded LDAP server (as used by the WebLogic security providers), a properties file (as used by the sample custom security providers, available on the Web), or a production-quality, customer-supplied database that you may already be using.
The sample custom security providers are available at http://www.oracle.com/technology/community/welcome-bea/index.html on the Oracle Technology Network (OTN).
The security provider database should be initialized the first time security providers are used. (That is, before the security realm containing the security providers is set as the default (active) security realm.) This initialization can be done:
- When a WebLogic Server instance boots.
- When a call is made to one of the security provider's MBeans.
At minimum, the security provider database is initialized with the default groups, security roles, security policies provided by WebLogic Server. For more information, see security providers and WebLogic Resources in Developing security providers for WebLogic Server.
Security Realms and Security Provider Databases
If you have multiple security providers of the same type configured in the same security realm, these security providers may use the same security provider database. This behavior holds true for all of the WebLogic security providers and the sample security providers that are available at the http://www.oracle.com/technology/community/welcome-bea/index.html on the Oracle Technology Network (OTN).
For example, if you configure two WebLogic Authentication providers in the default security realm (called myrealm), both WebLogic Authentication providers will use the same location in the embedded LDAP server as their security provider database, and thus, will use the same users and groups. Furthermore, if you or an administrator add a user or group to one of the WebLogic Authentication providers, you will see that user or group appear for the other WebLogic Authentication provider as well.
If you have two WebLogic security providers (or two sample security providers) of the same type configured in two different security realms, each will use its own security provider database. Only one security realm can be active at a time.
Custom security providers that you develop (or the custom security providers that you obtain from third-party security vendors) can be designed so that each instance of the security provider uses its own database or so that all instances of the security provider in a security realm share the same database. This is a design decision that you need to make based on your existing systems and security requirements. For more information about design decisions that affect security providers, see Design Considerations in Developing security providers for WebLogic Server.
Embedded LDAP Server
WebLogic Server uses its embedded LDAP server as the database that stores user, group, security roles, and security policies for the WebLogic security providers. The embedded LDAP server is a complete LDAP server that is production quality for reasonably small environments (10,000 or fewer users). For applications that need to scale above this recommendation, the embedded LDAP server can serve as an excellent development, integration and testing environment for future export to an external LDAP server for production deployment. The embedded LDAP server supports the following access and storage functions:
- Access and modification of entries in the LDAP server
- Use of an LDAP browser to import and export security data into and from the LDAP server.
- Read and write access by the WebLogic security providers.
WebLogic Server does not support adding attributes to the embedded LDAP server.
Table 4-1 shows how each of the WebLogic security providers uses the embedded LDAP server.
RDBMS Security Store
WebLogic Server provides the option of using an external RDBMS as a datastore that is used by the following security providers:
- XACML Authorization and Role Mapping providers
- WebLogic credential mapping provider
- PKI credential mapping provider
- The following providers for SAML 1.1:
- SAML identity assertion provider V2
- SAML credential mapping provider V2
- The following providers for SAML 2.0:
- SAML 2.0 identity assertion provider
- SAML 2.0 credential mapping provider
- Default Certificate Registry
When the RDBMS security store is configured in a security realm, an instance of any of the preceding security providers that has been created in the security realm automatically uses only the RDBMS security store as a datastore, and not the embedded LDAP server. Other security providers continue to use their default stores; for example, the WebLogic Authentication provider continues to use the embedded LDAP server.
Oracle recommends that you configure the RDBMS security store at the time of domain creation. The Configuration Wizard has been enhanced to simplify the process. This ensures that when the domain is booted, the security policies required to access the domain can be retrieved from the external RDBMS.
Note that the use of the RDBMS security store is required to use SAML 2.0 services in two or more WebLogic Server instances in a domain, such as in a cluster. For more information about the RDBMS security store, see “Managing the RDBMS Security Store” in Securing WebLogic Server.
Types of Security Providers
The following sections describe the types of security providers that you can use with WebLogic Server:
- Authentication Providers
- Identity Assertion Providers
- Principal Validation Providers
- Authorization Providers
- Adjudication Providers
- Role Mapping Providers
- Auditing Providers
- credential mapping Providers
- Certificate Lookup and Validation Providers
- Keystore Providers
- Realm Adapter Providers
You cannot develop a single security provider that merges several provider types (for example, you cannot have one security provider that does authorization and role mapping).
Authentication Providers
Authentication providers allow WebLogic Server to establish trust by validating a user. The WebLogic Server security architecture supports Authentication providers that perform: username/password authentication, certificate and digest authentication directly with WebLogic Server, and HTTP certificate authentication proxied through an external Web server.
An identity assertion provider is a special type of Authentication provider that handles perimeter-based authentication and multiple security token types/protocols. For more information, see Identity Assertion Providers.
A LoginModule is the part of an Authentication provider that actually performs the authentication of a user or system. Authentication providers also use Principal Validation providers which provide additional security by signing and verifying the authenticity of principals (users/groups). For more information about Principal Validation providers, see Principal Validation Providers in Developing security providers for WebLogic Server.
You must have at least one Authentication provider in a security realm, and you can configure multiple Authentication providers in a security realm. Having multiple Authentication providers allows you to have multiple LoginModules, each of which may perform a different kind of authentication. An administrator configures each Authentication provider to determine how multiple LoginModules are called when users attempt to login to the system. Because they add security to the principals used in authentication, a Principal Validation provider must be accessible to your Authentication providers.
Authentication providers and LoginModules are discussed in more detail in Authentication Providers in Developing security providers for WebLogic Server.
Identity Assertion Providers
Identity assertion involves establishing a client's identity using client-supplied tokens that may exist outside of the request. Thus, the function of an identity assertion provider is to validate and map a token to a username. Once this mapping is complete, an Authentication provider's LoginModule can be used to convert the username to principals. identity assertion providers allow WebLogic Server to establish trust by validating a user.
An identity assertion provider is a specific form of Authentication provider that allows users or system processes to assert their identity using tokens (in other words, perimeter authentication). You can use an identity assertion provider in place of an Authentication provider if you create a LoginModule for the identity assertion provider, or in addition to an Authentication provider if you want to use the Authentication provider's LoginModule. identity assertion providers enable perimeter authentication and support single sign-on.
WebLogic Server provides identity assertion providers that perform perimeter-based authentication (Web server, firewall, VPN), support token types such as Digest, SPNEGO, and SAML (1.1 and 2.0), and can handle multiple security protocols (Kerberos, SOAP, IIOP-CSIv2). You can also write custom identity assertion providers that support different token types, such as Microsoft Passport. When used with an Authentication provider's LoginModule, identity assertion providers support single sign-on. For example, the identity assertion provider can generate a token from a digital certificate, and that token can be passed around the system so that users are not asked to sign on more than once.
To use the WebLogic identity assertion provider for X.501 and X.509 certificates, you have the option of using the default user name mapper that is supplied with the WebLogic Server product (weblogic.security.providers.authentication. DefaultUserNameMapperImpl) or providing you own implementation of the weblogic.security.providers.authentication.UserNameMapper interface. For more information, see Do I Need to Develop a Custom Identity Assertion Provider? in Developing security providers for WebLogic Server.
Multiple identity assertion providers can be configured in a security realm, but none are required. An identity assertion provider can support more than one token type, but only one token type at a time can be active in a particular identity assertion provider. For example, a particular identity assertion provider can support both X.509 and SAML (either 1.1 or 2.0, but not both), but an administrator configuring the system must select which token type (X.509 or SAML) is to be active in that identity assertion provider. For example, if there only one identity assertion provider configured and it is set to handle X.509 tokens, but SAML token types must be supported as well, then another identity assertion provider must be configured that can handle SAML tokens and SAML must be set as its active token type.
WebLogic Server provides separate identity assertion providers for SAML 1.1 and SAML 2.0. They are not interchangeable between versions of SAML. The SAML identity assertion provider V2 consumes SAML 1.1 assertions only, and the SAML 2.0 identity assertion provider consumes SAML 2.0 assertions only.
identity assertion providers are discussed in more detail in Identity Assertion Providers in Developing security providers for WebLogic Server.
Principal Validation Providers
A Principal Validation provider is a special type of security provider that primarily acts as a “helper” to an Authentication provider. Because some LoginModules can be remotely executed on behalf of RMI clients, and because the client application code can retain the authenticated subject between programmatic server invocations, Authentication providers rely on Principal Validation providers to provide additional security protections for the principals contained within the subject.
Principal Validation providers provide these additional security protections by signing and verifying the authenticity of the principals. This principal validation provides an additional level of trust and may reduce the likelihood of malicious principal tampering. Verification of the subject's principals takes place during the WebLogic Server's demarshalling of RMI client requests for each invocation. The authenticity of the subject's principals is also verified when making authorization decisions.
Because have at least one Authentication provider in a security realm, also have one Principal Validation provider in a security realm. If you have multiple Authentication providers, each of those Authentication providers must have a corresponding Principal Validation provider.
You cannot use the WebLogic Server Administration Console to configure Principal Validation providers directly. WebLogic Server configures the required Principal Validation providers for you when you configure your Authentication providers.
Principal Validation providers are discussed in more detail in Principal Validation Providers in Developing security providers for WebLogic Server.
Authorization Providers
Authorization providers control access to WebLogic resources based on the security role a user or group is granted, and the security policy assigned to the requested WebLogic resource. For more information about WebLogic resources, security roles, and security policies, see Securing WebLogic Resources Using Roles and Policies.
An Access Decision is the part of the Authorization provider that actually determines whether a subject has permission to perform a given operation on a WebLogic resource. For more information about, see Principal Validation Providers in Developing security providers for WebLogic Server.
You must have at least one Authorization provider in a security realm, and you can configure multiple Authorization providers in a security realm. Having multiple Authorization providers allows you to follow a more modular design. For example, you may want to have one Authorization provider that handles Web application and Enterprise JavaBean (EJB) permissions and another that handles permissions for other types of WebLogic resources. Another example might be to have one Authorization provider that handles domestic employees, and another that handles permissions for overseas employees.
WebLogic Server includes bulk access versions of the following Authorization provider SSPI interfaces:
- BulkAuthorizationProvider
- BulkAccessDecision
The bulk access SSPI interfaces allow Authorization providers to receive multiple decision requests in one call rather than through multiple calls, typically in a 'for' loop. The intent of the bulk SSPI variants is to allow provider implementations to take advantage of internal performance optimizations, such as detecting that many of the passed-in Resource objects are protected by the same policy and will generate the same decision result.
Authorization providers and Access Decisions are discussed in more detail in Authorization Providers in Developing security providers for WebLogic Server.
Adjudication Providers
As part of an Authorization provider, an Access Decision determines whether a subject has permission to access a given WebLogic resource. Therefore, if multiple Authorization providers are configured, each may return a different answer to the “is access allowed?” question. These answers may be PERMIT, DENY, or ABSTAIN. Determining what to do if multiple Authorization providers' Access Decisions do not agree on an answer is the function of an Adjudication provider. The Adjudication provider resolves authorization conflicts by weighing each Access Decision's answer and returning a final result. If you only have one Authorization provider and no Adjudication provider, then an ABSTAIN returned from the single Authorization provider's Access Decision is treated like a DENY.
The WebLogic Adjudication provider supports the use of the WebLogic Server Administration Console to control whether an abstain is treated as a permit or a deny.
You must configure an Adjudication provider in a security realm only if you have multiple Authorization providers configured. You can have only one Adjudication provider in a security realm.
Since the default security realm has only one Authorization provider, it does not require an Adjudication provider, even though an Adjudication provider is provided. However, the Compatibility realm has two Authorization providers, so that realm does require an Adjudication provider.
WebLogic Server includes bulk access versions of the following Adjudication provider SSPI interfaces:
- BulkAdjudicationProvider
- BulkAdjudicator
The bulk access SSPI interfaces allow Adjudication providers to receive multiple decision requests in one call rather than through multiple calls, typically in a 'for' loop. The intent of the bulk SSPI variants is to allow provider implementations to take advantage of internal performance optimizations, such as detecting that many of the passed-in Resource objects are protected by the same policy and will generate the same decision result.
Adjudication providers are discussed in more detail in Adjudication Providers in Developing security providers for WebLogic Server.
Role Mapping Providers
A Role Mapping provider supports dynamic role associations by obtaining a computed set of security roles granted to a requestor for a given WebLogic resource. The WebLogic Security Framework determines which security roles (if any) apply to a particular subject at the moment that access is required for a given WebLogic resource by:
- Obtaining security roles from the J2EE and WebLogic deployment descriptor files.
- Using business logic and the current operation parameters to determine security roles.
A Role Mapping provider supplies Authorization providers with this security role information so that the Authorization provider can answer the “is access allowed?” question for WebLogic resources that use role-based security (that is, Web application and Enterprise JavaBean container resources).
You set security roles in J2EE deployment descriptors, or create them using the WebLogic Server Administration Console. Security roles set in deployment descriptors are applied at deployment time (unless you specifically choose to ignore deployment descriptors).
You must have at least one Role Mapping provider in a security realm, and you can configure multiple Role Mapping providers in a security realm. Having multiple Role Mapping providers allows you to work within existing infrastructure requirements (for example, configuring one Role Mapping provider for each LDAP server that contains user and security role information), or follow a more modular design (for example, configuring one Role Mapping provider that handles mappings for Web applications and Enterprise JavaBeans (EJBs) and another that handles mappings for other types of WebLogic resources).
If multiple Role Mapping providers are configured, the set of security roles returned by all Role Mapping providers will be intersected by the WebLogic Security Framework. That is, security role names from all the Role Mapping providers will be merged into single list, with duplicates removed.
WebLogic Server includes bulk access versions of the following Role Mapping provider SSPI interfaces:
- BulkRoleProvider
- BulkRoleMapper
The bulk access SSPI interfaces allow Role Mapping providers to receive multiple decision requests in one call rather than through multiple calls, typically in a 'for' loop. The intent of the bulk SSPI variants is to allow provider implementations to take advantage of internal performance optimizations, such as detecting that many of the passed-in Resource objects are protected by the same policy and will generate the same decision result.
Role Mapping providers are discussed in more detail in Role Mapping Providers in Developing security providers for WebLogic Server.
Auditing Providers
An Auditing provider collects, stores, and distributes information about operating requests and the outcome of those requests for the purposes of non-repudiation. An Auditing provider makes the decision about whether to audit a particular event based on specific audit criteria, including audit severity levels. Auditing providers can write the audit information to output repositories such as an LDAP directory, database, or simple file. Specific actions, such as paging security personnel, can also be configured as part of an Auditing provider.
Other types of security providers (such as Authentication or Authorization providers) can request audit services before and after security operations have been performed by calling through the WebLogic Security Framework. For more information, see Auditing Events From Custom security providers in Developing security providers for WebLogic Server.
You can configure multiple Auditing providers in a security realm, but none are required.
Auditing providers are discussed in more detail in Auditing Providers in Developing security providers for WebLogic Server.
credential mapping Providers
A credential map is a mapping of credentials used by WebLogic Server to credentials used in a legacy or remote system, which tell WebLogic Server how to connect to a given resource in that system. In other words, credential maps allow WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated.
A credential mapping provider can handle several different types of credentials (for example, username/password combinations, SAML assertions, public key certificates, and alias/credential type combinations). You can set credential mappings in deployment descriptors or by using the WebLogic Server Administration Console. These credential mappings are applied at deploy time (unless you specifically choose to ignore the credential mappings).
You must have at least one credential mapping provider in a security realm, and you can configure multiple credential mapping providers in a security realm. If multiple credential mapping providers are configured, then the WebLogic Security Framework calls into each credential mapping provider to find out if they contain the type of credentials requested by the container. The WebLogic Security Framework then accumulates and returns all the credentials as a list.
WebLogic Server provides separate credential mapping providers for SAML 1.1 and SAML 2.0. They are not interchangeable between versions of SAML. The SAML credential mapping provider V2 generates SAML 1.1 assertions only, and the SAML 2.0 credential mapping provider generates SAML 2.0 assertions only.
credential mapping providers are discussed in more detail in credential mapping Providers in Developing security providers for WebLogic Server.
Certificate Lookup and Validation Providers
The Certificate Lookup and Validation providers complete certificate paths and validate X509 certificate chains. There are two types of CLV providers:
- CertPath Builder—Receives a certificate, a certificate chain, or certificate reference (the end certificate in a chain or the Subject DN of a certificate) from a web service or application code. The provider looks up and validates the certificates in the chain.
- CertPath Validator—Receives a certificate chain from the SSL protocol, a web service, or application code and performs extra validation (for example, revocation checking).
There must be at least one CertPath Builder and one CertPath Validator configured in a security realm. Multiple CertPath Validators can be configured in a security realm. If multiple providers are configured, a certificate or certificate chain must pass validation with all the CertPath Validators in order for the certificate or certificate chain to be valid.
WebLogic Server provides the functionality of the CLV providers in the WebLogic CertPath provider and the Certificate Registry.
Keystore Providers
With WebLogic Server, a keystore creates and manages password-protected stores of private keys (and their associated public key certificates) and trusted certificate authorities.
The WebLogic Keystore provider that is included as part of the WebLogic Server product is used to obtain secured private keys from keystores.
The WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use the WebLogic Trust and Identity keystores or the Java KeyStores (JKS) instead. All of the functionality that was supported by the WebLogic Keystore provider is available through use of these keystores. The WebLogic Keystore provider is only supported for backward compatibility. Oracle recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see Configuring Keystores in Securing WebLogic Server.
Realm Adapter Providers
Realm Adapter providers provide backward-compatibility with 6.x WebLogic security realms by allowing the use of existing, 6.x security realms with the security features in this release of WebLogic Server. The Realm Adapter providers map the realm API (weblogic.security.acl) used in WebLogic Server 6.x to the APIs used in this release of WebLogic Server. Figure 4-2 shows a Compatibility realm and the types of security providers supported. Figure 4-2 Compatibility Realm
Security Provider Summary
Table 4-2 indicates whether you can configure multiple security providers of the same type in a security realm.
| Type | Multiple Providers Supported? |
|---|---|
| Authentication provider | Yes |
| identity assertion provider | Yes |
| Principal Validation provider | Yes |
| Authorization provider | Yes |
| Adjudication provider | No |
| Role Mapping provider | Yes |
| Auditing provider | Yes |
| credential mapping provider | Yes |
| Certificate Lookup and Validation provider | One CertPath Builder Multiple CertPath Validators |
| Keystore provider | Yes |
| Realm Adapter provider | Yes for all types of Realm Adapter providers supported except the Adjudication provider. See Figure 4-2 for the supported types. |
security providers and Security Realms
All security providers exist within the context of a security realm. If you are not running a prior, 6.x release of WebLogic Server, the WebLogic Server security realm defined out-of-the-box as the default realm (that is, the active security realm called myrealm) contains the WebLogic security providers displayed in Figure 4-3.
If you are upgrading from a 6.x release to this release, your out-of-the-box experience begins with a Compatibility realm—which is initially defined as the default realm—to allow you to work with your existing configuration. Because the 6.x model is deprecated, you need to upgrade your security realm to the security model available in this release of WebLogic Server. Figure 4-3 WebLogic security providers in a Security Realm
Because security providers are individual modules or components that are “plugged into” a WebLogic Server security realm, you can add, replace, or remove a security provider with minimal effort. You can use the WebLogic security providers, custom security providers you develop, security providers obtained from third-party security vendors, or a combination of all three to create a fully-functioning security realm. However, as Figure 4-3 also shows, some types of security providers are required for a security realm to operate properly. Table 4-3 summarizes which security providers must be configured for a fully-operational security realm.
| Type | Required? |
|---|---|
| Authentication provider | Yes |
| identity assertion provider | Yes, if using perimeter authentication. |
| Principal Validation provider | Yes |
| Authorization provider | Yes |
| Adjudication provider | Yes, if there are multiple Authorization providers configured. |
| Role Mapping provider | Yes |
| Auditing provider | No |
| credential mapping provider | Yes |
| Certificate Lookup and Validation providers | Yes |
| Keystore provider | No
The WebLogic Keystore provider is deprecated in this release of WebLogic Server but is still supported. The development of custom Keystore providers is not supported. Use Java KeyStores (JKS) instead. Oracle recommends using the WebLogic Keystore provider only when it is needed to support backward compatibility with a WebLogic Server 7.0 configuration. For information on how to use Java KeyStores, see Configuring Keystores in Securing WebLogic Server. |
For more information about security realms, see
Configuration Steps for Security in Securing WebLogic Server.