Dicas de Resolução de Problemas do Web Services Security
Para resolver problemas do Web Services Security, revise as configurações com as ferramentas do conjunto para corresponder à solicitação do cliente e do servidor e às configurações de resposta.
Resolver problemas do Web Services Security é feito da melhor forma ao revisar as configurações com as ferramentas do conjunto para que você possa corresponder à solicitação do cliente e do servidor e às configurações de resposta. Essas configurações devem corresponder. A configuração do emissor de um pedido do cliente deve corresponder à configuração do receptor do pedido do servidor. Para que a criptografia ocorra com êxito, a chave pública do receptor deve ser exportada ao emissor e essa chave deve ser configurada corretamente nas informações de criptografia. Para a autenticação, você deve especificar o método utilizado pelo cliente no mapeamento de login do servidor.
As etapas a seguir incluem uma lista de etapas genéricas de resolução de problemas que é possível executar.
Etapas para Esta Tarefa
- Verifique se as extensões da segurança do cliente e as extensões da segurança do servidor
correspondem aos seguintes emissores e receptores em cada chamada de recebimento de dados:
- Emissor de pedidos e receptor de pedidos
- Emissor da respostas e receptor de respostas
- Verifique se quando a opção Adicionar Data e Hora da Criação está ativada do cliente esse servidor tem a opção Adicionar Data e Hora de Recebimento configurada. Você deve configurar as extensões de segurança com uma ferramenta de montagem.
- Verifique se as ligações da segurança do cliente e as ligações da segurança do servidor estão configuradas corretamente. Quando o método de autenticação do cliente for assinatura, certifique-se de que o servidor tenha um mapeamento de login. Quando o cliente usar a chave pública cn=Bob,o=IBM,c=US para criptografar o corpo, verifique se esse assunto é um certificado pessoal no armazenamento de chaves do servidor, para que possa decriptografar o corpo com a chave privada. É possível configurar as ligações de segurança utilizando uma ferramenta de montagem ou o console administrativo do WebSphere Application Server.
- Verifique o arquivo SystemOut.log no diretório ${USER_INSTALL_ROOT}/logs/server1
(server1 pode ser alterado dependendo do nome do servidor) para procurar mensagens que possam fornecer informações sobre o problema.Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.
- Ative o rastreamento da Web Services Security usando a seguinte especificação de rastreio:
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
Digite as duas linhas linhas anteriores como uma linha contínua.
Erros Quando Proteger Serviços da Web
- A mensagem de erro de incompatibilidade de chave "CWWSS6811E: O identificador de chave <identifier name> recuperado da mensagem é diferente do identificador de chave <identifier name> adquirido a partir do keystore" é exibida
- A Mensagem de Erro CWWSI5061E: O corpo do SOAP não está assinado é Exibida
- A Mensagem de Erro CWWSI5075E: Nenhum token de segurança que satisfaça qualquer um dos métodos de autenticação foi localizado é Exibida
- A Mensagem de Erro CWWSI5094E: Nenhum UsernameToken de usuário confiável foi localizado ou o login falhou para o usuário enquanto o TrustMode é BasicAuth é Exibida
- A Mensagem de Erro CWSCJ0053E: Autorização falhou para /UNAUTHENTICATED... é Exibida
- A Mensagem de Erro WSWS3243I: Informação: Exceção de Mapeamento para WebServicesFault é Exibida Quando Você Especifica o Nome Local do Tipo de Valor e o URI para um Consumidor de Token ou Gerador de Token
- A Mensagem de Erro URI Inválido: O formato do URI não pôde ser determinado Poderá Ser Exibida Quando Você Usar um Cliente Microsoft .NET Que Acessa um Serviço da Web para o WebSphere Application Server
- A Mensagem de Erro WSEC5502E: Elemento inesperado como o elemento de destino é Exibida
- WSEC6664E: Nulo não é permitido para PKIXBuilderParameters. As configurações de TrustAnchor e CertStoreList não estão corretas é Exibida
- O erro WSE567: O token Username de entrada deve conter um nonce e um horário de criação para o recurso de detecção de resposta do Microsoft .NET é Exibido
- A Mensagem de Erro WSEC6500E: Não há candidato usado para login é Exibida
- O identificador de chave SHA-1 para o token de Kerberos não é consumido ou gerado corretamente sem uma propriedade customizada.
- O token binário AP_REQ do Kerberos V5 não é gerado ou consumido corretamente sem uma propriedade customizada
- Em vez de emitir uma exceção do CertPath, um caminho de certificação válido é criado no Sun Solaris quando um certificado inválido é utilizado
- Pedidos Criptográficos de Hardware com Exceções Relacionadas à Placa Devem Utilizar Software Criptográfico para Concluir Pedidos com Êxito
A mensagem de erro de incompatibilidade de chave "CWWSS6811E: O identificador de chave <identifier name> recuperado da mensagem é diferente do identificador de chave <identifier name> adquirido a partir do keystore" é exibida
Causa:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: O Login falhou
devido a uma exceção: javax.security.auth.login.LoginException: CWWSS6811E:
O identificador de chave TVpC640XSSc= recuperado da mensagem é diferente do
identificador de chave QdZLf+KjrUg= adquirido do Caminho do keystore:
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
Solução:
Uma solução alternativa para resolver o erro de incompatibilidade de chave é copiar manualmente os arquivos keystore dos nós da Versão 7.0 e superior no cluster combinado para o Feature Pack da Versão 6.1 dos nós de serviços da Web. Isso assegura que os nós da Versão 7.0 e superior e o Feature Pack Versão 6.1 para os nós de serviços da Web usem os mesmos arquivos keystore. Outra solução alternativa é mover os arquivos keystore Versão 7.0 e superior para um local de diretório comum e, em seguida, modificar todas as ligações para apontar para o local comum dos arquivos keystore.
A Mensagem de Erro CWWSI5061E: O corpo do SOAP não está assinado é Exibida
Causa:
Esse erro normalmente ocorre todas as vezes que o manipulador de segurança SOAP não é carregado corretamente e não assina o corpo de SOAP. O manipulador de segurança SOAP geralmente é a primeira validação que ocorre no servidor, portanto, muitos problemas podem fazer com que essa mensagem seja exibida. O erro pode ser causado por configurações inválidas do URI do agente principal.
Solução:
É possível configurar o URI (Universal Resource Identifier) do agente nos seguintes locais com a ferramenta de montagem:
- A partir do editor de cliente de serviços da Web na ferramenta do conjunto para configurações
do cliente:
- Clique em ActorURI. e indique as informações do agente no campo
- Clique em Agente. e indique as informações do agente no campo
- A partir do Web Services Editor na ferramenta de montagem para configurações
do servidor:
- Clique em . Verifique se o URI do agente principal possui a mesma cadeia de agente principal que no lado do cliente.
- Clique em Agente. e indique as informações do agente no campo
As informações do agente principal, tanto no cliente como no servidor, devem fazer referência à mesma cadeia. Quando os campos do agente principal no cliente e no servidor correspondem, o pedido ou a resposta sofre ação, em vez de ser encaminhada adiante no fluxo de dados. Os campos atuantes podem ser diferentes quando você tiver serviços da Web que atuam como um gateway para outros serviços da Web. No entanto, em todos os outros casos, verifique se as informações do agente principal correspondem no cliente e no servidor. Quando a implementação dos serviços da Web estiver atuando como um gateway e não possuir o mesmo agente configurado que a solicitação que passa pelo gateway, essa implementação de serviços da Web não processará a mensagem a partir do cliente. Em vez disso, ela enviará o pedido de recebimento de dados. O processo downstream que contém a cadeia de agente principal correta processa o pedido. A mesma situação ocorre para a resposta. Portanto, é importante verificar se os campos de agente principal apropriados do cliente e do servidor estão sincronizados.
Além disso, o erro pode aparecer quando você não especificar que o corpo é assinado na configuração do cliente. Para assinar a parte do corpo da mensagem usando o editor de cliente de serviço da web na ferramenta de montagem, clique em
e selecione as partes da mensagem a serem assinadas.A Mensagem de Erro CWWSI5075E: Nenhum token de segurança que satisfaça qualquer um dos métodos de autenticação foi localizado é Exibida
Solução:
Verifique se as informações de configuração do registro do cliente e do servidor correspondem nas extensões de segurança. Verifique, também, se o cliente possui uma ligação de login válida e se o servidor tem um mapeamento de login nas ligações de segurança. Pode-se verificar essas informações consultando os seguintes locais da ferramenta de montagem:
- A partir do editor de cliente de serviços da Web na ferramenta do conjunto para configurações
do cliente:
- Clique em e verifique o método de autenticação.
- Clique em e verifique o método de autenticação e outros parâmetros.
- A partir do Web Services Editor na ferramenta de montagem para configurações
do servidor:
- Clique em e verifique o método de autenticação.
- Clique em e verifique o método de autenticação e outros parâmetros.
Além disso, certifique-se de que o URI do agente principal especificado no cliente e no servidor correspondam. É possível configurar o URI do agente nos seguintes locais na ferramenta de montagem:
- A partir do editor de cliente de serviços da Web na ferramenta do conjunto para configurações
do cliente:
- Clique em ActorURI. e indique as informações sobre o agente no campo
- Clique em Agente. e indique as informações do agente no campo
- A partir do editor de serviços da Web na ferramenta do conjunto para configurações
do servidor:
- Clique em URI do Agente tenha a mesma sequência do agente que no lado do cliente. . Certifique-se de que o campo
- Clique em Agente. e indique as informações sobre o agente no campo
A Mensagem de Erro CWWSI5094E: Nenhum UsernameToken de usuário confiável foi localizado ou o login falhou para o usuário enquanto o TrustMode é BasicAuth é Exibida
Causa:
Essa situação ocorre quanto você tem a IDAssertion configurada como método de autenticação.
Solução:
No serviço da Web de envio, configure uma entrada de autenticação básica confiável na ligação de login. Em seguida, no servidor, verifique se o avaliador de ID confiável possui um conjunto de propriedades que contém o nome do usuário dessa entrada de autenticação básica.
Para configurar o cliente para asserção de identidade, consulte a configuração do cliente para asserção de identidade ao especificar o método e a configuração do cliente para asserção de identidade ao coletar o método de autenticação.
Para configurar o servidor para asserção de identidade, consulte a configuração do servidor para manipular autenticação da asserção de identidade e a configuração do servidor para validar as informações de autenticação de asserção de identidade.
A Mensagem de Erro CWSCJ0053E: Autorização falhou para /UNAUTHENTICATED... é Exibida
Causa:
CWSCJ0053E: A autorização falhou para /UNAUTHENTICATED ao chamar (Home)com/ibm/wssvt/tc/
pli/ejb/Beneficiary findBeneficiaryBySsNo(java.lang.String):2 securityName: /UNAUTHENTICATED;accessID:
não é concedido ao nulo nenhuma das funções necessárias: AgentRole
Essa situação ocorre porque uma configuração de login não está sendo configurada ou o Web Services Security não está configurado de um cliente para um servidor. Quando o pedido chega no servidor e as informações de autenticação não são recebidas, o usuário UNAUTHENTICATED é definido no encadeamento. A autorização retorna este erro se há qualquer função designada ao recurso, exceto para a função "Everyone" especial, que suporta acesso por qualquer pessoa.
Se o cliente autenticar-se com êxito a um arquivo Enterprise JavaBeans (EJB), mas o arquivo EJB chamar um arquivo EJB de recebimento de dados que não está configurado com a Segurança de Serviços da Web ou segurança de transporte, como ID do usuário e senha HTTP, pode ocorrer um erro para essa solicitação de recebimento de dados.
Solução:
- Configurando as Ligações de Segurança do Cliente Utilizando uma Ferramenta de Montagem
- Configurando as Ligações de Segurança em um Servidor Agindo como um Cliente Utilizando o console administrativo
- Configurando as Ligações de Segurança do Servidor Utilizando uma Ferramenta de Montagem
- Configurando as Ligações de Segurança do Servidor Utilizando o Console Administrativo
Para configurar o cliente para asserção de identidade, consulte a configuração do cliente para asserção de identidade ao especificar o método e a configuração do cliente para asserção de identidade ao coletar o método de autenticação.
A Mensagem de Erro WSWS3243I: Informação: Exceção de Mapeamento para WebServicesFault é Exibida Quando Você Especifica o Nome Local do Tipo de Valor e o URI para um Consumidor de Token ou Gerador de Token
Causa:
- Token de Nome de Usuário
- Token do Certificado X509
- Certificados X509 em um PKIPath
- Uma lista de certificados X509 e CRLs em um PKCS#7
Solução:
Se você especificar um dos nomes locais anteriores do tipo de valor, não digite um valor para o campo URI do Tipo de Valor.
A Mensagem de Erro URI Inválido: O formato do URI não pôde ser determinado Poderá Ser Exibida Quando Você Usar um Cliente Microsoft .NET Que Acessa um Serviço da Web para o WebSphere Application Server
Causa:
URI inválido: o formato do URI não pode ser
determinado.
System.UriFormatException
em System.Uri.Parse()
em System.Uri..ctor(String uriString, Boolean dontEscape)
em System.Uri..ctor(String uriString)
no Microsoft.Web.Services2.SoapInputFilter.CanProcessHeader(cabeçalho XmlElement, contexto SoapContext)
no Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMessage(envelope SoapEnvelope)
no Microsoft.Web.Services2.Pipeline.ProcessInputMessage(envelope SoapEnvelope)
no Microsoft.Web.Services2.InputStream.GetRawContent()
no Microsoft.Web.Services2.InputStream.get_Length()
em System.Xml.XmlScanner..ctor(TextReader reader, XmlNameTable ntable)
em System.Xml.XmlTextReader..ctor(String url, TextReader input, XmlNameTable nt)
em System.Xml.XmlTextReader..ctor(TextReader input)
em System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,
WebResponse response, Stream responseStream, Boolean asyncCall)
No WebSphere Application Server,
O Web Services Security é ativado e usa o atributo ActorURI.
Esse erro corre porque o WSE (Web Services Enhancements) Versão 2.0 Service Pack 3 doMicrosoft .NET não suporta um valor de URI relativo para o atributo
ActorURI.
O WSE Versão 2.0 Service Pack 3 suporta um
URI (Identificador Uniforme de Recursos) para esse atributo apenas.Solução:
Para trabalhar com um cliente Microsoft .NET, você deve configurar esse atributo como um URI absoluto. Um exemplo de um URI absoluto é: abc://myWebService. Um exemplo de URI relativo é: myWebService.
- Abra o Editor de Serviços da Web, clique na guia Extensões e expanda Configuração do Serviço do Servidor.
- Insira o URI completo absoluto no campo Agente.
- Expanda .
- Insira o URI completo absoluto no campo Agente.
A Mensagem de Erro WSEC5502E: Elemento inesperado como o elemento de destino é Exibida
Causa:
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Unexpected element as the target element: wsse:BinarySecurityToken
- Obtenha um rastreio do WS-Security para o processo que está produzindo a mensagem. Para obter informações adicionais sobre como implementar o rastreio do WS-Security, leia sobre o rastreio de serviços da Web.
- Verifique se o rastreio contém informações sobre a mensagem SOAP
de entrada:
- No ponto da exceção, procure para trás pelo termo soapenv:env.
- A partir desse ponto, procure para trás pelo termo X509.
- Anote o tipo do token de segurança X.509, #X509 ou #X509v3.
- Se o rastreio não contiver informações sobre a mensagem SOAP recebida, por exemplo, porque o rastreio está incompleto, procure para trás pelo tipo de valor do termo Destino, iniciando no ponto da exceção. Essa procura localiza a parte do rastreio que mostra qual token de segurança estava sendo processado no momento do erro. Observe o tipo do token de segurança, #X509 ou #X509v3.
- Verifique o tipo de token de segurança X.509 que está especificado na
configuração do consumidor:
- No ponto da exceção, procure para trás pelo termo WSSConsumerConfig.
- Agora procure para trás pelo termo #X509.
- Anote o tipo do consumidor do token de segurança X.509 configurado, #X509 ou #X509v3.
- Se o consumidor de token de segurança não corresponder ao tipo do token de segurança de entrada, isso confirmará que uma incompatibilidade do tipo de token de segurança é a causa do erro.
Solução:
O consumidor do token configurado deve corresponder ao tipo especificado para o token de segurança de entrada. Se a causa do erro, conforme definido nas etapas anteriores, for determinado como uma incompatibilidade do tipo de token de segurança, você deverá alterar a configuração do consumidor ou provedor para o WS-Security para assegurar que os tipos de token correspondam.
WSEC6664E: Nulo não é permitido para PKIXBuilderParameters. As configurações de TrustAnchor e CertStoreList não estão corretas é Exibida
Causa:
A configuração do caminho do certificado não está definida apropriadamente.
Solução:
- No console administrativo, clique em .
- No título Ligação de consumidor padrão, clique em .
- Selecione a opção Confiar em Todos ou Informações de Assinatura
Dedicadas.
Se você selecionar a opção Informações de Assinatura Dedicada, selecione uma âncora de confiança e um armazenamento de certificados a partir das configurações fornecidas nas listas drop-down.
- Clique em OK e Salvar para a configuração master.
O erro WSE567: O token Username de entrada deve conter um nonce e um horário de criação para o recurso de detecção de resposta do Microsoft .NET é Exibido
Causa:
Nesse cenário, você possui um cliente de serviços da Web para o WebSphere Application Server e um serviço da Web Microsoft .NET. O serviço da Web Microsoft .NET possui uma restrição do ws-security para um token de nome de usuário configurado. A exceção a seguir é ativada pelo servidor do Microsoft .NET:
WSE567: O token nome de usuário de entrada deve conter um nonce e uma hora de criação para o recurso de detecção de resposta.
Por padrão, o serviço da WebMicrosoft .NET valida o nonce e o registro de data e hora para o token do nome do usuário. Entretanto, ele é opcional para você configurar as propriedades do nonce e de registro de data e hora para um cliente serviço da Web que está usando o WebSphere Application Server.
Solução:
- Abra o descritor de implementação do cliente de serviço da Web e clique na guia WS-Binding.
- Expanda as seções .
- Clique no nome do token username já criado, e clique em Editar.
- Na seção Propriedades da janela Gerador de Token, clique em Incluir.
- Insira com.ibm.wsspi.wssecurity.token.username.addNonce no campo Nome para fornecer o nome da propriedade nonce.
- Digite true no campo Valor.
- Clique em Incluir (Add).
- Insira com.ibm.wsspi.wssecurity.token.username.addTimestamp no campo Nome para fornecer o nome da propriedade timestamp.
- No campo Valor, digite true.
- Clique em OK e salve o descritor de implementação cliente.
As exceções do Java 2 Security ocorrem ao utilizar o pacote com.ibm.wsspi.wssecurity.auth.token com o Java 2 Security ativado
Causa:
Um aplicativo cria as exceções do Java™ 2 Security enquanto utiliza o pacote com.ibm.wsspi.wssecurity.auth.token.* quando o Java 2 Security está ativado.
Novas permissões do Java 2 foram configuradas para vários métodos públicos do pacote com.ibm.wsspi.wssecurity.auth.token.* no WebSphere Application Server Versão 6.1. Se o aplicativo utilizar um dos métodos públicos dessas classes protegidas pelas permissões doJava 2 Security e não tiver as permissões apropriadas, o aplicativo falhará. A mensagem de exceção fornece informações que identificam as classes e os métodos públicos afetados pela nova permissão de Java 2 Security correspondente.
Solução:
- Utilize a PolicyTool para editar os arquivos de política. Siga as etapas adequadas para seu sistema operacional.
- E todas as permissões para o arquivo was.policy que são empacotadas no arquivo EAR (Enterprise Archive) para seu aplicativo. Se você desejar refinar a granularidade para as permissões no arquivo was.policy de seu aplicativo, ative as permissões que são necessárias para seu aplicativo com base nas classes de que precisa. Por exemplo, se precisar acessar apenas os métodos para o X509BSToken, incluirá as seguintes permissões no arquivo 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"; };
- Atualize o arquivo was.policy no arquivo EAR de seu aplicativo.
- Desinstale o aplicativo pelo WebSphere Application Server e reinstale-o com o novo arquivo EAR e o arquivo was.policy atualizado.
Poderá Ocorrer uma Exceção Quando a Integridade ou a Confidencialidade for Declarada para um Elemento SOAP
Causa:
Se um cliente declarar integridade ou confidencialidade para um elemento SOAP, mas o elemento estiver ausente na mensagem, será emitida uma exceção.
Se o cliente precisar da aplicação de uma assinatura ou criptografia em um elemento SOAP, o elemento SOAP deverá sempre estar presente. A presença desse elemento não é opcional. Por exemplo, se a configuração especificar que a integridade ou a confidencialidade deve ser aplicada ao elemento wscontext. Se wscontext estiver ausente da mensagem, a seguinte exceção será emitida:
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Objects
a serem processados não localizados com o dialeto
[http://www.ibm.com/websphere/webservices/wssecurity/dialect-was]
e a palavra-chave [wscontext]
Solução:
Os desenvolvedores de clientes asseguram que os elementos SOAP que eles utilizam como destino para integridade e confidencialidade estão sempre presentes na mensagem SOAP. Se você não puder assegurar que o elemento SOAP está sempre presente, não utilize-os como destino para integridade ou confidencialidade.
Exceções de Saída do Cliente Causadas pela Diferença nos Modelos de Programação JSR-101 e JSR-109
Causa:
Às vezes, as exceções de saída do cliente são produzidas ao executar o cliente. As exceções de saída do cliente poderão ser causadas pelas diferenças nos modelos de programação JSR-101 versus JSR-109.
É possível configurar qualquer uma das restrições do Web Services Security, como: token do nome de usuário, token X509, assinatura ou criptografia dos elementos SOAP, e assim por diante. Por exemplo, é possível configurar o token de nome de usuário em um cliente e serviço do WebSphere Application Server. O cliente é configurado para enviar um token de nome do usuário no pedido e o servidor é configurado para esperar um token de nome de usuário. Mas se o cliente não enviar um token de nome do usuário, o servidor rejeitará o pedido. Quando o cliente não desempenha uma consulta de nomenclatura de JNDI (Java Naming and Directory Interface), o cliente provavelmente não é um cliente JSR-109. Se ele não for um cliente do JSR-109, não obterá as informações de configuração do JSR-109, incluindo as configurações de segurança, e o pedido falhará.
Para o modelo de programação JSR-109, a chamada começa com a consulta do JNDI, que permite que as informações de segurança sejam anexadas. Para o modelo de programação JSR-101, uma consulta do JNDI não é executada; as informações de configuração de segurança não podem ser anexadas.
Solução:
Esse comportamento não é um problema com os modelos de programação JSR-101 e JSR-109. O Web Services Security não fornece as informações de configuração de segurança do WebSphere Application Server para um cliente JSR-101.
- O Web Services Security não é suportado para um cliente JSR-101.
- É possível configurar apenas um cliente JSR-109 para usar o Web Services Security.
Se o cliente requerer o Web Services Security, ele deverá ser um cliente JSR-109.
A Mensagem de Erro "WSSecurityCon E WSEC5514E: Uma exceção ao processar WS-Security" é Exibida
Causa:
00000046 WebServicesFa 1
com.ibm.ws.webservices.engine.WebServicesFault makeUserFault
MakeUserFault: com.ibm.wsspi.wssecurity.SoapSecurityException:
WSEC5720E: Uma parte da mensagem obrigatória [corpo] não está assinada.
em com.ibm.wsspi.wssecurity.SoapSecurityException.format(SoapSecurityException.java:143)
em com.ibm.ws.webservices.wssecurity.dsig.VerifiedPartChecker.invoke(VerifiedPartChecker.java:
263)
em com.ibm.ws.webservices.wssecurity.core.WSSConsumer.checkRequiredIntegrity(WSSConsumer.java:
1430)
em com.ibm.ws.webservices.wssecurity.core.WSSConsumer.invoke(WSSConsumer.java:545)
em com.ibm.ws.webservices.wssecurity.handler.WSSecurityConsumerBase.invoke(WSSecurityConsumerB
ase.java:85)
em com.ibm.ws.webservices.wssecurity.handler.GlobalSecurityHandler.handleRequest6(GlobalSecuri
tyHandler.java:406)
Solução:
Para os clientes gerenciados, a consulta de serviços é feita por meio da consulta JNDI (Java Naming and Directory Interface). Consulte sobre a configuração de um UsernameToken, Web Services Security, assinatura digital do Web Services Security e do token Lightweight Third-Party Authentication (LTPA) do Web Services Security. Segue um exemplo de consulta de contexto compatível com 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();
Quando você estiver instanciando uma consulta de contexto para um cliente gerenciado, não utilize new() para o localizador de serviço. Aqui está um exemplo que não é compatível com JSR 109 (novo ServiceLocator):
Properties prop = new Properties();
InitialContext ctx = new InitialContext(prop);
FredsBankServiceLocator locator = new FredsBankServiceLocator();
FredsBank fb = locator.getFredsBank(url);
long balance = fb.getBalance();
A Mensagem de Erro WSEC6500E: Não há candidato usado para login é Exibida
Causa:
- A segurança do aplicativo é ativada, mas a mensagem SOAP de entrada não contém o token de segurança necessário especificado na parte do responsável pela chamada do consumidor para o serviço.
- Um cliente de serviços da Web chama os serviços da Web usando o Web Services Security e a segurança do aplicativo está desativada no servidor de aplicativos que hospeda o serviço da Web.
Por exemplo, um serviço da Web pode ser configurado para autenticação usando um token Nome de usuário ou o token LTPA. No entanto, ele será implementado em um servidor de aplicativos em que a segurança global está desativada. Quando o serviço da Web é chamado por um cliente de serviço da Web, que fornece corretamente o token Nome de usuário ou o token LTPA necessário, a chamada do serviço da Web falhará. A seguinte falha pode ser retornada para o cliente de serviço da Web:
<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>
Solução:
Se a segurança do aplicativo estiver ativada no servidor de aplicativo que hospeda o serviço da Web, certifique-se de que o cliente esteja configurado corretamente para enviar o token de segurança que é necessário pelo serviço da Web na configuração da parte do responsável pela chamada do consumidor do Web Services Security.
- Ative a segurança do aplicativo no servidor de aplicativos que hospeda o serviço da Web.
- Configure a propriedade customizada do Web Services Security com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled no serviço da Web.
A propriedade com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled permite que o Web Services Security não processe o cabeçalho do WS-Security se a segurança do aplicativo estiver desativada. Isso permite que os administradores de sistema e os programadores de aplicativo depurem os aspectos dos serviços em um ambiente não seguro sem ter que remover as informações do WS-Security de seus descritores de implementação. O uso dessa propriedade só se destina para fins de diagnósticos e não para um ambiente de produção.
Os valores válidos para essa propriedade são true e false. O valor padrão é false.
O nível do aplicativo, o nível de célula e o nível do servidor são os níveis de ligação oferecidos pelo WebSphere Application Server.
- Clique em .
- Em Segurança, clique em Serviços da Web: Ligações Padrão de Web Services Security.
- Execute um dos seguintes procedimentos:
- Clique em (pode se aplicar a todos os aplicativos da célula).
- Clique em (pode se aplicar a todos os aplicativos da célula).
- Clique em .
- Em Ligações do Gerador Padrão ou Ligações do Consumidor Padrão, clique em Propriedades.
- Em Segurança, clique em Serviços da Web: Ligações Padrão de Web Services Security.
- Execute uma das seguintes opções, especificadas nos locais a seguir, na ordem de prioridade:
- Clique em .
- Clique em .
- Clique em .
- Em Infraestrutura do Servidor, clique em .
- Em Propriedades Adicionais, clique em Java Virtual Machine.
- Em Propriedades Adicionais, clique em Propriedades Personalizadas.
O identificador de chave SHA-1 para o token de Kerberos não é consumido ou gerado corretamente sem uma propriedade customizada.
Causa:
Conforme especificado no padrão OASIS denominado Web Services Security Kerberos Token Profile v1.1, uma codificação base64 de um valor de chave transformado SHA-1 pode ser usado para especificar um identificador de chave para um token AP-REQ Kerberos. O SHA-1 é uma função hash criptográfica que transforma uma entrada e retorna uma cadeia de tamanho fixo. Depois que o cliente e o provedor de serviços trocarem uma mensagem de serviços da Web inicial, o identificador de chave SHA-1 será usado para referenciar externamente o token de autenticação Kerberos. Para usar o SHA-1 para esse propósito, você deve configurar uma propriedade customizada nas ligações de política para gerar e consumir o identificador de chave SHA-1. A propriedade customizada com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken é incluída no gerador de token do cliente e nas ligações do consumidor de token de serviço. Essa propriedade permite que o aplicativo gere e consuma corretamente o identificador de chave SHA-1 durante trocas subsequentes de mensagens de serviços da Web quando o token do Kerberos for usado como um token de autenticação.
Solução:
Se um aplicativo gerar ou consumir um identificador de chave SHA-1 para cada troca de mensagens de serviços da Web, configure a propriedade customizada com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken para true no gerador de token e as ligações do consumidor de token para o aplicativo.
- Clique em .
- Clique em .
- Clique na política WS-Security na tabela Políticas.
- Clique no link Autenticação e Proteção na seção de ligações da política de segurança.
- Em Tokens de Autenticação, clique no nome do consumidor ou do gerador de token.
- Na seção Propriedades Customizadas, insira a propriedade customizada com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken e o valor da propriedade true.
- Clique em OK e, em seguida, clique em Salvar.
O token binário AP_REQ do Kerberos V5 não é gerado ou consumido corretamente sem uma propriedade customizada
Causa:
Quando os aplicativos de serviço da Web da Microsoft® solicitarem mensagens usando um token do Kerberos, você deverá configurar uma propriedade customizada nas ligações de política para o token Kerberos V5 AP_REQ para gerar e consumir o token. Inclua a propriedade customizada com.ibm.wsspi.wssecurity.kerberos.attach.apreq no gerador de token do cliente e nas ligações do consumidor de token de serviço. Ativar essa propriedade permite que o aplicativo gere e consuma o token Kerberos AP_REQ para cada mensagem de solicitação de serviços da Web.
Solução:
- Para interoperar com os aplicativos clientes do Microsoft .NET, configure a propriedade customizada como true nas ligações do consumidor de token para o serviço de destino.
- Para interoperar com os serviços do Microsoft .NET, configure a propriedade customizada para true nas ligações do gerador de token do cliente.
- Se um aplicativo gerar o token Kerberos AP_REQ para cada mensagem de serviços da web, configure a propriedade customizada como true nas ligações do gerador de token do cliente e nas ligações do consumidor de token do serviço.
- No console administrativo, clique em .
- Clique em .
- Clique na política WS-Security na tabela Políticas.
- Clique no link Autenticação e Proteção na seção de ligações da política de segurança.
- Em Tokens de Proteção, clique no nome do consumidor ou do gerador de token.
- Na seção Propriedades Customizadas, insira a propriedade customizada com.ibm.wsspi.wssecurity.kerberos.attach.apreq e o valor da propriedade (true).
Em vez de emitir uma exceção do CertPath, um caminho de certificação válido é criado no Sun Solaris quando um certificado inválido é utilizado
Causa:
Os aplicativos de serviços da Web ativados do WS-Security em um sistema Sun Solaris podem construir incorretamente um caminho de certificação válido mesmo se um certificado inválido for usado. Quando a chave no certificado em um pedido e a chave no certificado recuperado no servidor não correspondem, uma mensagem de erro deve ser emitida. Entretanto, quando os certificados diferem em cada aspecto, exceto para DN, e o provedor de segurança Sun é utilizado, o caminho de certificação é retornado como válido. Esse problema não ocorre quando o provedor de segurança IBMCertPath é utilizado. O IBMCertPath é o provedor de segurança padrão em todos os sistemas, exceto Sun Solaris; portanto, o Sun Solaris é o único sistema no qual esse problema ocorre.
- Quando o serviço da Web é implementado em sistemas não Sun Solaris, o provedor padrão IBM CertPath (IBMCertPath)
será retornado. Quando o código funcionar corretamente, você verá a seguinte exceção porque as chaves não correspondem:
WSEC5085E: Unable to build a valid CertPath: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
- Quando o serviço da web é implementado no Sun Solaris, o método java.security.cert.CertPathBuilder.build retorna o provedor CertPath padrão do Sun, em vez do IBMCertPath.
O provedor de segurança Sun verifica apenas o DN (nome distinto) e não verifica as informações de assinatura.
O pedido deve falhar devido à chave incorreta. No entanto, o CertPath inválido é retornado como válido porque apenas o DN foi verificado. Os aplicativos de serviços da Web em execução no Sun Solaris poderiam construir incorretamente um CertPath válido se a entrada inválida fornecida for diferente em cada aspecto de um certificado no servidor, exceto para o DN.
Solução:
Uma nova propriedade foi incluída para o WebSphere Application Server v 6.0.2 e posteriores: com.ibm.wsspi.wssecurity.config.CertStore.Provider
Essa propriedade permite que o Web Services Security, quando em execução no WebSphere Application Server no Solaris, use o provedor IBMCertPath em vez de usar o provedor Sun CertPath. Essa propriedade é o provedor de segurança que o Web Services Security deve usar quando usar âncoras de confiança e quando o provedor de segurança de armazenamento de certificado for especificado em conjunto com o armazenamento de certificado.
Se com.ibm.wsspi.wssecurity.config.CertStore.Provider estiver especificada e um provedor de segurança for especificado para o armazenamento de conteúdo, o provedor de segurança do armazenamento de certificados substituirá a configuração de com.ibm.wsspi.wssecurity.config.CertStore.Provider.
Pedidos Criptográficos de Hardware com Exceções Relacionadas à Placa Devem Utilizar Software Criptográfico para Concluir Pedidos com Êxito
Causa:
Exceções relacionadas a dispositivos criptográficos de hardware podem ser vistas quando a máquina está enfrentando uma sobrecarga. Os pedidos são concluídos com êxito porque o software criptográfico é utilizado para a operação específica que recebeu a exceção. No entanto, o dispositivo criptográfico de hardware não é utilizado.
CWWSS5601E: The following exception occurred while decrypting the message:
com.ibm.pkcs11.PKCS11Exception: Outra operação já está ativa
eCWWSS5601E: Ocorreu a seguinte exceção ao decriptografar a mensagem: O manipulador de chaves é inválido:
com.ibm.pkcs11.PKCS11Exception: O identificador de chave é inválido
Esse problema só ocorre quando o cartão criptográfico de hardware está manipulando um número excessivo de operações.
Solução:
Não há soluções alternativas conhecidas. No entanto, os pedidos são concluídos com êxito porque a criptografia de software é utilizada quando a criptografia de hardware falha para uma operação.