You have to fulfill certain prerequisites for configuring Digest Authentication.

The host system on which the web service is deployed must be a WebLogic Server system configured with the embedded LDAP authentication provider (Default Authenticator). This is because the web service client sends a password in the form of a digest and, in order to authenticate it at the service side, the authentication provider must recreate the digest using the clear-text password, the nonce, and timestamp. The Default Authenticator is able to get the password in the required clear text.

There is no limitation for the digest-based client policies. The web service client to which they are attached can be run from all supported platforms.

You can configure the Default Authenticator and Default Identity Asserter from the Weblogic Server Remote Console.

1. Set the Enable Password Digests checkbox on the provider-specific page of the Default Authenticator. See Configure Authentication and Identity Assertion providers for more information.
2. Set wsse:PasswordDigest as an active type on the common page of the DefaultIdentityAsserter, as shown in Figure 11-1. See Configure Authentication and Identity Assertion providers for more information.

   Figure 11-1 wsee:PasswordDigest as Active Type

   
   Description of "Figure 11-1 wsee:PasswordDigest as Active Type"
3. Restart WebLogic Server.
4. Users created after you configure digest authentication can be authenticated using the digest based mechanism.

   However, users created before you configure digest authentication cannot be authenticated using the digest based mechanism because the WebLogic Server security runtime has already stored the password digests (rather than cleartext passwords) for the already-created users.

   You must recreate these users so that their cleartext password, and not their digest, is stored in the password database.

This section describes how to attach a policy and in turn enable digest authentication.

1. If you have not already done so, attach a copy of one of the web service policies that support digest authentication. See Attaching Policies to Manage and Secure Web Services for information about how to copy and attach a policy.
2. Open the policy and change the Password Type drop-down menu to Digest, as shown in Figure 11-2.

   Figure 11-2 Selecting Digest From the Password Type Drop-Down Menu

   
   Description of "Figure 11-2 Selecting Digest From the Password Type Drop-Down Menu"
3. Set the Creation Time Required control.
4. Set the Nonce Required control.
5. Repeat steps one through four for the client version of the policy.

The SAML login module verifies the SAML tokens on behalf of the web service. The SAML login module then extracts the username from the verified token and (indirectly) passes it to Oracle Platform Security Services (OPSS) to complete the authentication.

Any configured Authentication provider as described in Supported Authentication Providers in WebLogic Server can then be invoked.

For more information, refer to the following sections:

• Validating a SAML Assertion

• Use Cases for SAML Token Validation

You have to configure the username for SAML assertion.

Map<String,Object>  reqContext = ((BindingProvider) proxy).getRequestContext()   reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe")

You can use configuration property to add user attributes to the SAML assertion.

1. In the Target Navigation pane, expand WebLogic Domain to show the domain for which you need to configure the identity store provider. Select the domain.
2. From the WebLogic Domain menu, select Security, and then Security Provider Configuration.
3. In the Identity Store Provider section of the page, click Configure to configure parameters that interact with the identity store.

   The Identity Store Configuration page is displayed, as shown in Figure 11-3.

   Figure 11-3 Identity Store Configuration Page

   
   

   
   Description of "Figure 11-3 Identity Store Configuration Page"

   
   
4. Click Add to add a custom property.

   The Add New Property window is displayed.

5. Add the property "virtualize" with a value of "true" as shown in Figure 11-4.

   Figure 11-4 Adding the virtualize property

   
   

   
   Description of "Figure 11-4 Adding the virtualize property"

   
   
6. Click OK to submit the changes.
7. Click OK on the Identity Store Configuration page.
8. Restart the server.

You can pass the user's role as an attribute statement in the SAML assertion

You have to configure OPSS for the predefined SAML policies.

To configure OPSS for the predefined SAML policies, follow these steps:

1. Configure the SAML login module, as described in Configuring the SAML and SAML2 Login Modules Using Fusion Middleware Control.

   By default, the SAML assertion issuer name is www.oracle.com. The saml.issuer.name client property must be www.oracle.com if you are using the predefined SAML policies (or assertions) on both the web service client and web service sides. Therefore, you can generally use the defaults and not configure any issuer.

   See Adding an Additional SAML Assertion Issuer Name for information on adding an additional issuer.

2. Configure the Authentication provider in the WebLogic Server Remote Console.

3. If you will be using policies that involve signatures related to SAML assertions (for example, SAML holder-of-key policies) where a key referenced by the assertion is used to sign the message, or sender-vouches policies where the sender's key is used to sign the message, you need to configure keys and certificates for signing and verification, as described in Overview of Configuring Keystores for Message Protection.

