Configuring WebLogic security providers

Securing WebLogic Server

Configuring WebLogic security providers

The following sections describe how to configure the security providers supplied by WebLogic Server.

WebLogic Server includes so many Authentication providers and identity assertion providers that they are better handled in a separate section. See Configuring Authentication Providers.

When Do You Need to Configure a Security Provider?
Reordering security providers
Configuring an Authorization Provider
Configuring the WebLogic Adjudication Provider
Configuring a Role Mapping Provider
Configuring the WebLogic Auditing Provider
Configuring a WebLogic credential mapping Provider
Configuring a PKI credential mapping Provider
Configuring a SAML credential mapping Provider for SAML 1.1
Configuring a SAML 2.0 credential mapping Provider for SAML 2.0
Configuring the Certificate Lookup and Validation Framework

When Do You Need to Configure a Security Provider?

By default, most WebLogic security providers are generally configured to run after you install WebLogic Server. However, the following circumstances require you to supply configuration information:

Before using the WebLogic identity assertion provider, define the active token type. See Configuring Identity Assertion Providers.
To map tokens to a user in a security realm, configure the user name mapper in the WebLogic identity assertion provider. See Configuring a WebLogic credential mapping Provider.
To use auditing in the default (active) security realm, configure either the WebLogic Auditing provider or a custom Auditing provider. See Configuring the WebLogic Auditing Provider.
To use HTTP and Kerberos-based authentication in conjunction with WebLogic Server. See Configuring Single Sign-On with Microsoft Clients.
To use identity assertion based on SAML assertions. See Configuring Single Sign-On with Web Browsers and HTTP Clients.
To use certificate revocation. See Certificate Registry.
To use an LDAP server other than the embedded LDAP server, configure one of the LDAP Authentication providers. An LDAP authentication provider can be used instead of or in addition to the WebLogic Authentication provider. See Configuring LDAP Authentication Providers.
To access user, password, group, and group membership information stored in databases for authentication purposes. See Configuring RDBMS Authentication Providers The RDBMS Authentication providers can be used to upgrade from the RDBMS security realm.
To use Windows NT users and groups for authentication purposes. See Configuring a Windows NT Authentication Provider. The Windows NT Authentication provider is the upgrade path for the Window NT security realm.
When you create a new security realm, configure security providers for that realm. See Creating and Configuring a New Security Realm: Main Steps.
When you add a custom security provider to a security realm or replace a WebLogic security provider with a custom security provider, configure options for the custom security provider. When you create a custom security provider, you can implement options that are configurable through the Administration Console. However, those options are implementation-specific and are not addressed in this manual. See Extending the Administration Console.

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.

Reordering security providers

You can configure more than one security provider of a given type in a security realm. For example, you might use two or more different Role Mapping providers or Authorization providers. If you have more than one security provider of the same type in a security realm, the order in which these providers are called can affect the overall outcome of the security processes. By default, security providers are called in the order that they were added to the realm. You can use the Administration Console to change the order of the providers. See Re-order security providers in the Administration Console Online Help.

Configuring an Authorization Provider

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. For information about using the XACML Authorization provider, see Using XACML Documents to Secure WebLogic Resources in Securing WebLogic Resources Using Roles and Policies. 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.

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 Using Roles and Policies. The XACML Authorization uses its own cache, but this cache is not configurable.

Configuring the WebLogic Adjudication Provider

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 PERMIT, DENY, or 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.

In the Administration Console, the WebLogic Adjudication provider is referred to as the Default Adjudicator.
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 PERMIT and ABSTAIN votes from the configured Authorization providers.

If the option is enabled (the default), all Authorization providers must vote PERMIT in order for the Adjudication provider to vote true.
If the option is disabled, ABSTAIN votes are counted as PERMIT votes.

Configuring a Role Mapping Provider

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. For information about using the XACML Role Mapping provider, see Using XACML Documents to Secure WebLogic Resources in Securing WebLogic Resources Using Roles and Policies.
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.
For information about using, developing, and configuring Role Mapping providers, see:

Users, Groups, And Security Roles in Securing WebLogic Resources Using Roles and Policies
Role Mapping Providers in Developing security providers for WebLogic Server
Configure Role Mapping providers in the Administration Console Online Help

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 Using Roles and Policies. The XACML Role Mapping provider uses its own cache, but this cache is not configurable.

Configuring the WebLogic Auditing Provider

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.

