Default binding
The default binding information is defined in the ws-security.xml file and can be administered by either the console or by scripting.
There is an important distinction between V5.x and V6 and later applications. The information in this article supports version 5.x applications only that are used with WAS V6.0.x and later. The information does not apply to V6 and later applications. Certain applications can share certain binding information. This information includes truststores, keystores, and authentication methods (token validation). WAS provides support for default binding information. Administrators can define binding information at:
- The server level
- The cell level
Applications can refer to this binding information.
You can define the following binding information in the ws-security.xml file:
- Trust anchors (truststore)
-
- Trust anchors contain key store configuration information that has the root-trusted certificates. Trust anchors are used for certificate path validation of the incoming X.509-formatted security tokens.
- The Trust Anchor Name is used in the binding file (ibm-webservices-bnd.xmi and ibm-webservicesclient-bnd.xmi when Web services is running as a client) to refer to the trust anchor defined in the default binding information. The trust anchor name must be unique in the trust anchor collection.
- Trust anchors contain key store configuration information that has the root-trusted certificates. Trust anchors are used for certificate path validation of the incoming X.509-formatted security tokens.
- Collection certificate store
-
- The collection certificate store specifies a list of untrusted, intermediate certificates and is used for certificate path validation of incoming
X.509-formatted security tokens. The default provider is IBMCertPath.
- The Certificate Store Name is used in the binding file (ibm-webservices-bnd.xmi and ibm-webservicesclient-bnd.xmi when Web services is running as a client) to refer to the certificate store defined in the default binding information. The Certificate Store Name must be unique to the collection certificate store collection.
- The collection certificate store specifies a list of untrusted, intermediate certificates and is used for certificate path validation of incoming
X.509-formatted security tokens. The default provider is IBMCertPath.
- Key locators
-
- Key locators specify implementation of the com.ibm.wsspi.wssecurity.config.KeyLocator interface. This interface is used to retrieve keys for signature or encryption.
Customer implementations can extend the key locator interface to retrieve keys using other methods. WAS provides implementations to retrieve a key from the key store, map an authenticated identity to a key in the key store, or retrieve a key from the signer certificate (mapping and retrieving actions are used for encrypting the response).
- The Key Locator Name is used in the binding file (ibm-webservices-bnd.xmi and ibm-webservicesclient-bnd.xmi when Web services is running as a client) to refer to the key locator defined in the default binding information. The Key Locator Name must be unique to the key locators collection in the default binding information.
- Key locators specify implementation of the com.ibm.wsspi.wssecurity.config.KeyLocator interface. This interface is used to retrieve keys for signature or encryption.
Customer implementations can extend the key locator interface to retrieve keys using other methods. WAS provides implementations to retrieve a key from the key store, map an authenticated identity to a key in the key store, or retrieve a key from the signer certificate (mapping and retrieving actions are used for encrypting the response).
- Trusted ID evaluators
-
- Trusted ID evaluators are an implementation of the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator interface. This interface is used to make sure the identity (ID)-asserting authority is trusted. Additionally, you can extend the trusted identity evaluator to validate the trust. WAS provides a default implementation for validating trust based on a predefined list of identities.
- The Trusted ID Evaluator Name is used in the binding file (ibm-webservices-bnd.xmi) to refer to the trusted identity evaluator defined in the default binding information. The Trusted ID Evaluator Name must be unique to the Trusted ID Evaluator collection.
- Trusted ID evaluators are an implementation of the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator interface. This interface is used to make sure the identity (ID)-asserting authority is trusted. Additionally, you can extend the trusted identity evaluator to validate the trust. WAS provides a default implementation for validating trust based on a predefined list of identities.
- Login mappings
-
- Login mappings define the mapping of the authentication method to the JAAS login configuration.
The mappings are used to authenticate the incoming security token embedded in the Web services security SOAP message header. The JAAS login configuration is defined in the console under Security > Secure administration, applications, and infrastructure > Java Authentication and Authorization Service
> Application logins.
- WAS defines the following authentication methods:
- BasicAuth
- Authenticates user name and password.
- Signature
- Maps the subject distinguished name (DN) in the certificate to a WebSphere Application Server credential.
- IDAssertion
- Maps the identity to a WAS credential.
- LTPA
- Authenticates a token.
- This method can be extended to authenticate custom security tokens by providing a custom JAAS login configuration and by using the com.ibm.wsspi.wssecurity.auth.module.WSSecurityMappingModule to create the principal and credential required by WAS.
- If LoginConfig (AuthMethod) is defined in the IBM extension deployment descriptor (ibm-webservices-ext.xmi), but there are no login mapping bindings (ibm-webservices-bnd.xmi) defined for the AuthMethod, Web services security run time uses the login mapping defined in the default binding information.
- Login mappings define the mapping of the authentication method to the JAAS login configuration.
The mappings are used to authenticate the incoming security token embedded in the Web services security SOAP message header. The JAAS login configuration is defined in the console under Security > Secure administration, applications, and infrastructure > Java Authentication and Authorization Service
> Application logins.
WebSphere Application Server ND
When the WebSphere Application Server is federated to a ND cell, the default binding file (ws-security.xml) of the server is added to the new cell (with other server level configuration information). If you use the cell-level default binding, the entries of the server level default binding must be removed. There is a cell-level default binding (ws-security.xml) for ND installation. Furthermore, for ND installation server-level binding is optional. To navigate to the cell-level default binding in the console, click Security > Web Services. Figure 1. Web services security application-level, cell-level, and server-level default binding information
The order of the default binding information is application-level binding, server-level, and cell-level default binding.
Related concepts
Trust anchors
Collection certificate store
Key locator
Trusted ID evaluator
Login mappings
BasicAuth authentication method
Identity assertion authentication method
Signature authentication method
LTPA
Related Reference
ws-security.xml file - Default configuration for WebSphere Application Server ND