4. If you will be using policies that require SSL, you need to configure SSL, as described in About Configuring Keystores for SSL.

There are three scenarios in which you need to add additional issuers to the trusted issuers list.

1. In the Target Navigation pane, expand WebLogic Domain to show the domain for which you need to add the issuer. Select the domain.
2. In the content pane, select WebLogic Domain, then Security, and then Security Provider Configuration.
3. In the Login Modules section, select the SAML or SAML2 login module as appropriate and click Edit.

   The Edit Login Module page is displayed.

4. In the SAML Specific Attributes section of the page, click Add.
5. In the Add Issuer window, enter the issuer name in the Issuer field and click OK.
6. Restart the server.
7. Configure the issuer in the client policy as follows:

   • Post-deployment, specify a configuration override value for the saml.issuer.name property in an attached SAML client policy. If you cloned a predefined Oracle SAML client policy, you can set the value in the saml.issuer.name configuration property before attaching the policy.

   • At design time, set the saml.issuer.name property in the BindingProvider.

Identity switching means that the policy propagates a different identity than the one based on the authenticated Subject.

OWSM includes the wss11_saml_token_identity_switch_with_message_protection_client_policy policy that enables identity switching. Identity switching means that the policy propagates a different identity than the one based on the authenticated Subject. To explore more about identity switching, view the following topics:

• Understanding Identity Switching Use Case Scenarios

• Setting the javax.xml.ws.security.auth.username Property

• Setting the Permission Using WSIdentityPermission

You can define a list of trusted distinguish names (DNs) for SAML signing certificates for additional security.

By default, OWSM checks the incoming issuer name against the list of configured issuers, and checks the SAML signature against the configured certificates in the OWSM keystore. If you define a trusted DNs list, OWSM also verifies that the SAML signature is signed by the particular certificate(s) that is associated with that issuer.

Configuration of the trusted DNs list is optional; it is available for users that require more fine-grained control to associate each issuer with a list of one or more signing certificates. If you do not define a list of DNs for a trusted issuer, then OWSM allows signing by any certificate, as long as that certificate is trusted by the certificates present in the OWSM keystore.

For more information about defining a trusted DNs list for SAML signing certificates, see SAML Trusted Issuers and DN Lists Using Fusion Middleware Control.

Allowing anonymous users over SAML is provided as a convenience so that you can have one policy that supports both authenticated and anonymous users.

All SAML policies allow anonymous users to be propagated. For example, if you have an ADF application that can work with either authenticated users or an anonymous user, and this ADF application needs to make a call to a web service and propagate the current user, then you can propagate both the authenticated users and the anonymous user using any of the SAML policies. From the security perspective, propagating the anonymous user over SAML is equivalent to the client not sending any authentication tokens to the service.

Allowing anonymous users over SAML is provided as a convenience so that you can have one policy that supports both authenticated and anonymous users. Note, however, that anonymous propagation over SAML is non-standard and will not interoperate with other vendors. It should only be used when both the client and the web service are using OWSM.

Identity Context secures access to resources using traditional security controls (such as roles and groups) and as dynamic data established during authentication and authorization (such as authentication strength, risk levels, device trust, and so on).

For example, an application could use Identity Context to:

• Disable a particular business function if the user is not authenticated using a strong credential such as smart card.

• Secure access to a transaction based on the identity data supplied by a business partner (by using Identity Federation) with whom the organization does business.

• Request additional authentication credentials if it detects that access is originating from a location known for fraudulent activities.

• Limit the scope of administrative authority if the Administrator's industry certification (as maintained by a third party) has expired.

• Disable certain business functions if it detects that access is originating from an unknown device.

OWSM can propagate the Identity Context from the web service client to the web service, and then make it available ("publish it") to other components for authentication and authorization purposes.

The Identity Context is opaque to your web service client and web service, and you need not perform any additional coding or processing in your web service client or web service to support it once you enable Identity Context propagation for your policies.

For more information on Identity Context, configuring the Identity Context Service, and using the Identity Context API, see "Using Identity Context" in Administrator's Guide for Oracle Access Management.

OWSM propagates the Identity Context from web service clients to web services via SAML 1.1 or SAML 2.0 assertions.

You can specify a value on the Configurations page in the policy or override it when you attach the policy.