Table 4-1 WebLogic Auditing Provider Events
Audit Event Indicates...
AUTHENTICATE Simple authentication (username and password) occurred.
ASSERTIDENTITY Perimeter authentication (based on tokens) occurred.
USERLOCKED A user account is locked because of invalid login attempts.
USERUNLOCKED The lock on a user account is cleared.
USERLOCKOUTEXPIRED The lock on a user account expired.
ISAUTHORIZED An authorization attempt occurred.
ROLEEVENT A getRoles event occurred.
ROLEDEPLOY A deployRole event occurred.
ROLEUNDEPLOY An undeployRole event occurred.
POLICYDEPLOY A deployPolicy event occurred.
POLICYUNDEPLOY An undeployPolicy event occurred.
START_AUDIT An Auditing provider has been started.
STOP_AUDIT An Auditing provider has been stopped.

Rotation Minutes—Specifies how many minutes to wait before creating a new DefaultAuditRecorder.log file. At the specified time, the audit file is closed and a new one is created. A backup file named DefaultAuditRecorder.YYYYMMDDHHMM.log (for example, DefaultAuditRecorder.200405130110.log) is created in the same directory.
Severity—Severity level appropriate for your WebLogic Server deployment. The WebLogic Auditing provider audits security events of the specified severity, as well as all events with a higher numeric severity rank. For example, if you set the severity level to ERROR, the WebLogic Auditing provider audits security events of severity level ERROR, SUCCESS, and FAILURE. You can also set the severity level to CUSTOM, and then enable the specific severity levels you want to audit, such as ERROR and FAILURE events only. Audit events include both the severity name and numeric rank; therefore, a custom Auditing provider can filter events by either the name or the numeric rank. Auditing can be initiated when the following levels of security events occur. Table 4-2 Audit Severity Levels

Event Severity Rank
INFORMATION 1
WARNING 2
ERROR 3
SUCCESS 4
FAILURE 5

All auditing information recorded by the WebLogic Auditing provider is saved in WL_HOME\yourdomain\yourserver\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:
-Dweblogic.security.audit.auditLogDir=c:\foo
The new file location will be c:\foo\yourserver\logs\DefaultAuditRecorder.log.
For more information, see Security in the WebLogic Server Command Reference.

WARNING: Using an Auditing provider affects the performance of WebLogic Server even if only a few events are logged.

For more information, see Configure Auditing providers in the Administration Console Online Help.

Auditing ContextHandler Elements

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 toString method. Table 4-3 lists the available ContextHandler entries. Table 4-3 Context Handler Entries for Auditing.

Context Element Name Description and Type
com.bea.contextelement.
servlet.HttpServletRequest A servlet access request or SOAP message via HTTP javax.http.servlet.HttpServletRequest
com.bea.contextelement.
servlet.HttpServletResponse A servlet access response or SOAP message via HTTP javax.http.servlet.HttpServletResponse
com.bea.contextelement.
wli.Message A WebLogic Integration message. The message is streamed to the audit log. java.io.InputStream
com.bea.contextelement.
channel.Port Internal listen port of the network channel accepting or processing the request java.lang.Integer
com.bea.contextelement.
channel.PublicPort External listen port of the network channel accepting or processing the request java.lang.Integer
com.bea.contextelement.
channel.RemotePort Port of the remote end of the TCP/IP connection of the network channel accepting or processing the request java.lang.Integer
com.bea.contextelement.
channel.Protocol Protocol used to make the request of the network channel accepting or processing the request java.lang.String
com.bea.contextelement.
channel.Address The internal listen address of the network channel accepting or processing the request java.lang.String
com.bea.contextelement.
channel.PublicAddress The external listen address of the network channel accepting or processing the request java.lang.String
com.bea.contextelement.
channel.RemoteAddress Remote address of the TCP/IP connection of the network channel accepting or processing the request java.lang.String
com.bea.contextelement.
channel.ChannelName Name of the network channel accepting or processing the request java.lang.String
com.bea.contextelement.
channel.Secure Whether the network channel is accepting or processing the request using SSL java.lang.Boolean
com.bea.contextelement.
ejb20.Parameter[1-N] Object based on parameter
com.bea.contextelement.
wsee.SOAPMessage javax.xml.rpc.handler.MessageContext
com.bea.contextelement.
entitlement.EAuxiliaryID Used by a WebLogic Server internal process. weblogic.entitlement.expression.EAuxiliary
com.bea.contextelement.
security.ChainPrevalidatedBySSL 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. java.lang.Boolean
com.bea.contextelement.
xml.SecurityToken Not used in this release of WebLogic Server. weblogic.xml.crypto.wss.provider.SecurityToken
com.bea.contextelement.
xml.SecurityTokenAssertion Not used in this release of WebLogic Server. java.util.Map
com.bea.contextelement.
webservice.Integrity{id:XXXXX} javax.security.auth.Subject
com.bea.contextelement.
saml.SSLClientCertificateChain SSL client certificate chain obtained from the SSL connection over which a sender-vouches SAML assertion was received. java.security.cert.X509Certificate[]
com.bea.contextelement.
saml.MessageSignerCertificate Certificate used to sign a Web Services message. java.security.cert.X509Certificate
com.bea.contextelement.
saml.subject.ConfirmationMethod Type of SAML assertion: bearer, artifact, sender-vouches, or holder-of-key. java.lang.String
com.bea.contextelement.
saml.subject.dom.KeyInfo <ds:KeyInfo> element to be used for subject confirmation with holder-of-key SAML assertions. org.w3c.dom.Element

