WS-Security troubleshooting tips


 

+

Search Tips   |   Advanced Search

 

To troubleshoot WS-Security, review the configurations with assembly tools to match the client and server request and the response configurations. These configurations must match. A client request sender configuration must match a server request receiver configuration. For encryption to successfully occur, the public key of the receiver must be exported to the sender and this key must be configured properly in the encryption information. For authentication, specify the method used by the client in the login mapping of the server.

The following includes a list of generic troubleshooting steps that we can perform.

 

Steps for this task

  1. Verify that the client security extensions and server security extensions match on each downstream call for the following senders and receivers:

  2. Verify that when the Add Created Time Stamp option is enabled on the client-side that the server has the Add Received Time Stamp option configured. You must configure the security extensions with an assembly tool.

  3. Verify that the client security bindings and the server security bindings are correctly configured. When the client authentication method is signature, make sure that the server has a login mapping.

    When the client uses the public key...

    cn=Bob,o=IBM,c=US

    ...to encrypt the body, verify that this Subject is a personal certificate in the server key store so that it can decrypt the body with the private key. Configure the security bindings using an assembly tool or the WAS admin console.

  4. Check SystemOut.log in...

    ${USER_INSTALL_ROOT}/logs/server

  5. Enable trace for WS-Security by using the following trace specification:

    com.ibm.xml.soapsec.*=all=enabled:com.ibm.ws.webservices.*=all=enabled: com.ibm.wsspi.wssecurity.*=all=enabled: com.ibm.ws.security.*=all=enabled: SASRas=all=enabled

    Type the previous three lines as one continuous line.

 

Errors when securing Web services

The following errors might occur when you secure Web services:

 

"CWWSS6811E: The key identifier <identifier name> retrieved from the message is different from the key identifier <identifier name> acquired from the keystore" key mismatch error message displays

 

Cause:

For WAS V7.0, the sample keystore files included with WAS have been updated because some of the certificates are due to expire. Therefore, the keys contained in V7.0, and the keys contained in WAS V6.1 Feature Pack for Web services, are incompatible. If the keys are used in a mixed cluster environment, a key mismatch error occurs. For example:

com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login. LoginException: CWWSS6811E: The key identifier TVpC640XSSc= retrieved from the message is different from the key identifier QdZLf+KjrUg= acquired from the keystore Path: PROFILE_HOME\AppSrv01 //etc/ws-security/samples/enc-receiver.jceks."

The keystore files included with WAS are intended as samples and should not be used in a production environment. However, if we use the sample files to test a mixed cluster environment, the files should be synchronized to prevent the key mismatch error. The keystore files are located in a sub-directory under the profile directory. For example:

$WP_PROFILE/etc/ws-security/samples/dsig-sender.ks

$WP_PROFILE/etc/ws-security/samples/dsig-receiver.ks

$WP_PROFILE/etc/ws-security/samples/enc-sender.jceks

$WP_PROFILE/etc/ws-security/samples/enc-receiver.jceks

$WP_PROFILE/etc/ws-security/samples/intca2.cer where $PROFILE_ROOT is the home directory for a particular instantiated WAS profile.

The sample keystore files are also located in the installation directory:

APP_ROOT/etc/ws-security/samples/dsig-sender.ks

APP_ROOT/etc/ws-security/samples/dsig-receiver.ks

APP_ROOT/etc/ws-security/samples/enc-sender.jceks

APP_ROOT/etc/ws-security/samples/enc-receiver.jceks

APP_ROOT/etc/ws-security/samples/intca2.cer where APP_ROOT is the location of the WAS installation.

 

Solution:

You can work around the key mismatch error by manually copying the keystore files from the V7.0 nodes in the mixed cluster to the V 6.1 Feature Pack for Web services nodes. This ensures that V 7.0 nodes and V6.1 Feature Pack for Web services nodes are using the same keystore files. Another workaround is to move the V 7.0 keystore files to a common directory location, then modify all bindings to point to the common location for the keystore files.

 