1. In the Target Navigation pane, expand WebLogic Domain and select the domain for which you need to configure identity context propagation.
2. From the WebLogic Domain menu, select Web Services, then WSM Policies.
3. Select the cloned SAML policy for which you want to enable identity context propagation and click Open.

   Remember that you have to enable identity context propagation for both the web service client and web service policies.

4. Select the Assertions tab.
5. Click Configuration.

   The Configuration page displays a list of the configuration properties for the policy.

6. Enter true in the Value field for the propagate.identity.context property.
7. Click OK.

   Figure 11-6 Setting the propagate.identity.context Property to True

   
   

   
   Description of "Figure 11-6 Setting the propagate.identity.context Property to True"

   
   
8. Click Save to submit the changes.
9. Repeat Steps 3 and 8 for the corresponding client or service policy, as appropriate.
10. Attach the policy to the desired endpoints as described in Attaching Policies to Manage and Secure Web Services.

You can use MIT Kerberos as your KDC.

This section describes the following tasks when using MIT Kerberos as your KDC:

• Initializing and Starting the MIT Kerberos KDC

• Creating Principals

• Configuring the Web Service Client to Use the Correct KDC

You can use Microsoft Active Directory with Key Distribution Center (KDC) as your KDC.

This section describes how to configure the KDC through Active Directory for use with Kerberos and message protection.

This section assumes that you are already familiar with Active Directory. See your Active Directory documentation for additional details.

This section describes the following topics:

• Web Service Client Set Up Tasks

• Setting Up the Web Service

The web service client that is enforcing Kerberos client-side policies needs to know the service principal name of the service it is trying to access.

JAX-WS Clients: 
((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSS_KERBEROS_SERVICE_PRINCIPAL, 
SOAP/myhost.example.com@example.com);

Configure the web service to authenticate against the correct KDC.

You should use the correct keytab file in Enterprise Manager.

To use the correct keytab file, you

• Extract and install the keytab File

• Export the keytab file

• Modify the krb5 login module

These tasks are described in the following sections:

• Extracting the Keytab File

• Exporting the Keytab File

• Modifying the krb5 Login Module to use the Keytab File

The web services runtime must be able to verify the validity of the kerberos token.

You can create a ticket cache for the web service client.

1. Log in to the Kerberos system using the user principal you created for the client.

   >kinit fmwadmin password
   

2. This creates a ticket cache on the file system with ticket granting ticket. To see this:

   >klist -e

   Information similar to the following is displayed:

   Credentials cache: /tmp/krb5cc_36687
   Default principal: fmwadmin@example.com, 1 entry found.
   [1]  Service Principal:  krbtgt/example.com@example.com
        Valid starting:  Sep 28, 2007 17:20
        Expires:         Sep 29, 2007 17:20
            Encryption type: DES3 CBC mode with SHA1-KD
   

   Make sure the encryption type reflects what is shown above.

3. Run the web service client.

The two basic assertion templates for Kerberos, oracle/wss11_kerberos_token_client_template and oracle/wss11_kerberos_token_service_template, provide authentication using Kerberos tokens but do not provide any form of message protection.

OWSM provides the following assertion templates that add message protection using SSL transport-level security to the basic authentication using Kerberos tokens:

• oracle/wss11_kerberos_token_over_ssl_client_template

• oracle/wss11_kerberos_token_over_ssl_service_template

To use these assertion templates, you need to configure SSL, as described in About Configuring Keystores for SSL.

These assertions use the Kerberos token for authentication and for signing the timestamp, and rely on underlying One-Way SSL transport for message protection. They advertise the Kerberos token as an EndorsingSupportingToken.

SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) is a standard that enables a client and a service to negotiate a method to use for authentication. Because SPNEGO uses HTTP headers to perform the negotiation, it is especially useful in a cross-platform context such as the web.

For more information on using Kerberos with SPNEGO, see "Kerberos and SPNEGO" in Understanding Oracle Web Services Manager.

OWSM provides the following assertion templates to enable clients and services using SPNEGO negotiation to use Kerberos for authentication:

• oracle/http_spnego_token_client_template

• oracle/http_spnego_token_service_template

These assertion templates can be used by policies attached to SOAP or REST endpoints.

You can use these assertion templates to create a new policy, or to add a SPNEGO assertion to an existing multi-token policy. For more information about creating policies or adding an assertion to a policy, see the following sections:

• Creating a New Web Service Policy

• Adding Assertions to a Policy