Configuration Auditing

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).
The Administration Server writes configuration auditing messages to its local log file. They are not written to the domain-wide message log by default.
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).

Enabling Configuration Auditing

Enable configuration auditing by one of these methods:
Enabling Configuration Auditing in the Administration Console Online Help.
When you start the Administration Server, include one of the following Java options in the weblogic.Server command:

-Dweblogic.domain.ConfigurationAuditType="audit"
Causes the domain to emit Audit Events only.
-Dweblogic.domain.ConfigurationAuditType="log"
Causes the domain to write configuration auditing messages to the Administration Server log file only.
-Dweblogic.domain.ConfigurationAuditType="logaudit"
Causes the domain to emit Audit Events and write configuration auditing messages to the Administration Server log file.
See weblogic.Server Command-Line Reference.

Use the WebLogic Scripting Tool to change the value of the ConfigurationAuditType attribute of the DomainMBean. See WebLogic Scripting Tool.

Configuration Auditing Messages

Configuration auditing messages are of the following severities:

Table 4-4 Configuration Auditing Message Severities
Severity Description
SUCCESS A successful configuration change occurred.
FAILURE An attempt to modify the configuration failed due to insufficient user credentials.
ERROR An attempt to modify the configuration failed due to an internal error.

Configuration auditing messages are identified by message IDs that fall within the range of 159900-159910.
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 LogMBean is: 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.

Table 4-5 Summary of Configuration Auditing Messages
When This Event Occurs... WebLogic Server Generates a Message With This ID... And This Message Text...
Authorized user creates a resource. 159900 USER username CREATED MBean-name
where username identifies the WebLogic Server user who logged in and created a resource.
Unauthorized user attempts to create a resource. 159901 USER username CREATED MBean-name
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user deletes a resource. 159902 USER username REMOVED MBean-name where username identifies the WebLogic Server user who logged in and deleted a resource.
Unauthorized user attempts to delete a resource. 159903 USER username REMOVE MBean-name
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user changes a resource's configuration. 159904 USER username MODIFIED MBean-name
ATTRIBUTE attribute-name
FROM old-value TO new-value where username identifies the WebLogic Server user who logged in and changed the resource's configuration.
Unauthorized user attempts to change a resource's configuration. 159905 USER username MODIFY MBean-name
ATTRIBUTE attribute-name
FROM old-value TO new-value
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user invokes an operation on a resource. For example, a user deploys an application or starts a server instance. 159907 USER username INVOKED ON
MBean-name
METHOD operation-name
PARAMS specified-parameters where username identifies the WebLogic Server user who logged in and invoked a resource operation.
Unauthorized user attempts to invoke an operation on a resource. 159908 USER username INVOKED ON
MBean-name
METHOD operation-name
PARAMS specified-parameters
FAILED weblogic.management.
NoAccessRuntimeException:
exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user enables configuration auditing. 159909 USER username, Configuration Auditing is enabled where username identifies the WebLogic Server user who enabled configuration auditing.
Authorized user disables configuration auditing. 159910 USER username, Configuration Auditing is disabled where username identifies the WebLogic Server user who disabled configuration auditing.

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:

Note: <Sep 15, 2005 11:54:47 AM EDT> <Info> <Management> <140009> <Configuration changes for domain saved to the repository.>

Note: 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.