"CWWSI5061E: The SOAP Body is not signed" error message displays

 

Cause:

This error usually occurs whenever the SOAP security handler does not load properly, and does not sign the SOAP body. The SOAP security handler is typically the first validation that occurs on the server-side, so many problems can cause this message to display. The error might be caused by invalid actor URI configurations.

 

Solution:

You can configure the actor Universal Resource Identifier (URI) at the following locations within the assembly tool:

The actor information on both the client and the server must refer to the same string. When the actor fields on the client and the server match, the request or response is acted upon instead of being forwarded downstream. The actor fields might be different when we have Web services acting as a gateway to other Web services. However, in all other cases, verify that the actor information matches on the client and server. When the Web services implementation is acting as a gateway and it does not have the same actor configured as the request passing through the gateway, this Web services implementation does not process the message from the client. Instead, it sends the request downstream. The downstream process that contains the correct actor string processes the request. The same situation occurs for the response. Therefore, it is important that you verify that the appropriate client and server actor fields are synchronized.

Additionally, the error can appear when you do not specify that the body is signed in the client configuration. To sign the body part of the message using the Web service client editor in the assembly tool, click...

Security Extensions | Request Sender Configuration | Integrity

...and select the message parts to sign.

 

"CWWSI5075E: No security token found that satisfies any one of the authentication methods" error message displays

 

Solution:

Verify that the client and server login configuration information matches in the security extensions. Also, verify that the client has a valid login binding and that the server has a valid login mapping in the security bindings. We can check this information by looking at the following locations in the assembly tool:

Also, make sure that the actor URI specified on the client and server matches. Configure the actor URI at the following locations within the assembly tool:

 

"CWWSI5094E: No UsernameToken of trusted user was found or the login failed for the user while the TrustMode is BasicAuth" error message displays

 

Cause:

This situation occurs when we have IDAssertion configured in the login configuration as the authentication method.

 

Solution:

On the sending Web service, configure a trusted basic authentication entry in the login binding. Then, on the server side, verify that the trusted ID evaluator has a property set that contains the user name of this basic authentication entry. To configure the client for identity assertion, consult the following topics:

To configure the server for identity assertion, consult the following topics:

 

"CWSCJ0053E: Authorization failed for /UNAUTHENTICATED..." error message displays

 

Cause:

The following authorization error occurs with UNAUTHENTICATED as the security name: CWSCJ0053E: Authorization failed for /UNAUTHENTICATED while invoking (Home)com/ibm/wssvt/tc/pli/ejb/Beneficiary findBeneficiaryBySsNo(java.lang.String):2 securityName: /UNAUTHENTICATED;accessID: null is not granted any of the required roles: AgentRole

This situation occurs because a login configuration is not being configured or Web services Security is not configured from a client to a server. When the request arrives at the server and authentication information is not received, the UNAUTHENTICATED user is set on the thread. Authorization returns this error if there are any roles assigned to the resource except for the special "Everyone" role, which supports access by anyone.

If the client successfully authenticates to an EJB file, but the EJB file calls a downstream EJB file not configured with Web services security or transport security, such as HTTP user ID and password, an error can occur for this downstream request.

 

Solution: Using the assembly tool, verify that the EAR file for both client and server has the correct security extensions and security bindings.

See, consult the following topics:

 

"WSWS3243I: Info: Mapping Exception to WebServicesFault." error message is displayed when you specify the value type local name and the URI for a token consumer or the token generator

 

Cause: The Value type URI is not required for the following predefined value type local names:

 

Solution:

If we specify one of the previous value type local names, do not enter a value for the Value type URI field.

 

"Invalid URI: The format of the URI could not be determined" error message might display when you use a Microsoft .NET client that accesses a Web service for

 

Cause:

The following exception message might display when you use a Microsoft .NET client that accesses a Web service for WAS.

Invalid URI: The format of the URI could not be determined.