Kerberos includes a feature called credential delegation to support scenarios where a client request demands that one service use a second service (on behalf of the client) to satisfy the request. To satisfy such scenarios, the client provides the first service with a forwarded TGT (ticket granting ticket) that the first service uses to obtain a service ticket for the second service from the KDC.

For more information on credential delegation, see "Credential Delegation in Kerberos" in Understanding Oracle Web Services Manager.

To configure credential delegation, you must perform these tasks:

• Configure Kerberos to allow credential delegation.

• Configure the domain where the client is deployed to allow OWSM to forward a Kerberos ticket to the service on behalf of the client.

• Enable credential delegation in the client policy and the service policy.

When using credential delegation with a service in active directory, you must also configure the service's SPN account to be trusted for delegation.

The following subsections describe these tasks:

• Configuring Credential Delegation in Kerberos

• Configuring Delegation Permission to OWSM

• Enabling Credential Delegation in the Client Policy and the Service Policy

• Configuring Credential Delegation for a Service in Active Directory

• Configuring Credential Delegation With An Example

The WS-Trust 1.3 specification defines extensions to WS-Security that provide a framework for requesting and issuing security tokens, and to broker trust relationships. WS-Trust extensions provide methods for issuing, renewing, and validating security tokens.

To secure communication between a web service client and a web service, the two parties must exchange security credentials. As defined in the WS-Trust specification, these credentials can be obtained from a trusted Security Token Service (STS), which acts as trust broker. That is, the web service client and the web service do not explicitly trust each other; instead, they implicitly trust each other because they both trust the STS.

When using an STS as a trust broker, authentication proceeds as follows:

1. The web service client authenticates itself to the STS and requests a security token to be issued to it. This is called the RequestSecurityToken (RST) message.

2. The STS confirms the web service client's credentials and then responds to the security token request. This is called the RequestSecurityTokenResponse (RSTR) message.

3. The web service client presents to the web service the security token that the STS issued to it.

4. The web service confirms the validity of the issued security token.

Upon successful completion of this process, the web service client can make requests to the web service.

When OWSM is used to manage authentication, the actual process to achieve the preceding generic process is as follows:

1. The web service client wants to invoke a web service. The OWSM agent attempts to fetch the WSDL of the web service and extract the issued token service policy. The OWSM agent uses the local client policy (as optionally overridden) to talk to the STS identified in the WSDL.

   The web service policy can require the issued token to be from a specific STS.

2. The OWSM agent issues an RST to the STS.

3. The STS responds with an RSTR.

4. The OWSM agent processes the RSTR sent by the STS and propagates the issued token to the web service.

5. The OWSM agent servicing the web service processes and verifies the issued token and generates a response back.

Web Services Federation

In acting as a trust broker, an STS provides two main services:

• It issues tokens to authenticated web service clients

• It validates tokens as requested by web services

Additionally, an STS can accept a token issued by another STS and issue its own token based on the received token's content, provided that it trusts the other STS. This ability of STSes to trust each other and to transform issued tokens enables federated trust across security domains, which is called web services federation.

As an example, a web service client in one security domain wants to invoke a web service that is in another security domain. If the there is an STS in each domain, and they trust each other, the web service client can invoke the web service as follows:

1. The web service client authenticates itself to the STS in its security domain and requests a security token to be issued to it. This STS is called the Identity Provided STS, or IP-STS.

2. The IP-STS confirms the web service client's credentials and then responds to the security token request, providing an issued token.

3. The web service client presents the issued token from the IP-STS to the STS in the web service's security domain and request a security token be issued to it. This second STS is called the Relying Party STS, or RP-STS.

4. The RP-STS confirms the validity of the issued token from the IP-STS. Using data from the IP-STS's token, it creates its own token and provides it to the web service client.

5. The web service client presents to the web service the issued token from the RP-STS.

6. The web service confirms the validity of the issued token from the STS that it trusts, the RP-STS in its own security domain.

The preceding process shows how a web service client can communicate with a web service in a different security domain due to the trust shared between STSes in the two domains. However, this shared trust between STSes can be extended even further: if the IP-STS and the RP-STS do not trust each other directly, but share trust with the same intermediary STS, a chain of trust can be formed from the IP-STS to the intermediary STS to the RP-STS. Moreover, additional intermediary STSes can be positioned between the IP-STS and the RP-STS, provided that a chain of trust can be traced from the IP-STS to the RP-STS.

For information about using OWSM to configure web services federation, see About Configuring Web Services Federation.

OWSM provides a standard WS-Trust client. This client has been certified to interoperate with the following Security Token Services.

