Securing WebLogic Server
Note: WebLogic Server includes so many Authentication providers and Identity Assertion providers that they are better handled in a separate section. See Configuring Authentication Providers.
You can use either the WebLogic-supplied security providers or a custom security provider in a security realm. To configure a custom security provider, see Configure a custom security provider in the Administration Console online help.
Authorization is the process whereby the interactions between users and resources are limited to ensure integrity, confidentiality, and availability. In other words, authorization is responsible for controlling access to resources based on user identity or other information. You should only need to configure an Authorization provider when you create a new security realm.
By default, security realms in newly created domains include the XACML Authorization provider. The XACML Authorization provider uses XACML, the eXtensible Access Control Markup Language. WebLogic Server also includes the WebLogic Authorization provider, which uses a proprietary policy language. This provider is named DefaultAuthorizer, but is no longer the default authorization provider.
See Configure Authorization providers in the Administration Console online help.
Note: The WebLogic Authorization provider improves performance by caching the roles, predicates, and resource data that it looks up. For information on configuring these caches, see Best Practices: Configure Entitlements Caching When Using WebLogic Providers in Securing WebLogic Resources. The XACML Authorization uses its own cache, but this cache is not configurable.
When multiple Authorization providers are configured in a security realm, each may return a different answer to the "is access allowed" question for a given resource. This answer may be
ABSTAIN. Determining what to do if multiple Authorization providers do not agree on the answer is the primary function of the Adjudication provider. Adjudication providers resolve authorization conflicts by weighting each Authorization provider's answer and returning a final decision.
Each security realm requires an Adjudication provider, and can have no more than one active Adjudication provider. By default, a WebLogic security realm is configured with the WebLogic Adjudication provider. You can use either the WebLogic Adjudication provider or a custom Adjudication provider in a security realm.
By default, most configuration options for the WebLogic Adjudication provider are defined. However, you can set the Require Unanimous Permit option to determine how the WebLogic Adjudication provider handles a combination of
ABSTAIN votes from the configured Authorization providers.
PERMITin order for the Adjudication provider to vote
ABSTAINvotes are counted as
Role Mapping providers compute the set of roles granted to a subject for a given resource. Role Mapping providers supply Authorization providers with this role information so that the Authorization provider can answer the "is access allowed?" question for WebLogic resources. By default, a WebLogic security realm is configured with the XACML Role Mapping provider. The XACML Role Mapping provider uses XACML, the eXtensible Access Control Markup Language. WebLogic Server also includes the WebLogic Role Mapping provider, which uses a proprietary policy language. This provider is named DefaultRoleMapper, but is no longer the default role mapping provider in newly-created security realms. You can also use a custom Role Mapping provider in your security realm.
By default, most configuration options for the XACML Role Mapping provider are already defined. However, you can set Role Mapping Deployment Enabled, which specifies whether or not this Role Mapping provider imports information from deployment descriptors for Web applications and EJBs into the security realm. This setting is enabled by default.
In order to support Role Mapping Deployment Enabled, a Role Mapping provider must implement the
DeployableRoleProvider SSPI. Roles are stored by the XACML Role Mapping provider in the embedded LDAP server.
Note: The WebLogic Role Mapping provider improves performance by caching the roles, predicates, and resource data that it looks up. For information on configuring these caches, see Best Practices: Configure Entitlements Caching When Using WebLogic Providers in Securing WebLogic Resources. The XACML Role Mapping provider uses its own cache, but this cache is not configurable.
Auditing is the process whereby information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. In other words, Auditing providers produce an electronic trail of computer activity.
Configuring an Auditing provider is optional. The default security realm (
myrealm) does not have an Auditing provider configured. WebLogic Server includes a provider named the WebLogic Auditing provider (referred to as
DefaultAuditor in the Administration Console). You can also develop custom Auditing providers, as described in Auditing Providers in Developing Security Providers for WebLogic Server.
The WebLogic Auditing provider can log the events described in Table 4-1. In addition, if you enable configuration auditing (as described in Configuration Auditing), the WebLogic Auditing provider can log the events described in Table 4-5.
By default, most configuration options for the WebLogic Auditing provider are already defined and, once it is added to the active security realm, the WebLogic Auditing provider will begin to record audit events. However, you need to define the following settings, which you can do in the Administration Console on the Configuration: Provider Specific page for the provider. You can also use WebLogic Scripting tool or the Java Management Extensions (JMX) APIs to configure the Auditing provider:
DefaultAuditRecorder.logfile. At the specified time, the audit file is closed and a new one is created. A backup file named
DefaultAuditRecorder.200405130110.log) is created in the same directory.
All auditing information recorded by the WebLogic Auditing provider is saved in
logs\DefaultAuditRecorder.log by default. Although an Auditing provider is configured per security realm, each server writes auditing data to its own log file in the server directory. You can specify a new directory location for the
DefaultAuditRecorder.log file on the command line with the following Java startup option:
For more information, see "Security" in the Weblogic Server Command Reference.
For more information, see Configure Auditing providers in the Administration Console online help.
An Audit Event includes a
ContextHandler that can hold a variety of information or objects. Set the WebLogic Auditing provider's Active ContextHandler Entries attribute to specify which
ContextElement entries in the
ContextHandler are recorded by the Auditing provider. By default, none of the
ContextElements are audited. Objects in the
ContextHandler are in most cases logged using the
Table 4-3 lists the available
SSL framework has validated the certificate chain, meaning that the certificates in the chain have signed each other properly; the chain terminates in a certificate that is one of the server's trusted CAs; the chain honors the basic constraints rules; and the certificates in the chain have not expired.
You can configure the Administration Server to emit log messages and generate audit events when a user changes the configuration of any resource within a domain or invokes management operations on any resource within a domain. For example, if a user disables SSL on a Managed Server in a domain, the Administration Server emits log messages. If you have enabled the WebLogic Auditing provider, it writes the audit events to an additional security log. These messages and audit events provide an audit trail of changes within a domain's configuration (configuration auditing).
Note that configuration audit information is contained in Authorization Events. As a result, another approach to configuration auditing is to consume Authorization Events. Note, however, that the information in an Authorization Event tells you whether access was allowed to perform a configuration change; it does not tell you whether the configuration change actually succeeded (for instance, it might have failed because it was invalid).
ConfigurationAuditTypeattribute of the
DomainMBean. See WebLogic Scripting Tool.
The messages use MBean object names to identify resources. Object names for WebLogic Server MBeans reflect the location of the MBean within the hierarchical data model. To reflect the location, object names contain name/value pairs from the parent MBean. For example, the object name for a server's
mydomain:Name=myserverlog,Type=Log,Server=myserver. See WebLogic Server MBean Data Model in Developing Custom Management Utilities with JMX.
Table 4-5 summarizes the messages.
Note: Each time an authorized user adds, modifies, or deletes a resource, the Management subsystem also generates an
Info message with the ID
140009 regardless of whether configuration auditing is enabled. For example:
While the message informs you that the domain's configuration has changed, it does not provide the detailed information that configuration auditing messages provide. Nor does the Management subsystem generate this message when you invoke operations on resources.
Table 4-6 lists additional message attributes for configuration auditing messages. All configuration auditing messages specify the same values for these attributes.
An audit event is an object that Auditing providers can read and process in specific ways. An Auditing provider is a pluggable component that the security realm uses to collect, store, and distribute information about operating requests and the outcome of those requests for the purposes of non-repudiation.
If you enable a domain to emit Audit Events, the domain emits the events described in Table 4-7. All Auditing providers that are configured for the domain can handle these events.
All of the events are of severity level
SUCCESS and describe the security principal who initiated the action, whether permission was granted, and the object (MBean or MBean attribute) of the requested action.
Other Auditing providers that you create or purchase can filter these events and write them to output repositories such as an LDAP server, database, or a simple file. In addition, other types of security providers can request audit services from an Auditing provider. See Auditing Providers in Developing Security Providers for WebLogic Server.
Credential mapping is the process whereby the authentication and authorization mechanisms of a remote system (for example, a legacy system or application) obtain an appropriate set of credentials to authenticate remote users to a target WebLogic resource. The WebLogic Credential Mapping provider maps WebLogic Server subjects to the username/password pairs to be used when accessing such resources.
By default, most configuration options for the WebLogic Credential Mapping provider are defined. However, you have the option of setting Credential Mapping Deployment Enabled, which specifies whether or not this Credential Mapping provider imports credential maps from a resource adapter's deployment descriptor (
weblogic-ra.xml file) into the security realm. This setting is enabled by default.
In order to support Credential Mapping Deployment Enabled, a Credential Mapping provider must implement the
DeployableCredentialProvider SSPI. The credential mapping information is stored in the embedded LDAP server.
The PKI (Public Key Infrastructure) Credential Mapping provider included in WebLogic Server maps (a) a WebLogic Server subject (the initiator) and target resource (and an optional credential action) to (b) a key pair or public certificate that can be used by applications when accessing the targeted resource. The PKI Credential Mapping provider uses the subject and resource name to retrieve the corresponding credential from the keystore.
myrealm). See PKI Credential Mapper Attributes and Configure Credential Mapping providers in the Administration Console online help.
To configure the PKI Credential Mapping provider, set values for these attributes. See Configure Credential Mapping providers in the Administration Console online help.
Optionally, you can label a credential mapping with a credential action. You can do this in the Administration Console when you create the credential mapping. The credential action is an arbitrary string that distinguishes credential mappings used in different circumstances. For example, one credential mapping could decrypt a message from a remote resource and another credential mapping could sign messages to be sent to the same resource. The subject initiator and the target resource are not sufficient to distinguish these two credential mappings. You can use the credential action to label one of these credential mappings something like
decrypt and the other one
sign. Then, the application calling the PKI Credential Mapping provider can provide the desired credential action value in the
ContextHandler that is passed to the provider.
The SAML Credential Mapping provider acts as a producer of SAML security assertions, allowing WebLogic Server to act as a source site for using SAML for single sign-on. The SAML Credential Mapping provider generates valid SAML 1.1 assertions for authenticated subjects based on the configuration of the target site or resource. The SAML Credential Mapping provider can be configured as a SAML Intersite Transfer Service. See Configure Credential Mapping providers in the Administration Console online help.
This release of WebLogic Server includes two SAML Credential Mapping providers. SAML Credential Mapping Provider Version 2 provides greatly enhanced configuration options and is recommended for new deployments. SAML Credential Mapping Provider Version 1 is deprecated in WebLogic Server 9.1. A security realm can have not more than one SAML Credential Mapping provider, and if the security realm has both a SAML Credential Mapping provider and a SAML Identity Assertion provider, both must be of the same version. Do not use a Version 1 SAML provider in the same security realm as a Version 2 SAML provider. For information about configuring the SAML Credential Mapping Provider Version 1, see Configuring a SAML Credential Mapping Provider in the WebLogic Server 9.0 documentation.
For general information about WebLogic Server's support for SAML, see Security Assertion Markup Language (SAML) and Single Sign-On with the WebLogic Security Framework in Understanding WebLogic Security. For information about how to use the SAML Credential Mapping provider in a SAML single sign-on configuration, see Configuring Single Sign-On with Web Browsers and HTTP Clients.
When you configure WebLogic Server to act as a source of SAML security assertions, you need to register the parties that may request SAML assertions will be accepted. For each SAML Relying Party, you can specify the SAML profile used, details about the Relying Party, and the attributes expected in assertions for the Relying Party. For information, see:
WebLogic Server may receive digital certificates as part of Web Services requests, two-way SSL, or other secure interactions. To validate these certificates, WebLogic Server includes a Certificate Lookup and Validation (CLV) framework, whose function is to look up and validate X.509 certificate chains. The key elements of the CLV framework are the CertPathBuilder and the CertPathValidators. The CLV framework requires one and only active CertPathBuilder which, given a reference to a certificate chain, finds the chain and validates it, and zero or more CertPathValidators which, given a certificate chain, validates it.
When WebLogic Server receives a certificate, the CLV framework uses the security provider configured as the CertPathBuilder to look up and validate the certificate chain. If the certificate chain is found and valid, the framework then calls each configured CertPathValidator, in the order the administrator configured them, to perform extra validation on the chain. The chain is only valid if the builder and all the validators successfully validate it.
WebLogic Server includes two CLV security providers: the WebLogic CertPath provider (which acts as both a CertPathBuilder and a CertPathValidator), described in CertPath Provider, and the Certificate Registry, described in Certificate Registry. Use just the WebLogic CertPath provider if you want to use trusted CA-based validation of the full certificate chain. Use just the Certificate Registry if you want only to validate that certificates are registered. Use both, designating the Certificate Registry as the current builder, if you want to use both types of validation.
For more information about certificate lookup and validation, see Configuring Identity and Trust.
The default security realm in WebLogic Server is configured with the WebLogic CertPath provider. The CertPath provider serves two functions: CertPathBuilder and CertPathValidator. The CertPath provider receives an end certificate or a certificate chain. It uses the server's list of trusted CAs to complete the certificate chain, if necessary. After building the chain, the CertPath provider validates the chain, checking the signatures in the chain, ensuring that the chain has not expired, checking the chain's basic constraints, and verifying that the chain terminates in a certificate issued by one of the server's trusted CAs.
The WebLogic CertPath provider requires no configuration, other than its Current Builder attribute, which indicates whether the CertPath provider should be used as the active certificate chain builder.
The Certificate Registry is a security provider that allows you to explicitly register the list of trusted certificates that are allowed to access WebLogic Server. If you configure a Certificate Registry as part of your security realm, then only certificates that are registered in the Certificate Registry will be considered valid. The Certificate Registry provides an inexpensive mechanism for performing revocation checking. By removing a certificate from the Certificate Registry, you can invalidate a certificate immediately. The registry is stored in the embedded LDAP server.
The Certificate Registry is both a CertPath Builder and a CertPath Validator. In either case, the Certificate Registry ensures that the chain's end certificate is stored in the registry, but does no other validation. If you use the Certificate Registry as your security realm's CertPath Builder and you also want to use the WebLogic CertPath provider or another security provider to perform full chain validation, make sure that you register the intermediate and root CAs in each server's trust keystore, and the end certificates in the Certificate Registry.
The default security realm in WebLogic Server does not include a Certificate Registry. Once you configure a Certificate Registry, you can use the WebLogic Administration Console to add, remove, and view certificates in the registry. You can export a certificate from a keystore to a file, using the Java
keytool utility. You can import a certificate that is a PEM or DER file in the file system into the Certificate Registry using the console. You can also use the Console to view the contents of a certificate, including its subject DN, issuer DN, serial number, valid dates, fingerprints, etc.
See Configure Certification Path providers in the Administration Console online help.
Note: The WebLogic Keystore provider is deprecated. It is only supported for backward compatibility. Use Java KeyStores (JKS) instead. All of the functionality that was supported by the WebLogic Keystore provider is available through use of Java KeyStores.
For information about configuring the WebLogic Keystore provider, see Configure keystores in the Administration Console online help.