Web Service 安全性故障诊断技巧
要对 Web Service 安全性进行故障诊断,请使用组装工具来复审配置,以使客户机与服务器之间的请求配置和响应配置相匹配。
对 Web Service 安全性进行故障诊断最好通过使用组装工具复审配置来完成,以使客户机与服务器的请求配置及响应配置相匹配。这些配置必须匹配。客户机请求发送方配置必须与服务器请求接收方配置匹配。要成功地进行加密,必须将接收方的公用密钥导出到发送方,并且必须在加密信息中正确地配置此密钥。对于认证而言,您必须在服务器的登录映射中指定客户机所使用的方法。
下列步骤包括您可以执行的一般故障诊断步骤的列表。
本任务的步骤
- 对于下列发送方和接收方,对每个下游调用验证客户机安全性扩展与服务器安全性扩展是否匹配:
- 请求发送方和请求接收方
- 响应发送方和响应接收方
- 验证当客户机端启用了添加创建时间戳记选项时,服务器是否配置了添加接收时间戳记选项。您必须使用组装工具来配置安全性扩展。
- 验证是否已正确地配置客户机安全性绑定和服务器安全性绑定。如果客户机认证方法是签名,请确保服务器有登录映射。如果客户机使用公用密钥 cn=Bob,o=IBM,c=US 对消息体进行加密,请验证此主体集是否服务器密钥库中的个人证书,以便它能够使用专用密钥对消息体进行解密。您可以使用组装工具或 WebSphere® Application Server 管理控制台来配置安全性绑定。
- 检查 ${USER_INSTALL_ROOT}/logs/server1 目录(server1 根据服务器名称而更改)中的
SystemOut.log 文件来查找可能提供有关此问题的信息的消息。注: 本主题引用了一个或多个应用程序服务器日志文件。作为另一种建议采用的方法,您可以在分布式系统和 IBM® i 系统上配置服务器以使用高性能可扩展日志记录 (HPEL) 记录和跟踪基础结构,而不使用 SystemOut.log、SystemErr.log、trace.log 和 activity.log 文件。您还可以将 HPEL 与本机 z/OS® 日志记录设施结合使用。如果要使用 HPEL,那么可从服务器概要文件 bin 目录使用 LogViewer 命令行工具来访问所有日志和跟踪信息。有关使用 HPEL 的更多信息,请参阅有关使用 HPEL 对应用程序进行故障诊断的信息。
- 通过使用以下跟踪规范来对 Web Service 安全性启用跟踪:
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 two lines as one continuous line.
Errors when securing 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
- CWWSI5061E: The SOAP body is not signed error message displays
- CWWSI5075E: No security token found that satisfies any one of the authentication methods error message displays
- CWWSI5094E: No UsernameToken of trusted user was found or the login failed for the user while the TrustMode is BasicAuth error message displays
- CWSCJ0053E: Authorization failed for /UNAUTHENTICATED error message displays
- 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
- 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 WebSphere Application Server
- WSEC5502E: Unexpected element as the target element error message displays
- WSEC6664E: Null is not allowed to PKIXBuilderParameters. The configuration of TrustAnchor and CertStoreList are not correct exception displays
- WSE567: The incoming Username token must contain both a nonce and a creation time for the replay detection feature Microsoft .NET error displays
- 显示“WSEC6500E: There is no candidate used to login”错误消息
- 在没有定制属性的情况下无法正确地使用或生成 Kerberos 令牌的 SHA-1 密钥标识
- 在没有定制属性的情况下无法正确生成或使用 Kerberos V5 二进制 AP_REQ 令牌
- 在 Sun Solaris 上,使用无效证书时构造了有效的认证路径,而未发出 CertPath 异常
- 发生了与卡相关的异常的硬件密码请求必须使用密码软件才能成功地完成请求
“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:
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:
C:\WebSphere\AppServer\profiles\AppSrv01//etc/ws-security/samples/enc-receiver.jceks."
profile_root/etc/ws-security/samples/dsig-sender.ks
profile_root/etc/ws-security/samples/dsig-receiver.ks
profile_root/etc/ws-security/samples/enc-sender.jceks
profile_root/etc/ws-security/samples/enc-receiver.jceks
profile_root/etc/ws-security/samples/intca2.cer
app_server_root/etc/ws-security/samples/dsig-sender.ks
app_server_root/etc/ws-security/samples/dsig-receiver.ks
app_server_root/etc/ws-security/samples/enc-sender.jceks
app_server_root/etc/ws-security/samples/enc-receiver.jceks
app_server_root/etc/ws-security/samples/intca2.cer
Solution:
You can work around the key mismatch error by manually copying the keystore files from the Version 7.0 and later nodes in the mixed cluster to the Version 6.1 Feature Pack for web services nodes. This ensures that Version 7.0 and later nodes and Version 6.1 Feature Pack for web services nodes are using the same keystore files. Another workaround is to move the Version 7.0 and later 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:
- From the web services client editor within the assembly tool for
client configurations:
- Click ActorURI field. and indicate the actor information in the
- Click Actor field. and indicate the actor information in the
- From the Web Services Editor within the assembly tool for server
configurations:
- Click section. Verify that the actor URI has the same actor string as the client-side.
- Click Actor field. and indicate the actor information in the
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 you 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
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. You can check this information by looking at the following locations in the assembly tool:
- From the web services client editor within the assembly tool for
client configurations:
- Click verify the authentication method.
- Click verify the authentication method and other parameters.
- From the Web Services Editor within the assembly tool for server
configurations:
- Click and verify the authentication method.
- Click and verify the authentication method and other parameters.
Also, make sure that the actor URI specified on the client and server matches. You can configure the actor URI at the following locations within the assembly tool:
- From the web services client editor within the assembly tool for
client configurations:
- Click ActorURI field. and indicate the actor information in the
- Click Actor field. and indicate the actor information in the
- From the web services editor within the assembly tool for server
configurations:
- Click Actor URI field has the same actor string as the client side. section. Make sure that the
- Click Actor field. and indicate the actor information in the
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 you 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, read about configuring the client for identity assertion when specifying the method and configuring the client for identity assertion collecting the authentication method.
To configure the server for identity assertion, read about configuring the server to handle identity assertion authentication and configuring the server to validate identity assertion authentication information
CWSCJ0053E: Authorization failed for /UNAUTHENTICATED error message displays
Cause:
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 Enterprise JavaBeans (EJB) file, but the EJB file calls a downstream EJB file that is 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:
- Configuring the client security bindings using an assembly tool
- Configuring the security bindings on a server acting as a client using the administrative console
- Configuring the server security bindings using an assembly tool
- Configuring the server security bindings using the administrative console
To configure the client for identity assertion, read about configuring the client for identity assertion when specifying the method and configuring the client for identity assertion collecting the authentication method.
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:
- Username token
- X509 certificate token
- X509 certificates in a PKIPath
- A list of X509 certificates and CRLs in a PKCS#7
Solution:
If you 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 WebSphere Application Server
Cause:
Invalid URI: The format of the URI could not be determined.
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 WebSphere Application
Server, Web Services Security is enabled and uses the ActorURI attribute.
This error occurs because Microsoft .NET Web Services Enhancements (WSE) Version 2.0 Service Pack 3
does not support a relative URI value for the ActorURI attribute.
WSE Version 2.0 Service Pack 3 supports an absolute Uniform Resource
Identifier (URI) for this attribute only.Solution:
To work with a Microsoft .NET client, you must configure this attribute as an absolute URI. An example of an absolute URI is: abc://myWebService. An example of a relative URI is: myWebService.
- Open the Web Services Editor, click the Extensions tab and expand Server Service Configuration.
- Enter the full absolute URI in the Actor field.
- Expand .
- Enter the full absolute URI in the Actor field.
WSEC5502E: Unexpected element as the target element error message displays
Cause:
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken
- Obtain a WS-Security trace for the process that is producing the message. For more information on how to implement the WS-Security trace, read about tracing web services.
- Check to see if the trace contains information about the incoming
SOAP message:
- From the point of the exception, search backwards for the term soapenv:env.
- From that point, search backwards for the term X509.
- Note the type of the X.509 security token, either #X509 or #X509v3.
- 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.
- Check the type of X.509 security token that is specified in the
consumer configuration:
- From the point of the exception, search backwards for the term WSSConsumerConfig.
- Now search forward for the term #X509.
- Note the type of the configured X.509 security token consumer, either #X509 or #X509v3.
- 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 you must 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:
- In the administrative console, click .
- Under the Default consumer binding heading, click .
- Select either the Trust any or Dedicated signing information option.
If you 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.
- 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, you have a web services client for WebSphere Application Server 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 that is using WebSphere Application Server.
Solution:
- Open the web service client deployment descriptor and click the WS-Binding tab.
- Expand the sections.
- Click the name of the username token that you already created and click Edit.
- In the Properties section of the Token Generator window, click Add.
- Enter com.ibm.wsspi.wssecurity.token.username.addNonce in the Name field to provide the name of the nonce property.
- Enter true in the Value field.
- Click Add.
- Enter com.ibm.wsspi.wssecurity.token.username.addTimestamp in the Name field to provide the name of the timestamp property.
- In the Value field, enter true.
- 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 WebSphere Application Server Version 6.1. If your 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:
- Use the PolicyTool to edit the policy files. Follow the appropriate steps for your operating system.
- Add all of the permissions to the was.policy file that gets packaged in the enterprise archive (EAR) file for
your application. If you want finer granularity for the permissions
in the was.policy file for your application,
enable the permissions that are necessary for your application based
upon the classes that you need. For example, if you need to access only the methods for the X509BSToken, you would add the following permissions to the was.policy file:
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"; };
- 更新该应用程序的 EAR 文件中的 was.policy 文件。
- 从 WebSphere Application Server 中卸载该应用程序,然后使用新的 EAR 文件和已更新的 was.policy 文件重新安装该应用程序。
对 SOAP 元素声明完整性或机密性时发生异常
原因:
如果客户机对某个 SOAP 元素声明了完整性或机密性,但消息中缺少该元素,那么将发出异常。
如果客户机要求对某个 SOAP 元素应用签名或加密,那么该 SOAP 元素必须始终存在。此元素的存在与否并不是可选的。例如,如果配置指定必须将完整性或机密性应用于 wscontext 元素,但是消息中不存在 wscontext,那么将发出以下异常:
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]
解决方案:
客户机开发者必须确保完整性或机密性所针对的 SOAP 元素在 SOAP 消息中始终存在。如果无法确保 SOAP 元素始终存在,请不要对该 SOAP 元素应用完整性或机密性。
JSR-101 与 JSR-109 编程模型之间的差别引起客户机输出异常
原因:
有时,运行客户机时会发生客户机输出异常。客户机输出异常可能是由于 JSR-101 与 JSR-109 编程模型之间的差别所致。
您可以配置任何 Web Service 安全性约束,例如:用户名令牌、X509 令牌以及对 SOAP 元素进行签名或加密等。例如,可以对 WebSphere Application Server 客户机和服务配置用户名令牌。客户机配置为在请求中发送用户名令牌,而服务器配置为接收用户名令牌。但是,如果客户机未发送用户名令牌,那么服务器将拒绝该请求。如果客户机未执行 Java 命名和目录接口 (JNDI) 命名查找,那么该客户机可能不是 JSR-109 客户机。如果它不是 JSR-109 客户机,那么它将无法获取 JSR-109 配置信息(包括安全性配置),因此请求将失败。
对于 JSR-109 编程模型而言,调用将先执行 JNDI 查找,这将允许连接安全性配置信息。对于 JSR-101 编程模型而言,不会执行 JNDI 查找,因此无法连接安全性配置信息。
解决方案:
此行为不是 JSR-101 和 JSR-109 编程模型的问题。Web Service 安全性未向 JSR-101 客户机提供 WebSphere Application Server 安全性配置信息。
- JSR-101 客户机不支持 Web Service 安全性。
- 只能将 JSR-109 客户机配置为使用 Web Service 安全性。
如果客户机需要 Web Service 安全性,那么它必须是 JSR-109 客户机。
出现“WSSecurityCon E WSEC5514E: An exception while processing WS-Security message error”
原因:
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(GlobalSecuri
tyHandler.java:406)
解决方案:
对于受管客户机,服务查询是通过 Java 命名和目录接口 (JNDI) 查询来执行。请阅读“设置 UsernameToken、Web Service 安全性、数字签名 Web Service 安全性以及轻量级第三方认证 (LTPA) 令牌 Web Service 安全性”。以下是遵从 JSR 109 的上下文查找的示例:
InitialContext ctx = new InitialContext();
FredsBankServiceLocator locator
=(FredsBankService)ctx.lookup("java:comp/env/service/FredsBankService");
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance();
在为受管客户机进行上下文查找实例化时,请不要将 new() 用于服务定位器。以下是不遵从 JSR 109 的示例 (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”错误消息
原因:
- 已启用应用程序安全性,但入站 SOAP 消息未包含服务的使用者调用者部件中指定的必需安全性令牌。
- Web Service 客户机正在通过使用 Web Service 安全性来调用 Web Service,但在主管 Web Service 的应用程序服务器上禁用了应用程序安全性。
例如,可通过使用用户名令牌或 LTPA 令牌来配置 Web Service 进行认证。但是,它被部署到禁用了全局安全性的应用程序服务器。如果由可正确提供所需用户名令牌或 LTPA 令牌的 Web Service 客户机调用 Web Service,那么 Web Service 调用将失败。可能会向 Web Service 客户机返回以下故障:
<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>
解决方案:
如果在主管 Web Service 的应用程序服务器上启用了应用程序安全性,请确保已正确配置客户机以发送 Web Service 安全性使用者调用者部件配置中 Web Service 所需的安全性令牌。
- 在主管 Web Service 的应用程序服务器上启用应用程序安全性。
- 对 Web Service 设置 com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled Web Service 安全性定制属性。
com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled 属性允许 Web Service 安全性不处理 WS-Security 头(如果已禁用应用程序安全性)。这允许系统管理员和应用程序员在非安全环境中调试服务的各个方面,而不必从部署描述符中移除 WS-Security 信息。此属性仅用于诊断用途,而不适用于生产环境。
此属性的有效值是 True 和 False。缺省值为 false。
应用程序级别、单元级和服务器级别是 WebSphere Application Server 提供的绑定级别。
- 单击 。
- 在“安全性”下,单击 Web Service:Web Service 安全性的缺省绑定。
- 执行下列其中一个任务:
- 单击 (可应用于单元中的所有应用程序)。
- 单击 (可应用于单元中的所有应用程序)。
- 单击 。
- 在“缺省生成器绑定”或“缺省使用者绑定”下,单击属性。
- 在“安全性”下,单击 Web Service:Web Service 安全性的缺省绑定。
- 按优先顺序执行下列位置中指定的其中一个操作:
- 单击 。
- 单击 。
- 单击 。
- 在“服务器基础结构”下,单击 。
- 在“其他属性”下,单击Java 虚拟机。
- 在“其他属性”下,单击定制属性。
在没有定制属性的情况下无法正确地使用或生成 Kerberos 令牌的 SHA-1 密钥标识
原因:
正如标题为“Web Service 安全性 Kerberos 令牌概要文件 V1.1”的 OASIS 标准中指定的那样,可以使用经过 SHA-1 变换的密钥值的基本 64 位编码来指定 Kerberos AP-REQ 令牌的密钥标识。SHA-1 是一项密码散列功能,用于对输入进行变换并返回固定大小的字符串。在客户机和服务提供程序已交换初始 Web Service 消息之后,SHA-1 密钥标识用来从外部引用 Kerberos 认证令牌。要将 SHA-1 用于此用途,您必须在策略绑定中配置一个定制属性以生成并使用 SHA-1 密钥标识。定制属性 com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken 将被添加到客户机令牌生成器绑定和服务令牌使用者绑定中。在将 Kerberos 令牌用作认证令牌时,此属性可让应用程序在后续交换 Web Service 消息期间正确地生成和处理 SHA-1 密钥标识。
解决方案:
如果应用程序针对每一 Web Service 消息交换生成或处理 SHA-1 密钥标识,请在该应用程序的令牌生成器和令牌使用者绑定中,将 com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken 定制属性设置为 True。
- 单击 。
- 单击 。
- 单击“策略”表中的 WS-Security 策略。
- 在“安全策略绑定”部分中单击认证与保护。
- 在认证令牌下,单击令牌使用者或令牌生成器的名称。
- 在定制属性部分中,输入 com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken 定制属性和属性值 True。
- 单击确定,然后单击保存。
在没有定制属性的情况下无法正确生成或使用 Kerberos V5 二进制 AP_REQ 令牌
原因:
在 Microsoft® Web Service 应用程序使用 Kerberos 令牌来请求消息时,您必须在策略绑定中为 Kerberos V5 AP_REQ 令牌配置定制属性,才能生成和处理该令牌。将 com.ibm.wsspi.wssecurity.kerberos.attach.apreq 定制属性添加到客户机令牌生成者和服务令牌使用者绑定。启用此属性将允许应用程序为每条 Web Service 请求消息生成并使用 Kerberos AP_REQ 令牌。
解决方案:
- 要与 Microsoft .NET 客户机应用程序进行互操作,请在目标服务的令牌使用者绑定中,将此定制属性设为 true。
- 要与 Microsoft .NET 服务进行互操作,请在客户机令牌生成器绑定中将此定制属性设置为 True。
- 如果应用程序针对每则 Web Service 消息生成 Kerberos AP_REQ 令牌,请在客户机令牌生成器绑定和服务令牌使用者绑定中,将此定制属性设为 true。
- 在管理控制台中,单击 。
- 单击 。
- 单击“策略”表中的 WS-Security 策略。
- 在“安全策略绑定”部分中单击认证与保护。
- 在“保护令牌”下,单击令牌使用者或令牌生成器的名称。
- 在“定制属性”部分中,输入 com.ibm.wsspi.wssecurity.kerberos.attach.apreq 定制属性和适当的值 (True)。
在 Sun Solaris 上,使用无效证书时构造了有效的认证路径,而未发出 CertPath 异常
原因:
即使使用了无效的证书,Sun Solaris 系统上启用了 WS-Security 的 Web Service 应用程序仍可能会错误地构建有效的认证路径。当请求中的证书中的密钥与服务器上检索到的证书中的密钥不匹配时,应该发出错误消息。但是,在使用 Sun 安全性提供程序时,即使证书在除 DN 以外的各方面均不同,也仍然会返回有效的认证路径。使用 IBMCertPath 安全性提供程序时,不会发生此问题。IBMCertPath 是除 Sun Solaris 以外的所有系统上的缺省安全性提供程序,因此 Sun Solaris 是唯一有可能发生此问题的系统。
- 将 Web Service 部署到非 Sun Solaris 系统时,会返回 IBM 缺省 CertPath 提供程序 (IBMCertPath)。如果代码工作正常,那么在密钥不匹配时,您将看到以下异常:
WSEC5085E: Unable to build a valid CertPath: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
- 将 Web Service 部署到 Sun Solaris 时,java.security.cert.CertPathBuilder.build 方法会返回 Sun 缺省 CertPath 提供程序,而不是 IBMCertPath。Sun 安全性提供程序将只检查专有名称 (DN),而不检查签名信息。
请求应该由于密钥不正确而失败。但是,由于只检查 DN,因此会将无效的 CertPath 作为有效 CertPath 返回。如果给定的无效输入在除 DN 以外的各方面均有别于服务器端上的证书,那么在 Sun Solaris 上运行的 Web Service 应用程序可能会不正确地构建有效 CertPath。
解决方案:
为 WebSphere Application Server V6.0.2 和更高版本添加了新属性:com.ibm.wsspi.wssecurity.config.CertStore.Provider
此属性可让 Web Service 安全性(在 Solaris 上的 WebSphere Application Server 运行时)使用 IBMCertPath 提供程序,而不是使用 Sun CertPath 提供程序。此属性是在使用信任锚及证书库安全性提供程序与证书库一并指定的情况下,Web Service 安全性应使用的安全性提供程序。
如果指定了 com.ibm.wsspi.wssecurity.config.CertStore.Provider 并对证书库指定了安全性提供程序,那么证书库安全性提供程序将覆盖 com.ibm.wsspi.wssecurity.config.CertStore.Provider 的设置。
发生了与卡相关的异常的硬件密码请求必须使用密码软件才能成功地完成请求
原因:
在负载较重的机器上,可能会发生与硬件密码设备相关的异常。这些请求能够成功完成的原因是,对于接收到此异常的特定操作,使用了密码软件。但是,未使用硬件密码设备。
CWWSS5601E: The following exception occurred while decrypting the message:
com.ibm.pkcs11.PKCS11Exception: Another operation is already active
和CWWSS5601E: The following exception occurred while decrypting the message: Key handle is invalid:
com.ibm.pkcs11.PKCS11Exception: Key handle is invalid
仅当硬件密码卡处理大量操作时,才会发生此问题。
解决方案:
没有已知的变通方法。但是,由于发生密码硬件故障时对某个操作使用了密码软件,因此这些请求成功完成。