Exception type:

System.UriFormatException
at System.Uri.Parse()
at System.Uri..ctor(String uriString, Boolean dontEscape)
at System.Uri..ctor(String uriString)
at Microsoft.Web.Services2.SoapInputFilter.CanProcessHeader(XmlElement header, SoapContext context)
at Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMessage(SoapEnvelope envelope)
at Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope envelope)
at Microsoft.Web.Services2.InputStream.GetRawContent()
at Microsoft.Web.Services2.InputStream.get_Length()
at System.Xml.XmlScanner..ctor(TextReader reader, XmlNameTable ntable)
at System.Xml.XmlTextReader..ctor(String url, TextReader input, XmlNameTable nt)
at System.Xml.XmlTextReader..ctor(TextReader input)
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,
WebResponse response, Stream responseStream, Boolean asyncCall)

Within WAS, WS-Security is enabled and uses the ActorURI attribute. This error occurs because Microsoft .NET Web Services Enhancements (WSE) V2.0 Service Pack 3 does not support a relative URI value for the ActorURI attribute. WSE V2.0 Service Pack 3 supports an absolute URI for this attribute only.

 

Solution:

To work with a Microsoft .NET client, configure this attribute as an absolute URI. An example of an absolute URI is: abc: //myWebService. An example of a relative URI is: myWebService.

To configure ActorURI attribute for use with WAS, use the IBM assembly tool to complete the following steps:

  1. Open the Web Service Editor, click...

    Extensions tab | Server Service Configuration

  2. Enter the full absolute URI in the Actor field.

  3. Expand...

    Response Generator Service Configuration Details | Details

  4. Enter the full absolute URI in the Actor field.

 

"WSEC5502E: Unexpected element as the target element" error message displays

 

Cause: If the following error displays, the cause may be an X.509 token that is in a message, but doesn't have a matching token consumer configured. This error can occur on either consumer or provider JAX-RPC applications.

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken

The cause of this error is that either an X.509 token is configured, and an X.509v3 token is received, or an X.509v3 token is configured, and an X.509 token is received. This happens most often when receiving X.509v3 tokens from Microsoft .NET. To determine if this is the cause of the problem, follow these steps:

  1. Obtain a WS-Security trace for the process that is producing the message.

    See on how to implement the WS-Security trace, read the topic Tracing Web services.

  2. Check to see if the trace contains information about the incoming SOAP message:

    1. From the point of the exception, search backwards for the term soapenv:env.

    2. From that point, search backwards for the term X509.

    3. Note the type of the X.509 security token, either #X509 or #X509v3.

  3. If the trace does not contain information about the incoming SOAP message, for example, because the trace is incomplete, search backwards for the term Target's value type is, starting at the point of the exception. This search locates the part of the trace that shows which security token was being processed at the time of the error. Note the type of the security token, either #X509 or #X509v3.

  4. Check the type of X.509 security token specified in the consumer configuration:

    1. From the point of the exception, search backwards for the term WSSConsumerConfig.

    2. Now search forward for the term #X509.

    3. Note the type of the configured X.509 security token consumer, either #X509 or #X509v3.

  5. If the configured token consumer does not match the type of the incoming security token, then this confirms that a security token type mismatch is the cause of the error.

 

Solution:

The configured token consumer must match the type as specified for the inbound security token. If the cause of the error, as determined in the previous steps, is determined to be a security token type mismatch, then change either the consumer or the provider configuration for WS-Security to ensure that the token types match.

 

"WSEC6664E: Null is not allowed to PKIXBuilderParameters. The configuration of TrustAnchor and CertStoreList are not correct" exception displays

 

Cause:

The certificate path setting is not configured properly.

 

Solution: Configure the certificate path setting by completing the following steps:

  1. In the admin console, click Security > Web services.

  2. Under the Default consumer binding heading, click Signing information > configuration_name.

  3. Select either the Trust any or Dedicated signing information option.

    If we select the Dedicated signing information option, select both a trust anchor and a certificate store from the configurations that are provided in the drop-down lists.

  4. Click OK and Save to the master configuration.

 