Token lifetime and token caching is detailed in this section.

The RSTR response message from an STS may contain a lifetime element (<trust:Lifetime>) indicating the validity of the returned token. If the lifetime element is present, OWSM validates the timestamp and rejects the message if the response has expired.

Additionally, OWSM supports caching of returned tokens. The configuration property issued.token.lifetime in issued token client policies control caching of returned tokens.

When making a request to STS, OWSM requests a lifetime for returned tokens for the period specified by issued.token.lifetime in the RST request message to an STS.

If the STS returns a token lifetime value different from the requested issued.token.lifetime value, OWSM uses the return value as the period for caching returned tokens. If the STS returns an empty token expiry value, OWSM does not cache returned tokens.

Thus, the issued.token.lifetime property is used only to request a particular lifetime for returned tokens. The STS is not obligated to honor the value, and OWSM performs token caching based on the actual lifetime value returned by the STS.

If you do not provide a value for issued.token.lifetime, OWSM uses the domain default value of 28800000 milliseconds (eight hours). To change this domain default value, see Configuring the Lifetime for the Issued Token Using Fusion Middleware Control.

Automatic Policy Configuration dynamically generates the information about the STS by parsing the STS WSDL document.

When the STS config policy is attached to the web service (and not to the client) Automatic Policy Configuration happens at run time on the first connect from client to server.

The only information you provide in the STS config policy (oracle/sts_trust_config_service_policy) is the port URI of the target STS. When this policy is attached to the web service (along with the issued token service policy) the port-uri of the STS appears as the Issuer-Address in the IssuedToken assertion of the web service WSDL.

As a result, OWSM obtains the other STS information (target namespace, service name, endpoint, and so forth) by accessing the STS WSDL and is saved in memory as the STS config. This information is saved in memory but is not persisted in MDS.

This section describes the following topics:

• Understanding the Requirements for Automatic Policy Configuration

• Main Steps in Setting Up Automatic Policy Configuration

• Manually Configuring the STS Config Policy From the Web Service Client: Main Steps

You have to configure web services, web service clients and STSes for web services federation.

The following sections describe how to configure web services, web service clients and STSes for web services federation:

• Configuring a Web Service for Web Services Federation

• About Configuring a Web Client for Web Services Federation

• Configuring an STS for Web Services Federation

In general, an STS returns tokens in the SAML assertion.

An STS generally returns one of the following kinds of tokens in the SAML assertion:

• SAML Holder of Key Symmetric. The SAML assertion that is returned by the STS is meant only for the particular client that sent its client token (username token, Kerberos, X509, etc) to the STS.

  A rogue client should not be allowed to steal this SAML assertion and use it. This is accomplished by a "proof key," which can be either symmetric or asymmetric.

  A symmetric proof key is generated on the STS side, or on the client side, or by taking inputs from both sides, as described in Determining the Proof Key for SAML HOK Only.

  The STS puts this symmetric proof key in the SAML HOK assertion in an encrypted form that only the web service can decrypt. Then, it signs the entire SAML assertion (including the encrypted proof key) and sends it to the client.

  When the client sends this SAML assertion to the server, it also needs to sign something with this proof key. The web service will at first verify the STS signature of the SAML assertion, extract the proof key from the SAML assertion, and then decrypt it and verify the client's signature. This client's signature "proves" to the server that the client has the proof key.

  Because this proof key is never sent in clear text, a rogue client cannot get it by network sniffing. Even if a rogue client gets the SAML assertion by network sniffing, it cannot make use of it, because it does not have the proof key and cannot sign with it. Therefore, the rogue client cannot prove to the server that it is allowed to use the SAML assertion.

