Securing WebLogic Server

Configuring WebLogic Security Providers

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

WebLogic Server includes such a large number of Authentication providers and Identity Assertion providers that they are better handled in a separate section. For information about configuring Authentication providers and Identity Assertion providers, see Configuring Authentication Providers.

When Do I Need to Configure a Security Provider?

By default, most WebLogic security providers are generally configured to run out of the box. 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 creating a new security realm, configure security providers for that new realm. See Creating a New Security Realm: Main Steps.
When adding a custom security provider to a security realm or replacing one of the WebLogic security providers with a custom security provider, configure options for the custom security provider. When writing a custom security provider, you can implement options that are configurable through the WebLogic 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. For information about configuring a custom security provider, see "Configure a custom security provider in the Administration Console online help.

The remainder of this section contains conceptual information and configuration options for each security provider, other than the Authorization security providers, for which see Configuring Authentication Providers.

Configuring the WebLogic 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. By default, the WebLogic Authorization provider is configured. You should only need to configure a WebLogic Authorization provider when creating a new security realm.

See Configure Authorization providers in the Administration Console online help.

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. Note that in the Administration Console, the WebLogic Adjudication provider is referred to as the Default Adjudicator.

By default, most of the 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 WebLogic 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 WebLogic Role Mapping provider. You can use either the WebLogic Role Mapping provider or a custom Role Mapping provider in a security realm. Note that in the Administration Console, the WebLogic Role Mapping provider is referred to as the Default Role Mapper.

By default, most configuration options for the WebLogic 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 WebLogic Role Mapping provider in the embedded LDAP server.

For more information, see:

Users, Groups, And Security Roles in Securing WebLogic Resources
Role Mapping Providers in Developing Security Providers for WebLogic Server
Configure Role Mapping providers in the Administration Console online help

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.

By default, most configuration options for the WebLogic Auditing provider are already defined. However, when configuring the WebLogic Auditing provider, you need to define the following, which can be configured in the Administration Console on the Configuration: Provider Specific page for the provider, by using WebLogic Scripting tool or by using Java Management Extensions (JMX) APIs:

Severity—Specifies the 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. 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

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.

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. The WebLogic Auditing provider's Active ContextHandler Entries attribute determines 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	The internal listen port of the network channel accepting or processing the request `java.lang.Integer`
com.bea.contextelement. channel.PublicPort	The external listen port of the network channel accepting or processing the request `java.lang.Integer`
com.bea.contextelement. channel.RemotePort	The 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	The 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	The remote address of the TCP/IP connection of the network channel accepting or processing the request `java.lang.String`
com.bea.contextelement. channel.ChannelName	The name of the network channel accepting or processing the request `java.lang.String`
com.bea.contextelement. channel.Secure	Is the network channel 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 WebLogic Server internal process. `weblogic.entitlement.expression.EAuxiliary`
com.bea.contextelement. security.ChainPrevalidatedBySSL	The 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	The 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	The certificate used to sign a Web Services message. `java.security.cert.X509Certificate`
com.bea.contextelement. saml.subject.ConfirmationMethod	The type of SAML assertion: bearer, artifact, sender-vouches, or holder-of-key. `java.lang.String`
com.bea.contextelement. saml.subject.dom.KeyInfo	The `<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 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. Because all configuration auditing messages are of the Info severity, they are not written to the domain-wide message log by default.

Enabling Configuration Auditing

You can do the following to enable configuration auditing:

Use the Administration Console. On the Configuration: General page for your domain, set the Configuration Audit Type. See 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 Trees 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-nameFAILED` `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-nameFAILED` `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-nameATTRIBUTE` `attribute-nameFROM` `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-nameATTRIBUTE` `attribute-nameFROM` `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` `ONMBean-nameMETHOD` `operation-namePARAMS` `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 ONMBean-nameMETHOD` `operation-namePARAMSspecified-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.

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:

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

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) are used to obtain an appropriate set of credentials to authenticate 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 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.

Creating Credential Mappings

You can create credential mappings using the Administration Console. To create a credential mapping for the WebLogic Credential Mapping provider:

In the left pane of the console, select Security Realm.

Expand Credential Mappings > Default and click New.

Enter information about the remote resource to be accessed using this credential mapping. This information is used to identify the remote resource and can include one or more of the following:

Protocol—The protocol to use to reach the remote resource.

Remote Host—The host name of the remote resource.

Remote Port—The port number of the remote resource.

Path—If the remote resource is identified by a path, rather than a hostname and port.

Method—The method on the remote resource this credential is used with.

Click Next.

Enter the name of the local user that you are mapping from. This is the WebLogic username that will be the initiator when you want to access the remote resource using this credential mapping.

Enter the name of the remote user that you are mapping to. This is the username that is authorized to access the resource using this credential mapping.

Enter the remote password required by the remote resource for the remote user you specified in the previous step.

Click Finish.

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 Creating PKI Credential Mappings.

PKI Credential Mapper Attributes

To configure the PKI Credential Mapping provider, set values for these attributes:

Keystore Provider—A provider for the Java Security API. If no value is provided for this attribute, the default provider class is used.
Keystore Type—Two types are supported, JKS (the default) and PKCS12.
Keystore Pass Phrase—The password used to access the keystore
Keystore File Name—The 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 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.

For more information, see Configure Credential Mapping providers in the Administration Console online help.

Creating PKI Credential Mappings

You can create credential mappings using the Administration Console. To create a credential mapping for the PKI Credential Mapping provider:

In the left pane of the console, select Security Realm.

Expand Credential Mappings > PKI and click New.

Enter information about the remote resource to be accessed using this credential mapping. This information is used to identify the remote resource and can include one or more of the following:

Protocol—The protocol to use to reach the remote resource.
Remote Host—The host name of the remote resource.
Remote Port—The port number of the remote resource.
Path—A path that identifies the remote resource.
Method—The method on the remote resource this credential is used with.

If all of these are left unspecified, then the credential mapping applies to all remote resources.
Click Next.

Select Key Pair or Certificate to indicate the type of credential you are mapping to.

Enter the name of the principal that you are mapping from. This is the WebLogic username that will be the initiator when you want to access the remote resource using this credential mapping.

Indicate whether the principal that you are mapping from is a user or a group.

Optionally, specify a credential action. See Credential Actions.

Enter the alias used in the keystore to identify the credential.

If this is a Key Pair credential, enter the password used to retrieve the credential from the keystore.

Click Finish.

Credential Actions

You can optionally label a credential mapping with a Credential Action. The Credential Action is an arbitrary string that you can use to distinguish credential mappings used in different circumstances. For example, you might have one credential mapping used for decrypting a message from a remote resource and another credential mapping used to 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.

Configuring a SAML Credential Mapping 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. You can configure the provider to add user information and group membership to the AttributeStatement contained in the assertion, which then can be used as part of the asserted identity. Note that you can define default values in the SAML Credential Mapping provider for generating attributes in assertions and override those values for particular classes of assertions in the assertion configuration, as described in Produced Assertion Configuration.

For general information about WebLogic Server's support for SAML, see Securlity 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.

SAML Authority Configuration

These attributes configure the SAML Credential Mapping provider as a SAML authority.

Table 4-8 Source Site Configuration Attributes

Attribute	Description
Issuer URI	The value of the Issuer attribute for SAML assertions generated by the SAML Credential Mapping provider.
Name Qualifier	The Name Qualifier value used by the Name Mapper. This value is the security or administrative domain that is appended to the name of the subject.
Default Time To Live	The assertion lifetime, in seconds. Bearer and artifact assertions must have a non-zero (but hopefully short) time-to-live value. Sender-vouches and holder-of-key assertions may specify 0 to indicate that the `NotBefore` and `NotOnOrAfter` conditions should be omitted from the assertion.
Default Time To Live Delta	If non-zero, allow for clock skew between source site and destination site when evaluating assertion lifetimes. A value of -N allows for accepting assertions up to N seconds before their `NotBefore` time; a value of +N allows for accepting assertions up to N seconds after their `NotOnOrAfter` time; and a value of N allows for accepting assertions up to N seconds before or after their validity period.

Source Site Configuration

These attributes configure the SAML Credential Mapping provider as a SAML source site:

Table 4-9 Source Site Configuration Attributes

Attribute	Description
Source Site URL	The SAML source site URL, which participates in SAML SSO. A SAML `SourceID` is automatically generated from this URL.
Intersite Transfer URIs	The URIs that provide the Intersite Transfer Service for Artifact and POST profiles. The default values are: `/samlits_ba/its/post` `/samlits_ba/its/artifact` `/samlits_cc/its/post` `/samlits_cc/its/artifact`

Attribute

Description

Source Site URL

The SAML source site URL, which participates in SAML SSO. A SAML SourceID is automatically generated from this URL.

Intersite Transfer URIs

The URIs that provide the Intersite Transfer Service for Artifact and POST profiles. The default values are:

/samlits_ba/its/post

/samlits_ba/its/artifact

/samlits_cc/its/post

/samlits_cc/its/artifact

POST Profile Configuration

These attributes configure the SAML Credential Mapping provider for the POST SAML profile:

Table 4-10 POST Profile Configuration Attributes

Attribute	Description
Post Enabled	Enables the use of Artifact profile. If this is true, then the ITS servlet will be deployed and will respond to incoming SAML POST profile requests.
Default Post Form	The path name of the form to use in POST profile assertions. WebLogic Server includes a default form for this purpose, which you may want to replace with a form that uses your own branding or other information. Additionally, you can override this default for `bearer` type assertions, using the PostForm assertion configuration attribute.

Artifact Profile Configuration

These attributes configure the SAML Credential Mapping provider for the Artifact SAML profile:

Table 4-11 Artifact Profile Configuration Attributes

Attribute	Description
Artifact Enabled	Enables the use of Artifact profile. If this is true, then the ITS servlet will be deployed and will respond to incoming SAML Artifact profile requests.
Assertion Retrieval URIs	One or more URIs to which the SAML Credential Mapping provider should listen for incoming assertion retrieval requests. The default is `/samlars/ars`.
Assertion Store Class Name	The class that acts as the persistent store for Artifact profile assertions. An Assertion Store is required for Artifact profile, so that when assertion retrieval requests come in, the corresponding assertion can be located. You can use a custom class that implements `weblogic.security.providers.saml.SAMLAssertionStore`. If you do not designate a custom class, the default class will be used.
Assertion Store Properties	These properties, if provided, will be passed to the `initStore()` method of your custom Assertion Store class.

Produced Assertion Configuration

The following settings are used to configure individual assertions produced by the SAML Credential Mapping provider. You can configure the SAML Credential Mapping provider with any number of assertions, allowing the Credential Mapper to generate different assertions for different purposes. You configure assertions with Java-style properties, in key=value format. The key takes the form assertionName.propertyName.

Table 4-12 Produced Assertion Configuration Properties

Property	Description
Assertions	The names assigned to these assertion configurations.
AssertionType	One of: `bearer`, `artifact`, `sender-vouches`, `holder-of-key`.
Target	For `bearer` and `artifact` assertions, the destination site URL for which authentication is desired. The Identity Asserter uses the target URL, in conjunction with the assertion type and issuer URL, to identify the assertion configuration against which the assertion should be validated. This attribute is ignored for `sender-vouches` and `holder-of-key` assertions.
ConsumerURL	For bearer and artifact assertions only, the URL to which the assertion or artifact should be posted or redirected.
PostForm	The POST form template to use with POST profile. This value overrides the default form setting in the SAML source site configuration. Ignored for assertion types other than `bearer`.
TimeToLive	The assertion lifetime, in seconds. Bearer and artifact assertions must have a non-zero (but hopefully short) TTL value. Sender-vouches and holder-of-key assertions may specify 0 to indicate that the `NotBefore` and `NotOnOrAfter` conditions should be omitted from the assertion.
TTLDelta	If non-zero, allow for clock skew between source site and destination site when evaluating assertion lifetimes. A TTLDelta value of -N allows for accepting assertions up to N seconds before their `NotBefore` time; a value of +N allows for accepting assertions up to N seconds after their `NotOnOrAfter` time; and a value of N allows for accepting assertions up to N seconds before or after their validity period.
AudienceURI	An audience URI to include in the assertion. Optional for all assertion types.
Signed	If `true`, assertions will be signed. If `false`, signature elements will be ignored. Signing is optional for all assertion types, but the SAML Token Profile specifies that holder-of-key assertions used for WSS should be signed.
SigIncludeCerts	If `true`, include signing certificates in the signature element.
NameMapperClass	If this attribute is present, then the Credential Mapping provider will use the specified `SAMLCredentialNameMapper` class instead of the default Name Mapper.
IncludeGroups	If `true`, include in the assertion an Attribute Statement containing WebLogic Server groups.

Example of Produced Assertion Configuration

Listing 4-1 is an example of how you might configure produced assertions. It includes both a POST profile assertion, named mypost, and an Artifact profile assertion, named myart.

Listing 4-1 Produced Assertion Configuration

Assertions=mypost,myart

mypost.AssertionType=bearer

mypost.Target=http://www.destination_site.com:7001/targets/PostTarget.jsp

mypost.ConsumerURL=https://www.destination_site.com:7002/samlacs/acs

mypost.IncludeGroups=true

myart.AssertionType=artifact

myart.Target=http://www.destination_site.com:7001/targets/Art*

myart.ConsumerURL=https://www.destination_site.com:7002/samlacs/acs

Configuring the Credential 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, that 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, see Configuring 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. It is a CertPathBuilder and a 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 realms, 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.

For more information, see Configure Certification Path providers in the Administration Console online help.

Configuring a WebLogic Keystore Provider

Note: The WebLogic Keystore provider is deprecated in this release of WebLogic Server. 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.