"WSE567: The incoming Username token must contain both a nonce and a creation time for the replay detection feature" Microsoft .NET error displays

 

Cause:

In this scenario, we have a Web services client for WAS and a Microsoft .NET Web service. The Microsoft .NET Web service has a ws-security constraint for a username token configured.

The following exception is thrown from the Microsoft .NET server:

WSE567: The incoming username token must contain both a nonce and a creation time for the replay detection feature.

By default, the Microsoft .NET Web service validates the nonce and the timestamp for the username token. However, it is optional for you to configure the nonce and timestamp properties for a Web service client using WAS.

 

Solution: Complete the following steps to add the nonce and timestamp properties for a username token on a Web service client for WAS. These steps involve an assembly tool.

  1. Open the Web service client deployment descriptor and click the WS-Binding tab.

  2. Expand the Security Request Generator Binding Configuration > Token Generator sections.

  3. Click the name of the username token that you already created and click Edit.

  4. In the Properties section of the Token Generator window, click Add.

  5. Enter com.ibm.wsspi.wssecurity.token.username.addNonce in the Name field to provide the name of the nonce property.

  6. Enter true in the Value field.

  7. Click Add.

  8. Enter com.ibm.wsspi.wssecurity.token.username.addTimestamp in the Name field to provide the name of the timestamp property.

  9. In the Value field, enter true.

  10. Click OK and save the client deployment descriptor.

 

Java 2 Security exceptions occur when using the com.ibm.wsspi.wssecurity.auth.token package with Java 2 Security enabled

 

Cause:

An application creates Java 2 Security exceptions while using the com.ibm.wsspi.wssecurity.auth.token.* package when Java 2 Security is enabled.

New Java 2 permissions have been set for various public methods of the com.ibm.wsspi.wssecurity.auth.token.* package on WAS V6.1. If the application uses one of the public methods from these classes that are protected by Java 2 Security permissions and it does not have the appropriate permissions, the application will fail. The exception message provides information that identifies the classes and public methods that are affected with the corresponding new Java 2 Security permission.

 

Solution:

Grant permission in was.policy for the application:

  1. Use the PolicyTool to edit the policy files. Follow the appropriate steps for the operating system.

  2. Add all of the permissions to was.policy that gets packaged in the EAR file for the application. If we want finer granularity for the permissions in was.policy for the application, enable the permissions that are necessary for the application based upon the classes that we need. For example, to access only the methods for the X509BSToken, you would add the following permissions to was.policy:

    grant codeBase "file:${application}" {
    permission com.ibm.websphere.security.WebSphereRuntimePermission
    "wssecurity.X509BSToken.setBytes";
    permission com.ibm.websphere.security.WebSphereRuntimePermission
    "wssecurity.X509BSToken.setCert";
    permission com.ibm.websphere.security.WebSphereRuntimePermission
    "wssecurity.WSSToken.setTrusted";
    permission com.ibm.websphere.security.WebSphereRuntimePermission
    "wssecurity.WSSToken.addAttribute";
    permission com.ibm.websphere.security.WebSphereRuntimePermission
    "wssecurity.WSSToken.setUsedTokenConsumer";
    };

  3. Update was.policy in the EAR file for the application.

  4. Uninstall the application from WAS and reinstall it with the new EAR file and the updated was.policy file.

 

An exception might occur when integrity or confidentiality is asserted for a SOAP element

 

Cause:

If a client asserts integrity or confidentiality for a SOAP element but the element is missing from the message, an exception is issued.