• SAML Holder of Key Asymmetric. The asymmetric proof key works as follows.

  1. The client generates a public/private key pair.

  2. It keeps the private key and securely sends the public key to the STS along with its token (username token, Kerberos, X509, and so forth.)

  3. The STS verifies the client's token, and returns a SAML assertion containing the public key. The entire SAML assertion (including the public key) is signed by the STS and returned to the client.

  4. The client then sends a SAML HOK asymmetric assertion to a web service, and it signs something with the private key of that public-private key pair.

  5. The web service verifies the STS's signature of the SAML assertion, then extracts the public key from the SAML assertion and uses it to verify the client's signature.

     This client's signature proves to the web service that the SAML assertion is being used correctly, and was not stolen and replayed.

  Note:

  Unlike in the case of SAML HOK symmetric key, this public key in SAML HOK is not encrypted. This reduces the amount of configuration required on the STS side.

  For SAML HOK symmetric, the STS must be configured with each web service's certificate so that it can encrypt the symmetric key for that web service. This is not required for SAML HOK asymmetric.

  Also, the same SAML HOK asymmetric token can be sent to any web service because it is not encrypted with a particular web service's key.

  Note:

  Even though there is a public/private key pair, there is no certificate involved. That is, the public key is not sent to a Certificate Authority to request a certificate.

  Instead, the STS acts similar to a CA. A CA takes in a public key and returns a certificate. In this case, the STS takes in a public key and returns a SAML assertion.

  However, unlike a certificate whose lifetime is usually in many years, the SAML assertion issued by the STS usually has a lifetime of a few hours, after which the client would have to generate a new key pair and request a new SAML assertion.

  Because of this short life, there is no need for the revocation checking that is required for certificates. This makes it attractive on the client side, because there are no client keys to manage.

• SAML Bearer. The SAML bearer key has no proof key associated with it. Therefore, it must be used over SSL to prevent any rogue client from stealing and replaying it.

An STS typically returns a SAML HOK or SAML Bearer token. However, an STS can also return SAML sender vouches tokens.

SAML sender vouches has a completely different trust model. In HOK and Bearer the SAML assertion is issued by an STS and is signed by the STS. In this case, the web service does not trust the client directly, but it trusts the STS. When the web service receives an HOK or Bearer token, it verifies the signature against the trusted STS.

This indirect trust model greatly simplifies the trust store management. That is, if there are five clients talking to five web services using message protection, then each of the web services must know the five client public keys. However, if there an STS in between, the web services need to know only the public key of the STS.

For SAML sender vouches, the web service trusts the client directly. A SAML sender vouches token is typically directly generated by a client and signed by the client private key. However a client may choose to ask the STS to generate the token. The STS does not sign the SAML assertion in this case, and simply returns it to the client. The client signs the SAML sender vouches token as before and sends it to the web service. The web service is not aware that the client obtained the SAML sender vouches token from an STS and it checks the client signature.

To set up SAML sender vouches with WS-Trust, configure the web service without an issued token policy; that is, use the oracle/wss11_saml_token_with_message_protection_service_policy policy.

Configure the client with an issued token policy. Use the oracle/wss11_sts_issued_saml_with_message_protection_client_policy, which is meant for SAML sender vouches, and also an STS config policy.

The Automatic Policy Configuration feature (see Setting Up Automatic Policy Configuration for STS) cannot be used for SAML sender vouches because the web service WSDL will not have information about the STS.

"On Behalf Of" is an identity propagation use case, in which the web service client requests the STS token on behalf of another entity.

Consider the following scenario:

1. The web service client invokes the STS to get a token for another entity. This entity can be the end user or any other external entity. The entity's credentials are included in the RST in the onBehalfOf element.

2. The STS verifies the credentials presented by the web service client and issues a security token for the entity identified in the onBehalfOf element.

3. The web service client verifies the RSTR, extracts the token, and passes it to the web service.

4. The web service receives the SAML assertion for the end user and verifies that the token was issued by a trusted STS.

The "On Behalf Of" use case relies on the sts.auth.on.behalf.of.csf.key and on.behalf.of properties described in Oracle Web Services Manager Predefined Assertion Templates. If the "On Behalf Of" username is obtained from the Subject, it is a username without a password.

If sts.auth.on.behalf.of.csf.key identifies a CSF key for the "On Behalf Of" user entity, the identity established using that CSF key is sent on behalf of the other entity. It can be a username with or without a password.

You can set properties via programmatic configuration overrides for a given policy.

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

OWSM supports dynamic open id connect discovery to configure trust.

Discovery service provides a dynamic approach where a token is validated in real time without prior import of the keys or certificates which are used to sign tokens to configure trust . OWSM leverages OpenID provider metadata to configure trust dynamically.

OWSM supports token audience configuration in order to validate external tokens used by external identity providers differently.

OWSM validates a token audience, by ensuring that at least one of the audience values specified within the token matches, (or is a prefix of) the URL being called. In some cases, an external identity provider may use the audience claim/attribute differently, in such scenarios OWSM has the ability to specify one or more audience values which override the default audience values.

This override of the default audience value is done by configuring one or more audience values. OWSM considers the token to be valid if the audience value list in the token contains at least one value which matches any one of the configured values.

Token Audience Configuration helps to support Mobile Cloud Service (MCS) inter-work with external identity providers.