Table 4-6 Common Message Attributes and Values
Message Attribute Attribute Value
Severity Info
Subsystem Configuration Audit
User ID kernel identity This value is always kernel identity, regardless of which user modified the resource or invoked the resource operation.
Server Name AdminServerName Because the Administration Server maintains the configuration data for all resources in a domain, this value is always the name of the Administration Server.
Machine Name AdminServerHostName Because the Administration Server maintains the configuration data for all resources in a domain, this value is always the name of the Administration Server's host machine.
Thread ID execute-thread The value depends on the number of execute threads that are currently running on the Administration Server.
Timestamp timeStamp at which the message is generated.

Audit Events and Auditing Providers

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.

Table 4-7 Summary of Audit Events for Configuration Auditing
When This Event Occurs... WebLogic Server Generates This Audit Event Object...
A request to create a new configuration artifact has been allowed or prevented. weblogic.security.spi.
AuditCreateConfigurationEvent See Javadoc.
A request to delete an existing configuration artifact has been allowed or prevented. weblogic.security.spi.
AuditDeleteConfigurationEvent See Javadoc.
A request to modify an existing configuration artifact has been allowed or prevented. weblogic.security.spi.
AuditInvokeConfigurationEvent See Javadoc.
A invoke an operation on an existing configuration artifact has been allowed or prevented. weblogic.security.spi.
AuditSetAttributeConfigurationEvent See Javadoc.

If you enable the default WebLogic Server Auditing provider, it writes all Audit Events as log messages in its own log file.
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.

Configuring a WebLogic credential mapping Provider

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.
For more information:

See credential mapping Providers in Developing security providers for WebLogic Server
See Configure credential mapping providers and Create credential mappings in the Administration Console Online Help.
For information about using credential maps, see Programming WebLogic Resource Adapters.
You can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration.
For information about other credential mapping providers, see Configuring a PKI credential mapping Provider and Configuring a SAML credential mapping Provider for SAML 1.1.

Configuring a PKI credential mapping Provider

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.
To use the PKI credential mapping provider, you need to:

Configure keystores with appropriate keys and distribute the keystores on all machines in a WebLogic Server cluster. Setting up keystores is not a WebLogic Server function. For information about setting up keystores, see the help for the Java keytool utility at http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html. See also Configuring Identity and Trust, for information about keystores and keys in WebLogic Server.
Configure a PKI credential mapping provider. A PKI credential mapping provider is not already configured in the default security realm (myrealm). See PKI Credential Mapper Attributes and Configure credential mapping providers in the Administration Console Online Help.
Create credential mappings. See Create PKI credential mappings in the Administration Console Online Help.

PKI Credential Mapper Attributes

To configure the PKI credential mapping provider, set values for these attributes. See Configure credential mapping providers in the Administration Console Online Help.

Keystore Provider—A keystore provider for the Java Security API. If no value is specified, the default provider class is used.
Keystore Type— JKS (the default) or PKCS12.
Keystore Pass Phrase—Password used to access the keystore
Keystore File Name—Location of the keystore relative to the directory where the server was started.

In addition, two optional attributes determine how the PKI credential mapping provider locates credential mappings in cases where the exact resource or subject may not be available:

Use Resource Hierarchy—A credential is located by traversing up the resource hierarchy for each type of resource. The search for all possible PKI credentials will start from the specific resource and will walk up the resource hierarchy to find all possible matches. This attribute is enabled by default.
Use Initiator Group Names—When a subject is passed to the PKI Credential Mapper provider, a credential is located by examining the groups of which the initiator is a member. This is enabled by default.

Credential Actions

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.
For information about adding credential actions to PKI credential mappings, see Create PKI credential mappings in the Administration Console Online Help.

Configuring a SAML credential mapping Provider for SAML 1.1

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.

Configuring Assertion Lifetime

A SAML Assertion's validity is typically time-limited. The default time-to-live for assertions generated by the SAML credential mapping provider is specified by the DefaultTimeToLive attribute. You can override the default time-to-live for assertions generated for different SAML Relying Parties.
Normally, an assertion is valid from the NotBefore time, which defaults to (roughly) the time the assertion was generated, until the NotOnOrAfter time, which is calculated as (NotBefore + TimeToLive). To allow the Credential Mapper to compensate for clock differences between the source and destination sites, you can configure the SAML credential mapping provider's DefaultTimeToLiveDelta attribute. This time-to-live offset value is a positive or negative integer indicating how many seconds before or after “now” the assertion's NotBefore value should be set to. If you set a value for DefaultTimeToLiveDelta, then the assertion lifetime is still calculated as (NotBefore + TimeToLive), but the NotBefore value is set to (now + TimeToLiveDelta). For example, given the following settings:
DefaultTimeToLive = 120
DefaultTimeToLiveDelta = -30
an assertion when generated would have a lifetime of two minutes (120 seconds), starting 30 seconds before it is generated.