If the client requires that the application of a signature or encryption to a SOAP element, the SOAP element must always be present. The presence of this element is not optional. For example, if the configuration specifies that integrity or confidentiality must be applied to the wscontext element. If wscontext is missing from the message, the following exception is issued:

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Objects to be processed not found with the dialect [http://www.ibm.com/websphere/webservices/wssecurity/dialect-was] and the keyword [wscontext]

 

Solution:

Client developers must assure that the SOAP elements they target for integrity or confidentiality are always present in the SOAP message. If we cannot assure that the SOAP element is always present, do not target the SOAP elements for integrity or confidentiality.

 

Client output exceptions caused by the difference in JSR-101 and JSR-109 models

 

Cause:

Sometimes client output exceptions are produced when running the client. The client output exceptions might be caused by the differences in the JSR-101 versus JSR-109 models.

We can configure any of the WS-Security constraints, such as: username token, X509 token, signing or encrypting the SOAP elements, and so on. For example, we can configure the username token on a WAS client and service. The client is configured to send a username token in the request, and the server is configured to expect a username token. But if the client does not send a username token, the server rejects the request. When the client does not perform a JNDI naming lookup, the client is probably not a JSR-109 client. If it is not a JSR-109 client, the client will not get the JSR-109 configuration information, including the security configurations, and the request will fail.

For the JSR-109 model, the invocation begins with the JNDI lookup, which allows the security configuration information to be attached. For the JSR-101 model, a JNDI lookup is not performed; the security configuration information cannot be attached.

 

Solution:

This behavior is not a problem with the JSR-101 and JSR-109 models. WS-Security does not provide the WAS security configuration information to a JSR-101 client. The WS-Security implementation works according to the following guidelines:

If the client requires WS-Security, it must be a JSR-109 client.

 

"WSSecurityCon E WSEC5514E: An exception while processing WS-Security message" error displays

 

Cause: The managed client has no access to the Web services deployment descriptor because the lookup() call did not use the JNDI. Without the lookup() call, the client cannot access the deployment descriptor. The WS-Security configuration is in the Web services deployment descriptor.

The following is a detail exception that is created:

00000046 WebServicesFa 1 com.ibm.ws.webservices.engine.WebServicesFault makeUserFault MakeUserFault: com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5720E: A required message part [body] is not signed.
at com.ibm.wsspi.wssecurity.SoapSecurityException.format(SoapSecurityException.java:143)
at com.ibm.ws.webservices.wssecurity.dsig.VerifiedPartChecker.invoke(VerifiedPartChecker.java:
263)
at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.checkRequiredIntegrity(WSSConsumer.java:
1430)
at com.ibm.ws.webservices.wssecurity.core.WSSConsumer.invoke(WSSConsumer.java:545)
at com.ibm.ws.webservices.wssecurity.handler.WSSecurityConsumerBase.invoke(WSSecurityConsumerB
ase.java:85)
at com.ibm.ws.webservices.wssecurity.handler.GlobalSecurityHandler.handleRequest6(GlobalSecurityHandler.java:406)

 

Solution:

For the managed clients, the service lookup is through JNDI lookup. Read about setting up a UsernameToken, WS-Security, digital signature WS-Security and LTPA token WS-Security.

The following is an example of a context lookup that is JSR 109 compliant:

InitialContext ctx = new InitialContext();

FredsBankServiceLocator locator = (FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService");

FredsBank fb = locator.getFredsBank(url);

long balance = fb.getBalance();

When we are instantiating a context lookup for a managed client, do not use new() for the service locator. Here is an example not JSR 109 compliant (new ServiceLocator):

Properties prop = new Properties();
InitialContext ctx = new InitialContext(prop);
FredsBankServiceLocator locator = new FredsBankServiceLocator();
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance();

 

"WSEC6500E: There is no candidate used to login" error message displays

 

Cause: This situation can occur in one of the following conditions:

For example, a Web service might be configured for authentication by using a Username token or an LTPA token. However, it is deployed to an appserver where global security is disabled. When the Web service is invoked by a Web service client, which correctly provides the required Username token or LTPA token, the Web service invocation will fail.

The following fault might be returned back to the Web service client: 

<soapenv:Fault>   
<faultcode 
    xmlns:p55="http://docs.oasis-open.org/wss/2004/01/oasis-
      200401-wss-wssecurity-secext-1.0.xsd">p55: FailedAuthentication  
</faultcode>   
<faultstring>  
<![CDATA[com.ibm.wsspi.wssecurity.SoapSecurityException:   

WSEC6500E: There is no candidate used to login.]]>   
</faultstring>   
<detail encodingStyle=""/>   
</soapenv:Fault>

 

Solution:

If application security is enabled on the appserver that is hosting the Web service, verify the client is properly configured to send the security token that is required by the Web service in the WS-Security consumer caller part configuration.

If application security is not enabled on the appserver that is hosting the Web service, do one of the following:

The com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled property enables WS-Security to not process the WS-Security header if application security is disabled. This allows system administrators and application programmers to debug aspects of their services in a non-secure environment without having to remove the WS-Security information from their deployment descriptors. The use of this property is only intended for diagnostic purposes and not for a production environment.

Valid values for this property are true and false. The default value is false.

Application-level, cell level and server-level are the levels of bindings that WAS offers. To configure the server-level bindings, which are the defaults:

  1. Click Servers > Application servers > <server_name>.

  2. Under Security, click Web Services: Default bindings for Web services security.

  3. Do one of the following:

    • Click Default consumer bindings > Properties (might apply to all applications in the cell).

    • Click Additional Properties > Properties (might apply to all applications in the cell).

To configure the cell-level bindings and access the default bindings on the cell level:

  1. Click Security > Web services.

  2. Under Default generator bindings or Default consumer bindings, click Properties.

  3. Under Security, click Web Services: Default bindings for Web services security.

  4. Do one of the following, specified in the following locations, in priority order:

    • Click Default consumer bindings > Properties.

    • Click Additional Properties > Properties.

To configure a JVM System property:

  1. Click Servers > Application servers > <server_name>.

  2. Under Server Infrastructure, click Java and Process Management > Process Definition.

  3. Under Additional Properties, click Java Virtual Machine.

  4. Under Additional Properties, click Custom Properties.

 

SHA-1 key identifier for Kerberos token is not consumed or generated correctly without a custom property

 

Cause:

As specified in the OASIS standard titled WS-Security Kerberos Token Profile v1.1, a base64 encoding of a SHA-1 transformed key value can be used to specify a key identifier for a Kerberos AP-REQ token. SHA-1 is a cryptographic hash function that transforms an input and returns a fixed size string. After the client and service provider have exchanged an initial Web services message, the SHA-1 key identifier is used to externally reference the Kerberos authentication token. To use SHA-1 for this purpose, configure a custom property in the policy bindings to generate and consume the SHA-1 key identifier. The custom property com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken is added to the client token generator and service token consumer bindings. This property allows the application to correctly generate and consume the SHA-1 key identifier during subsequent exchanges of Web Services messages when the Kerberos token is used as an authentication token.

 

Solution:

If an application generates or consumes a SHA-1 key identifier for each Web services message exchange, set the com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken custom property to true in the token generator and the token consumer bindings for the application. To set the custom property using the admin console, complete these steps:

  1. Click Services > Policy sets.

  2. Click General provider policy set bindings > binding_name.

  3. Click the WS-Security policy in the Policies table.

  4. Click Authentication and protection in the security policy bindings section.

  5. Under Authentication tokens, click the name of the token consumer or token generator.

  6. In the Custom properties section, enter the com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken custom property and the property value of true.

  7. Click OK, then click Save.

You should consider the possibility of a man-in-the-middle attack which can intercept the SHA-1 key during message exchanges. To protect the SHA-1 key, use either transport-level security, such as SSL, or message-level security including signature and encryption.

 

Kerberos V5 binary AP_REQ token is not generated or consumed correctly without a custom property

 

Cause:

When Microsoft® Web service applications request messages using a Kerberos token, configure a custom property in the policy bindings for the Kerberos V5 AP_REQ token to generate and consume the token.

Add the property...

com.ibm.wsspi.wssecurity.kerberos.attach.apreq custom

...to the client token generator and service token consumer bindings.

Enable this property allows the application to generate and consume the Kerberos AP_REQ token for each Web Services request message.

 

Solution: If an application generates or consumes a Kerberos V5 AP_REQ token for each Web Services request message, set the custom property...

com.ibm.wsspi.wssecurity.kerberos.attach.apreq

...to true in the token generator and the token consumer bindings for the application, as follows:

Generating and consuming an AP_REQ token for every Web Services request message has implications for product performance, including message processing efficiency and memory usage.

To set this custom property in the admin console, complete the

  1. In the admin console, click...

    Services | Policy sets | General provider policy set bindings | binding_name | Policies table | WS-Security policy | Security policy bindings | Authentication and protection | Protection tokens | [token_consumer | token generator]

    In the Custom properties section, enter the property...

    com.ibm.wsspi.wssecurity.kerberos.attach.apreq custom

    ...and the appropriate value (true).

 

Instead of issuing a CertPath exception, a valid certification path is built on Sun Solaris when an invalid certificate is used

 

Cause:

WS-Security enabled Web services applications on a Sun Solaris system may incorrectly build a valid certification path even though an invalid certificate has been used. When the key in the certificate in a request and the key in the certificate retrieved on the server do not match, an error message should be issued. However, when the certificates differ in every respect except for the DN, and the Sun security provider is used, the certification path is returned as valid. This problem does not occur when the IBMCertPath security provider is used. IBMCertPath is the default security provider on all systems except Sun Solaris, therefore Sun Solaris is the only system on which this problem occurs.

 

Solution:

A new property has been added for WAS v 6.0.2 and later: com.ibm.wsspi.wssecurity.config.CertStore.Provider

This property allows WS-Security, when running in WAS on Solaris, to use the IBMCertPath provider instead of using the Sun CertPath provider. Is the security provider that WS-Security should use when using trust anchors, and when the certificate store security provider was specified in conjunction with the certificate store.

If both the com.ibm.wsspi.wssecurity.config.CertStore.Provider is specified and a security provider is specified for the certificate store, the certificate store security provider will override the setting for com.ibm.wsspi.wssecurity.config.CertStore.Provider.

 

Hardware cryptographic requests with card-related exceptions must use cryptographic software to complete requests successfully

 

Cause:

Hardware cryptographic device-related exceptions might be seen when the machine is experiencing a heavy load. The requests complete successfully because cryptographic software is used instead for the particular operation that received the exception. However, the hardware cryptographic device is not used.

The following exceptions have been seen when running stress tests:

CWWSS5601E:

The following exception occurred while decrypting the message: com.ibm.pkcs11.PKCS11Exception: Another operation is already active

and

CWWSS5601E:

The following exception occurred while decrypting the message: Key handle is invalid: com.ibm.pkcs11.PKCS11Exception: Key handle is invalid

This problem only occurs when the hardware cryptographic card is handling a large number of operations.

 

Solution:

There are no known workarounds. However, the requests complete successfully because the software cryptography is used when the hardware cryptography fails for an operation.


 

Related concepts


Assembly tools

 

Related tasks


Set the client for identity assertion: specifying the method
Set the client for identity assertion: collecting the authentication method
Set the server to handle identity assertion authentication
Set the server to validate identity assertion authentication information
Set the client security bindings using an assembly tool
Set the security bindings on a server acting as a client
Set the server security bindings using an assembly tool
Set the server security bindings
Use PolicyTool to edit policy files for Java 2 security
Troubleshooting Web services

 

Related information


http://www.ibm.com/developerworks/websphere/techjournal/0604_singh/0604
http://www.ibm.com/developerworks/websphere/techjournal/0606_singh/0606
http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/06