Relying Party Registry

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 to be generated. 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:

Configure Relying Parties.
Configure a SAML Relying Party in the Administration Console Online Help.

Configuring a SAML 2.0 credential mapping Provider for SAML 2.0

The SAML 2.0 credential mapping provider included with WebLogic Server generates SAML 2.0 assertions that can be used to assert identity in the following use cases:

SAML 2.0 Web SSO Profile
WS-Security SAML Token Profile version 1.1

The SAML 2.0 credential mapping provider generates the assertion types listed and described in Table 4-8.

Table 4-8 Assertion Types Supported by the SAML 2.0 credential mapping Provider
Assertion Type Description
bearer The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the <SubjectConfirmationData> element of the assertion. Used for all assertions generated for the SAML 2.0 Web Browser SSO Profile and with the Web Service Security SAML Token Profile 1.1.
sender-vouches The identity provider (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the identity provider. Used with the Web Service Security SAML Token Profile 1.1 only.
holder-of-key The subject represented in the assertion uses an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages. Used with the Web Service Security SAML Token Profile 1.1 only.

For general information about WebLogic Server's support for SAML 2.0, 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 2.0 credential mapping provider in a SAML 2.0 single sign-on configuration, see Configuring Single Sign-On with Web Browsers and HTTP Clients. For information about specifying the confirmation method for assertions generated for web service Service provider partners, see Using Security Assertion Markup Language (SAML) Tokens For Identity in Securing WebLogic Web Services.

SAML 2.0 credential mapping Provider Attributes

http://e-docs.bea.com/wls/docs103/saml2_javadocs/com/bea/security/saml2/providers/SAML2CredentialMapperMBean.html
To configure the SAML 2.0 credential mapping provider, set the following attributes:

Issuer URI
Name of this security provider. The value that you specify should match the Entity ID specified in the SAML 2.0 General page that configures the per-server SAML 2.0 properties.
Name of Qualifier
Used by the Name Mapper class as the security or administrative domain that qualifies the name of the subject. This provides a means to federate names from disparate user stores while avoiding the possibility of subject name collision.
Assertion life time
Values that limit the life time of generated assertions during which they may be used. Expired assertions cannot be made available for use.
Web service assertion signing key alias and passphrase
Used for signing generated assertions.
Custom name mapper class
The custom Java class that overrides the default SAML 2.0 credential mapping provider name mapper class, which maps Subjects to identity information contained in the assertion.
Generate attributes
Whether group membership information associated with the authenticated Subject is included in generated assertions.

service provider Partners

When you configure WebLogic Server to act as an identity provider, you need to create and configure the service provider partners for whom SAML 2.0 assertions are generated. When an identity provider site needs to generate an assertion, the SAML 2.0 credential mapping provider determines the service provider partner for whom the assertion must be generated, and generates it according to the configuration of that service provider partner.
The way in which you configure a service provider partner, and the specific information you configure for that partner, depends upon whether the partner is used for web single sign-on or web services. Configuring a web single sign-on service provider partner consists of importing that partner's metadata file and establishing additional basic information about that partner, such as the following:

Determining whether SAML documents, such as authentication responses, SAML artifacts, and artifact requests, must be signed
Certificates used for validating signed documents received from this partner
The binding to be used for sending SAML artifacts to this partner
The client user name and password used by this partner when connecting to the local site's binding

For details about configuring a service provider partner for web single sign-on, see:

Create and Configure Web Single Sign-On service provider Partners
Create a SAML 2.0 Web SSO Provider partner in the Administration Console Online Help

Configuring a web service service provider partner does not use a metadata file, but does consist of establishing the following information about that partner:

Audience URIs, which specify an audience restriction to be included in assertions generated for this partner
In WebLogic Server, the Audience URI attribute is overloaded to also include the partner lookup string, which is required by the web service run time to discover the partner. See Partner Lookup Strings Required for Web Service Partners.
Custom name mapper class that overrides the default name mapper and that is to be used specifically with this partner
Values that specify the life span attributes of assertions generated for this partner
Confirmation method for assertions received from this partner

For more information about configuring web service service provider partners, see Create a SAML 2.0 Web Service service provider partner in the Administration Console Online Help.
Partner Lookup Strings Required for Web Service Partners

For web service service provider partners, you also configure Audience URIs. In WebLogic Server, the Audience URI attribute is overloaded to perform two distinct functions:

Specify an audience restriction that consists of the target service URL, per the OASIS SAML 2.0 specification.
Contain a partner lookup string, which is required at run time by WebLogic Server to discover the service provider partner for which a SAML 2.0 assertion needs to be generated.

The partner lookup string specifies an endpoint URL, which is used for partner lookup and can optionally also serve as an Audience URI restriction that is included in the generated assertion. The ability to specify a partner lookup string that is also an Audience URI eliminates the need to specify a given target URL twice: once for lookup, and again for audience restriction.

You must configure a partner lookup string for a service provider partner so that partner can be discovered at run time by the web service run time.
Lookup String Syntax

The partner lookup string has the following syntax:
[target:char:]<endpoint-url>
In this syntax, target:char: is a prefix that designates the partner lookup string, where char represents one of three special characters: a hyphen, plus sign, or asterisk (-, +, or *). This prefix determines how partner lookup is performed, as described in Table 4-9.

Table 4-9 service provider Partner Lookup String Syntax
Lookup String Description
target:-:<endpoint-url> Specifies that partner lookup is conducted for an exact match of the URL, <endpoint-url>. For example, target:-:http://www.avitek.com:7001/myserver/myservicecontext/myservice-endpoint specifies the endpoint that can be matched to this service provider, for which an assertion should be generated. This form of partner lookup string excludes the endpoint URL from being added as an Audience URI in the generated assertion.
target:+:<endpoint-url> Specifies that partner lookup is conducted for an exact match of the URL, <endpoint-url>. Using the plus sign (+) in the lookup string results in the endpoint URL being added as an Audience URI in the assertion generated for this service provider partner.
target:*:<endpoint-url> Specifies that partner lookup is conducted for an initial-string pattern match of the URL, <endpoint-url>. For example, target:*:http://www.avitek.com:7001/myserver specifies that any endpoint URL beginning with http://www.avitek.com:7001/myserver can be matched to this service provider, such as: http://www.avitek.com:7001/myserver/contextA/endpointA and http://www.avitek.com:7001/myserver/contextB/endpointB. If more than one service provider partner is discovered that is a match for the initial string, the partner with the longest initial string match is selected. This form of partner lookup string excludes the endpoint URL from being added as an Audience URI in the generated assertion.

Notes: Configuring one or more partner lookup strings for a service provider partner is required in order for that partner to be discovered at run time. If this partner cannot be discovered, no assertions for this partner can be generated.

Note: If you configure an endpoint URL without using the target lookup prefix, it will be handled as a conventional Audience URI that must be contained in assertions generated for this service provider partner. (This also enables backwards-compatibility with existing Audience URIs that may be configured for this partner.)

Specifying Default Partners

To support the need for a default service provider partner entry, one or more of the default partner's Audience URI entries may contain a wildcard match that works for all targets. The actual wildcard URI may depend on the specific format used by the web service run time. For example:

target:*:http://
target:*:https://

Management of Partner Certificates

The SAML 2.0 credential mapping provider manages a set of trusted certificates for each partner configured for web single sign-on. Whenever a signed authentication or artifact request is received during a message exchange with a partner, the trusted certificate is used to verify the partner's signature. Partner certificates are used for the following purposes:

To validate trust when the SAML 2.0 credential mapping provider receives a signed authentication request or artifact request.
To validate trust in a service provider partner that is retrieving a SAML artifact from the Artifact Resolution Service (ARS) via an SSL connection.

From the Administration Console, you can view a web single sign-on service provider partner's signing certificate and transport layer client certificate in the partner management pages of the configured SAML 2.0 credential mapping provider.
Java Interface for Configuring service provider Partner Attributes

Operations on web service partners are available in the com.bea.security.saml2.providers.registry.Partner Java interface.

Configuring the Certificate Lookup and Validation Framework

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.
A chain is valid only if all of the following are true:

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 (for example, no certificate in the chain has been issued by a certificate that is not allowed to issue certificates).
The certificates in the chain have not expired.

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, seeConfiguring Identity and Trust.

CertPath Provider

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.

Certificate Registry

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.

Configuring a WebLogic Keystore Provider

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.

Audit Event	Indicates...
AUTHENTICATE	Simple authentication (username and password) occurred.
ASSERTIDENTITY	Perimeter authentication (based on tokens) occurred.
USERLOCKED	A user account is locked because of invalid login attempts.
USERUNLOCKED	The lock on a user account is cleared.
USERLOCKOUTEXPIRED	The lock on a user account expired.
ISAUTHORIZED	An authorization attempt occurred.
ROLEEVENT	A getRoles event occurred.
ROLEDEPLOY	A deployRole event occurred.
ROLEUNDEPLOY	An undeployRole event occurred.
POLICYDEPLOY	A deployPolicy event occurred.
POLICYUNDEPLOY	An undeployPolicy event occurred.
START_AUDIT	An Auditing provider has been started.
STOP_AUDIT	An Auditing provider has been stopped.

Context Element Name	Description and Type
com.bea.contextelement. servlet.HttpServletRequest	A servlet access request or SOAP message via HTTP javax.http.servlet.HttpServletRequest
com.bea.contextelement. servlet.HttpServletResponse	A servlet access response or SOAP message via HTTP javax.http.servlet.HttpServletResponse
com.bea.contextelement. wli.Message	A WebLogic Integration message. The message is streamed to the audit log. java.io.InputStream
com.bea.contextelement. channel.Port	Internal listen port of the network channel accepting or processing the request java.lang.Integer
com.bea.contextelement. channel.PublicPort	External listen port of the network channel accepting or processing the request java.lang.Integer
com.bea.contextelement. channel.RemotePort	Port of the remote end of the TCP/IP connection of the network channel accepting or processing the request java.lang.Integer
com.bea.contextelement. channel.Protocol	Protocol used to make the request of the network channel accepting or processing the request java.lang.String
com.bea.contextelement. channel.Address	The internal listen address of the network channel accepting or processing the request java.lang.String
com.bea.contextelement. channel.PublicAddress	The external listen address of the network channel accepting or processing the request java.lang.String
com.bea.contextelement. channel.RemoteAddress	Remote address of the TCP/IP connection of the network channel accepting or processing the request java.lang.String
com.bea.contextelement. channel.ChannelName	Name of the network channel accepting or processing the request java.lang.String
com.bea.contextelement. channel.Secure	Whether the network channel is accepting or processing the request using SSL java.lang.Boolean
com.bea.contextelement. ejb20.Parameter[1-N]	Object based on parameter
com.bea.contextelement. wsee.SOAPMessage	javax.xml.rpc.handler.MessageContext
com.bea.contextelement. entitlement.EAuxiliaryID	Used by a WebLogic Server internal process. weblogic.entitlement.expression.EAuxiliary
com.bea.contextelement. security.ChainPrevalidatedBySSL	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. java.lang.Boolean
com.bea.contextelement. xml.SecurityToken	Not used in this release of WebLogic Server. weblogic.xml.crypto.wss.provider.SecurityToken
com.bea.contextelement. xml.SecurityTokenAssertion	Not used in this release of WebLogic Server. java.util.Map
com.bea.contextelement. webservice.Integrity{id:XXXXX}	javax.security.auth.Subject
com.bea.contextelement. saml.SSLClientCertificateChain	SSL client certificate chain obtained from the SSL connection over which a sender-vouches SAML assertion was received. java.security.cert.X509Certificate[]
com.bea.contextelement. saml.MessageSignerCertificate	Certificate used to sign a Web Services message. java.security.cert.X509Certificate
com.bea.contextelement. saml.subject.ConfirmationMethod	Type of SAML assertion: bearer, artifact, sender-vouches, or holder-of-key. java.lang.String
com.bea.contextelement. saml.subject.dom.KeyInfo	<ds:KeyInfo> element to be used for subject confirmation with holder-of-key SAML assertions. org.w3c.dom.Element

Severity	Description
SUCCESS	A successful configuration change occurred.
FAILURE	An attempt to modify the configuration failed due to insufficient user credentials.
ERROR	An attempt to modify the configuration failed due to an internal error.

When This Event Occurs...	WebLogic Server Generates a Message With This ID...	And This Message Text...
Authorized user creates a resource.	159900	USER username CREATED MBean-name where username identifies the WebLogic Server user who logged in and created a resource.
Unauthorized user attempts to create a resource.	159901	USER username CREATED MBean-name FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user deletes a resource.	159902	USER username REMOVED MBean-name where username identifies the WebLogic Server user who logged in and deleted a resource.
Unauthorized user attempts to delete a resource.	159903	USER username REMOVE MBean-name FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user changes a resource's configuration.	159904	USER username MODIFIED MBean-name ATTRIBUTE attribute-name FROM old-value TO new-value where username identifies the WebLogic Server user who logged in and changed the resource's configuration.
Unauthorized user attempts to change a resource's configuration.	159905	USER username MODIFY MBean-name ATTRIBUTE attribute-name FROM old-value TO new-value FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user invokes an operation on a resource. For example, a user deploys an application or starts a server instance.	159907	USER username INVOKED ON MBean-name METHOD operation-name PARAMS specified-parameters where username identifies the WebLogic Server user who logged in and invoked a resource operation.
Unauthorized user attempts to invoke an operation on a resource.	159908	USER username INVOKED ON MBean-name METHOD operation-name PARAMS specified-parameters FAILED weblogic.management. NoAccessRuntimeException: exception-text stack-trace where username identifies the unauthorized WebLogic Server user.
Authorized user enables configuration auditing.	159909	USER username, Configuration Auditing is enabled where username identifies the WebLogic Server user who enabled configuration auditing.
Authorized user disables configuration auditing.	159910	USER username, Configuration Auditing is disabled where username identifies the WebLogic Server user who disabled configuration auditing.

Message Attribute	Attribute Value
Severity	Info
Subsystem	Configuration Audit
User ID	kernel identity This value is always kernel identity, regardless of which user modified the resource or invoked the resource operation.
Server Name	AdminServerName Because the Administration Server maintains the configuration data for all resources in a domain, this value is always the name of the Administration Server.
Machine Name	AdminServerHostName Because the Administration Server maintains the configuration data for all resources in a domain, this value is always the name of the Administration Server's host machine.
Thread ID	execute-thread The value depends on the number of execute threads that are currently running on the Administration Server.
Timestamp	timeStamp at which the message is generated.

When This Event Occurs...	WebLogic Server Generates This Audit Event Object...
A request to create a new configuration artifact has been allowed or prevented.	weblogic.security.spi. AuditCreateConfigurationEvent See Javadoc.
A request to delete an existing configuration artifact has been allowed or prevented.	weblogic.security.spi. AuditDeleteConfigurationEvent See Javadoc.
A request to modify an existing configuration artifact has been allowed or prevented.	weblogic.security.spi. AuditInvokeConfigurationEvent See Javadoc.
A invoke an operation on an existing configuration artifact has been allowed or prevented.	weblogic.security.spi. AuditSetAttributeConfigurationEvent See Javadoc.

Assertion Type	Description
bearer	The subject of the assertion is the bearer of the assertion, subject to optional constraints on confirmation using attributes that may be included in the <SubjectConfirmationData> element of the assertion. Used for all assertions generated for the SAML 2.0 Web Browser SSO Profile and with the Web Service Security SAML Token Profile 1.1.
sender-vouches	The identity provider (different from the subject) vouches for the verification of the subject. The receiver must have a trust relationship with the identity provider. Used with the Web Service Security SAML Token Profile 1.1 only.
holder-of-key	The subject represented in the assertion uses an X.509 certificate that may not be trusted by the receiver to protect the integrity of the request messages. Used with the Web Service Security SAML Token Profile 1.1 only.

Lookup String	Description
target:-:<endpoint-url>	Specifies that partner lookup is conducted for an exact match of the URL, <endpoint-url>. For example, target:-:http://www.avitek.com:7001/myserver/myservicecontext/myservice-endpoint specifies the endpoint that can be matched to this service provider, for which an assertion should be generated. This form of partner lookup string excludes the endpoint URL from being added as an Audience URI in the generated assertion.
target:+:<endpoint-url>	Specifies that partner lookup is conducted for an exact match of the URL, <endpoint-url>. Using the plus sign (+) in the lookup string results in the endpoint URL being added as an Audience URI in the assertion generated for this service provider partner.
target:*:<endpoint-url>	Specifies that partner lookup is conducted for an initial-string pattern match of the URL, <endpoint-url>. For example, target:*:http://www.avitek.com:7001/myserver specifies that any endpoint URL beginning with http://www.avitek.com:7001/myserver can be matched to this service provider, such as: http://www.avitek.com:7001/myserver/contextA/endpointA and http://www.avitek.com:7001/myserver/contextB/endpointB. If more than one service provider partner is discovered that is a match for the initial string, the partner with the longest initial string match is selected. This form of partner lookup string excludes the endpoint URL from being added as an Audience URI in the generated assertion.