Sugerencias para la resolución de problemas de la seguridad de servicios web

Para solucionar los problemas de seguridad de los servicios web, revise las configuraciones con las herramientas de ensamblaje para que pueda comparar las configuraciones de solicitud y respuesta de cliente y servidor.

La mejora manera de solucionar problemas de seguridad de los servicios web es revisar las configuraciones con herramientas de ensamblaje para que pueda comparar las configuraciones de solicitud y respuesta de cliente y servidor. Estas configuraciones deben coincidir. La configuración del remitente de la solicitud del cliente debe coincidir con la configuración del receptor de la solicitud del servidor. Para que el cifrado se realice correctamente, debe exportarse la clave pública del receptor al remitente y esta clave debe configurarse correctamente en la información de cifrado. Para la autenticación, debe especificar el método que utiliza el cliente en la correlación de inicio de sesión del servidor.

Los pasos siguientes incluyen una lista de pasos genéricos que puede efectuar para la resolución de problemas.

Pasos para realizar esta tarea

  1. Verifique que las extensiones de seguridad del cliente y las del servidor coinciden en cada llamada en sentido descendente para los remitentes y los destinatarios siguientes:
    • Remitente y destinatario de la solicitud
    • Remitente y destinatario de la respuesta
  2. Verifique que cuando está habilitada la opción Añadir indicación de la hora de creación en el cliente, el servidor tiene configurada la opción Añadir indicación de la hora de recepción. Debe configurar las extensiones de seguridad en la herramienta de ensamblaje.
  3. Verifique que los enlaces de seguridad del cliente y del servidor están configurados correctamente. Cuando el método de autenticación del cliente es por firma, asegúrese de que el servidor tiene una correlación de inicio de sesión. Cuando el cliente utiliza la clave pública cn=Bob,o=IBM,c=US para cifrar el cuerpo, verifique que este Asunto es un certificado personal del almacén de claves del servidor de modo que puede descifrar el cuerpo con la clave privada. Puede configurar los enlaces de seguridad utilizando la herramienta de ensamblaje o la consola administrativa de WebSphere Application Server.
  4. Compruebe en el archivo SystemOut.log del directorio ${USER_INSTALL_ROOT}/logs/servidor1 (servidor1 cambia en función del nombre de servidor) si hay mensajes que puedan proporcionar información sobre el problema.
    Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.
  5. Habilite el rastreo en Web Services Security utilizando la siguiente especificación de rastreo:
    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

    Escriba las dos líneas anteriores como una sola línea.

Errores de protección de los servicios web

Es posible que se produzcan los errores siguientes cuando proteja los servicios web:

Se visualiza un mensaje de error de discrepancia de claves "CWWSS6811E: El identificador de clave <nombre identificador> recuperado del mensaje es diferente del identificador de clave <nombre identificador> adquirido del almacén de claves"

Causa:

Los archivos de almacén de claves de ejemplo incluidos con el producto se han actualizado porque algunos de los certificados van a caducar. Si las claves se utilizan en un entorno combinado, se produce un error de discrepancia de claves. Por ejemplo:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS6521E: Ha fallado el inicio de sesión 
debido a una excepción: javax.security.auth.login.LoginException: CWWSS6811E: 
El identificador de clave TVpC640XSSc= recuperado del mensaje es diferente del
 identificador de clave QdZLf+KjrUg= adquirido de la vía de acceso del almacén de claves: 
C:\WebSphere\AppServer\profiles\AppSrv01//etc/ws-security/samples/enc-receiver.jceks."
Los archivos de almacén de claves incluidos con el producto son ejemplos y no deben utilizarse en un entorno de producción. No obstante, si utiliza los archivos de ejemplo para probar un entorno de clúster combinado, los archivos deben sincronizarse para evitar el error de discrepancia de claves. Los archivos de almacén de claves se encuentran en un subdirectorio del directorio del perfil. Por ejemplo:

raíz_perfil/etc/ws-security/samples/dsig-sender.ks
raíz_perfil/etc/ws-security/samples/dsig-receiver.ks
raíz_perfil/etc/ws-security/samples/enc-sender.jceks
raíz_perfil/etc/ws-security/samples/enc-receiver.jceks
raíz_perfil/etc/ws-security/samples/intca2.cer

donde raíz_perfil es el directorio para un perfil de instancia determinado de WebSphere Application Server.
Los archivos de almacén de claves de ejemplo también se encuentran en el directorio de instalación:

raíz_servidor_aplicaciones/etc/ws-security/samples/dsig-sender.ks
raíz_servidor_aplicaciones/etc/ws-security/samples/dsig-receiver.ks
raíz_servidor_aplicaciones/etc/ws-security/samples/enc-sender.jceks
raíz_servidor_aplicaciones/etc/ws-security/samples/enc-receiver.jceks
raíz_servidor_aplicaciones/etc/ws-security/samples/intca2.cer

donde raíz_servidor_apl es la ubicación de instalación de WebSphere Application Server.

Solución:

Puede solucionar el error de falta de coincidencia de claves copiando manualmente los archivos del almacén de claves desde los nodos de la Versión 7.0 y posteriores en el clúster mixto a los nodos de la Versión 6.1 Feature Pack para servicios web. Esto garantiza que los nodos de la Versión 7.0, y posteriores, y los nodos de la Versión 6.1 Feature Pack para servicios web utilicen los mismos archivos de almacén de claves. Otro método alternativo consiste en desplazar los archivos de almacén de claves de la versión 7.0, y posteriores, a una ubicación de directorio común y luego modificar todos los vínculos para que apunten a la ubicación común de los archivos de almacén de claves.

Se muestra el mensaje CWWSI5061E: El body de SOAP no está firmado.

Causa:

Este error suele producirse cuando el manejador de seguridad SOAP no se carga correctamente, y no firma el cuerpo de SOAP. El manejador de seguridad SOAP suele ser la primera validación que se produce en el servidor, de modo que muchos problemas pueden originar que se muestre este mensaje. El error podría producirse por configuraciones de URI de actor no válidas.

Solución:

Puede configurar el URI (Universal Resource Identifier) del actor en las ubicaciones siguientes dentro de la herramienta de ensamblaje:

  • Desde el Editor de cliente de servicios web, dentro de la herramienta de ensamblaje para las configuraciones cliente:
    • Pulse Security Extensions > Client Service Configuration Details (Extensiones de seguridad > Detalles de configuración de servicio del cliente) e indique la información de actor en el campo ActorURI.
    • Pulse Security Extensions > Request Sender Configuration section > Details (Extensiones de seguridad > Sección Configuración del remitente de la petición > Detalles) e indique la información de actor en el campo Actor.
  • En el editor de servicios web de la herramienta de ensamblaje para configuraciones de servidor:
    • Pulse Security Extensions > Server Service Configuration (Extensiones de seguridad > Sección Configuración de servicio del servidor). Verifique que el URI de actor tiene la misma serie de actor que en el cliente.
    • Pulse Security Extensions > Response Sender Service Configuration Details > Details (Extensiones de seguridad > Detalles de configuración del servicio de remitente de respuesta > Detalles) e indique la información en el campo Actor.

La información de actor, tanto en el cliente como en el servidor, debe referirse a la misma serie. Cuando los campos de actor del cliente y del servidor coinciden, se actúa sobre la solicitud o respuesta en lugar de enviarlas en sentido descendente. Los campos de actor podrían ser distintos si tiene servicios web actuando como una pasarela para otros servicios web. No obstante, en todos los demás casos, verifique que la información de actor coincide en el cliente y el servidor. Cuando la implementación de servicios web actúa como una pasarela y no tiene el mismo actor configurado que la solicitud que se transfiere a la pasarela, esta implementación de servicios web no procesa el mensaje del cliente. En su lugar, envía la solicitud en sentido descendente. El proceso en sentido descendente que contiene la serie de actor correcta procesa la solicitud. La misma situación ocurre para la respuesta. Por lo tanto, es importante que verifique que están sincronizados los campos de actor del cliente y el servidor.

De modo adicional, el error puede aparecer cuando no especifica que se firme el cuerpo en la configuración cliente. Para firmar la parte de cuerpo del mensaje utilizando web Services Client Editor de la herramienta de ensamblaje, pulse Extensiones de seguridad > Configuración de emisor de solicitudes > Integridad y seleccione las partes del mensaje que desea firmar.

Se muestra el mensaje CWWSI5075E: No se ha encontrado ningún símbolo de seguridad que cumpla uno de los métodos de autenticación

Solución:

Verifique que la información de configuración de inicio de sesión del cliente y el servidor coincide con las extensiones de seguridad. Además, verifique que el cliente tiene un enlace de inicio de sesión válido y que el servidor tiene una correlación de inicio de sesión en los enlaces de seguridad. Puede comprobar esta información revisando las ubicaciones siguientes en la herramienta de ensamblaje:

  • Desde el Editor de cliente de servicios web, dentro de la herramienta de ensamblaje para las configuraciones cliente:
    • Pulse Extensiones de seguridad > Configuración de emisor de peticiones > Configuración de inicio de sesión y verifique el método de autenticación.
    • Pulse Enlace de puerto > Configuración de enlace del remitente de la petición de seguridad > Enlace de inicio de sesión y verifique el método de autenticación y otros parámetros.
  • En el editor de servicios web de la herramienta de ensamblaje para configuraciones de servidor:
    • Pulse Extensiones de seguridad > Detalles de configuración del servicio receptor de solicitudes > Configuración de inicio de sesión y verifique el método de autenticación.
    • Pulse Configuraciones de enlace > Detalles de configuración del enlace receptor de solicitudes > Correlación de inicio de sesión y verifique el método de autenticación y otros parámetros.

Además, asegúrese de que el URI de actor especificado en el cliente y el servidor coinciden. Puede configurar el URI del actor en las ubicaciones siguientes dentro de la herramienta de ensamblaje:

  • En el editor de clientes de servicios web de la herramienta de ensamblaje para configuraciones cliente:
    • Pulse Security Extensions > Client Service Configuration Details (Extensiones de seguridad > Detalles de configuración de servicio del cliente) e indique la información de actor en el campo ActorURI.
    • Pulse Security Extensions > Request Sender Configuration section > Details (Extensiones de seguridad > Sección Configuración del remitente de la petición > Detalles) e indique la información de actor en el campo Actor.
  • En el Editor de servicios web dentro de la herramienta de ensamblaje para configuraciones de servidor:
    • Pulse Security Extensions > Server Service Configuration (Extensiones de seguridad > Sección Configuración de servicio del servidor). Verifique que el URI de actor tiene la misma serie de actor que en el cliente.
    • Pulse Security Extensions > Response Sender Service Configuration Details > Details (Extensiones de seguridad > Detalles de configuración del servicio de remitente de respuesta > Detalles) e indique la información en el campo Actor.

Se visualiza el mensaje de error CWWSI5094E: No se ha encontrado la UsernameToken del usuario de confianza o el inicio de sesión ha fallado cuando la TrustMode es BasicAuth

Causa:

Esta situación se produce cuando tiene configurado IDAssertion en la configuración de inicio de sesión como el método de autenticación.

Solución:

En el servicio web de envío, configure una entrada de autenticación básica en el enlace de inicio de sesión. Luego, en el servidor, verifique que el evaluador de identidad de confianza tiene un conjunto de propiedades que contiene el nombre de usuario de esta entrada de autenticación básica.

Para configurar el cliente para la aserción de identidad, lea el tema sobre cómo configurar el cliente para la aserción de identidad´ cuando se especifica el método y cómo configurar el cliente para la aserción de identidad recopilando el método de autenticación.

Para configurar el servidor para la aserción de identidad, lea el tema sobre cómo configurar el servidor para que gestione la autenticación de la aserción de identidad y cómo configurar el servidor para que valide la información de la autenticación de la aserción de identidad.

Se visualiza el mensaje de error CWSCJ0053E: La autorización ha fallado para /UNAUTHENTICATED...

Causa:

Se produce el siguiente error de autorización con el nombre de seguridad UNAUTHENTICATED:
CWSCJ0053E: La autorización ha fallado para /UNAUTHENTICATED al invocar a (Home)com/ibm/wssvt/tc/
pli/ejb/Beneficiary findBeneficiaryBySsNo(java.lang.String):2 securityName: /UNAUTHENTICATED;accessID: 
no se otorga el valor null a ninguno de los roles necesarios: AgentRole

Esta situación se suele deber a que no se ha configurado una configuración de inicio de sesión o no se ha configurado la seguridad de servicios web desde el cliente al servidor. Cuando llega la solicitud al servidor y no se recibe la información de autenticación, se establece en la hebra el usuario UNAUTHENTICATED. La autorización devuelve este error si hay roles asignados al recurso excepto para el rol especial "Todos", que soporta el acceso para todos los usuarios.

Si el cliente se autentica correctamente con un archivo EJB (Enterprise JavaBeans) pero este archivo llama a otro EJB (Enterprise JavaBeans) en sentido descendente que no está configurado con la seguridad de servicios web o la seguridad de transporte, como el ID de usuario y contraseña de HTTP, puede producirse un error para esta solicitud en sentido descendente.

Solución:

Con la herramienta de ensamblaje, verifique que el archivo EAR (Enterprise ARchive) del cliente y el servidor tienen las extensiones y los enlaces de seguridad correctos. Si desea más información, consulte los temas siguientes:
  • Configuración de los enlaces de seguridad del cliente con una herramienta de ensamblaje
  • Configuración de los enlaces de seguridad en un servidor que actúa como un cliente con la consola administrativa
  • Configuración de los enlaces de seguridad del servidor con una herramienta de ensamblaje
  • Configuración de los enlaces de seguridad del servidor con la consola administrativa

Para configurar el cliente para la aserción de identidad, lea el tema sobre cómo configurar el cliente para la aserción de identidad´ cuando se especifica el método y cómo configurar el cliente para la aserción de identidad recopilando el método de autenticación.

Se visualiza el mensaje de error WSWS3243I: Información: Excepción de correlación WebServicesFault cuando especifica el nombre local del tipo de valor y el URI de un consumidor de símbolos o del generador de símbolos

Causa:

El URI del tipo de valor no es necesario para los siguientes nombres locales del tipo de valor definidos previamente:
  • Señal de nombre de usuario
  • Señal de certificado X509
  • Certificados X509 en una PKIPath
  • Una lista de certificados X509 y CRL en PKCS#7

Solución:

Si especifica uno de los nombres locales del tipo de valor, no especifique un valor para el campo de URI del tipo de valor.

Se muestra el mensaje de error "URI no válido: no se ha podido determinar el formato del URI" cuando utiliza un cliente .NET de Microsoft que accede a un servicio web para WebSphere Application Server

Causa:

El siguiente mensaje de excepción se muestra cuando se utiliza un cliente .NET de Microsoft que accede a un servicio web para WebSphere Application Server.
URI no válido: el formato del URI no se ha podido determinar.
Tipo de excepción:
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) 
En WebSphere Application Server, la seguridad de servicios web está habilitada y utiliza el atributo ActorURI. Este error se produce porque Microsoft .NET Web Services Enhancements (WSE) Versión 2.0 Service Pack 3 no soporta un valor de URI relativo para el atributo ActorURI. WSE Versión 2.0 Service Pack 3 da soporte a un URI (Uniform Resource Identifier) sólo para este atributo.

Solución:

Para trabajar con un cliente Microsoft .NET, debe configurar este atributo como un URI absoluto. Un ejemplo de un URI absoluto es: abc://miServicioWeb. Un ejemplo de un URI relativo es: miServicioWeb.

Para configurar el atributo ActorURI y utilizarlo con WebSphere Application Server, utilice la herramienta de ensamblaje de IBM para completar los pasos siguientes:
  1. Abra el editor de servicios web, pulse el separador Extensiones y expanda Configuración del servicio de servidor.
  2. Escriba el URI absoluto completo en el campo Actor.
  3. Expanda Detalles de configuración del servicio generador de respuestas > Detalles.
  4. Escriba el URI absoluto completo en el campo Actor.
Para obtener más información, consulte la información acerca de las herramientas de ensamblaje. .

Se visualiza el mensaje de error WSEC5502E: elemento inesperado como elemento de destino

Causa:

Si aparece el error siguiente, la causa puede ser una señal X.509 que se encuentra en un mensaje, pero que no tiene un consumidor de señales coincidente configurado. Este error se puede producir en las aplicaciones JAX-RPC del consumidor o del proveedor.
com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5502E: Elemento inesperado como elemento de destino: wsse:BinarySecurityToken
La causa de este error es que o bien se ha configurado una señal X.509 y se ha recibido una señal X.509v3, o se ha configurado una señal X.509v3 y se ha recibido una señal X.509. Esto sucede la mayoría de las veces cuando se reciben señales X.509v3 de Microsoft .NET. Para determinar si esta es la causa del problema, siga estos pasos:
  1. Obtenga un rastreo de WS-Security para el proceso que está produciendo el mensaje. Para obtener más información acerca de cómo implementar el rastreo de WS-Security, lea el tema sobre el rastreo de servicios web.
  2. Compruebe si el rastreo contiene información sobre el mensaje SOAP entrante:
    1. Desde el punto de la excepción, busque hacia atrás el término soapenv:env.
    2. Desde dicho punto, busque hacia atrás el término X509.
    3. Anote el tipo de la señal de seguridad X.509. ya sea #X509 o #X509v3.
  3. Si el rastreo no contiene información sobre el mensaje SOAP de entrada, por ejemplo, porque el rastreo no está completo, busque hacia atrás el término El tipo de valor del destino, empezando en el punto de la excepción. Esta búsqueda localizará la parte del rastreo que muestra qué señal de seguridad se estaba procesando en el momento del error. Anote el tipo de señal de seguridad, #X509 o #X509v3.
  4. Compruebe el tipo de señal de seguridad X.509 que se ha especificado en la configuración del consumidor:
    1. Desde el punto de la excepción, busque hacia atrás el término WSSConsumerConfig.
    2. Ahora busque hacia adelante el término #X509.
    3. Anote el tipo del consumidor de la señal de seguridad X.509 configurado, ya sea #X509 o #X509v3.
  5. Si el consumidor de la señal configurada no coincide con el tipo de señal de seguridad entrante, se confirma que la causa del error se encuentra en la no coincidencia del tipo de señal de seguridad.

Solución:

El consumidor de la señal configurada debe coincidir con el tipo, tal y como se especifica en la señal de seguridad de entrada. Si se determina que la causa del error, como se muestra en los pasos anteriores, es una no coincidencia de tipo de señal de seguridad, debe cambiar la configuración del proveedor o el consumidor de WS-Security para asegurarse de que los tipos de señal coincidan.

WSEC6664E: No está permitido nulo para PKIXBuilderParameters. La configuración de TrustAnchor y CertStoreList no es correcta.

Causa:

La vía de acceso del certificado no se ha configurado correctamente.

Solución:

Configure la vía de acceso del certificado realizando los pasos siguientes:
  1. En la consola administrativa, pulse Seguridad > Servicios Web.
  2. En la cabecera Enlace de consumidor predeterminado, pulse Información de firmas > nombre_configuración.
  3. Seleccione la opción Confiar en cualquiera o Información de firmas dedicada.

    Si selecciona la opción Información de firmas dedicada, seleccione un ancla de confianza y un almacén de certificados de las configuraciones que se proporcionan en las listas desplegables.

  4. Pulse Aceptar y Guardar para guardar la configuración maestra.

Se muestra el error de .NET de Microsoft WSE567: La señal de nombre de usuario de entrada debe contener nonce y una hora de creación para la característica de detección de reproducción

Causa:

En este escenario tiene un cliente de servicios web para WebSphere Application Server y un servicio web de .NET de Microsoft. El servicio web de .NET de Microsoft tiene una restricción ws-security para una señal de nombre de usuario configurada. Se genera la excepción siguiente desde el servidor .NET de Microsoft:

WSE567: La señal de nombre de usuario de entrada debe contener nonce y una hora de creación para la característica de detección de reproducción.

De forma predeterminada, el servicio web de .NET de Microsoft valida nonce y la indicación de la hora para la señal de nombre de usuario. No obstante, es opcional configurar las propiedades nonce y la indicación de la hora para un cliente de servicios web que utilice WebSphere Application Server.

Solución:

Efectúe los pasos siguientes para añadir las propiedades nonce y de indicación de la hora para una señal de nombre de usuario en un cliente de servicios web para WebSphere Application Server. Estos pasos implican una herramienta de ensamblaje.
  1. Abra el descriptor de despliegue del cliente de servicios web y pulse WS-Binding (Enlace de WS).
  2. Expanda las secciones Configuración de enlaces del generador de solicitudes de seguridad > Generador de señales.
  3. Pulse el nombre de la señal de nombre de usuario que ha creado y pulse Editar.
  4. En la sección Propiedades de la ventana Generador de señales, pulse Añadir.
  5. Escriba com.ibm.wsspi.wssecurity.token.username.addNonce en el campo Nombre para proporcionar el nombre de la propiedad nonce.
  6. Especifique true en el campo Valor.
  7. Pulse Añadir.
  8. Escriba com.ibm.wsspi.wssecurity.token.username.addTimestamp en el campo Nombre para proporcionar el nombre de la propiedad de indicación de la hora.
  9. En el campo Value, especifique true.
  10. Pulse Aceptar para guardar el descriptor de despliegue del cliente.

Las excepciones de seguridad de Java 2 se producen cuando se utiliza el paquete com.ibm.wsspi.wssecurity.auth.token con la seguridad de Java 2 habilitada

Causa:

Una aplicación crea excepciones de seguridad de Java™ 2, si utiliza el paquete com.ibm.wsspi.wssecurity.auth.token.* con la seguridad de Java 2 habilitada.

Se han establecido nuevos permisos de Java 2 para diferentes métodos públicos del paquete com.ibm.wsspi.wssecurity.auth.token.* en WebSphere Application Server Versión 6.1. Si la aplicación utiliza uno de los métodos públicos desde estas clases protegidas por los permisos de Java 2 y no tiene los permisos apropiados, la aplicación fallará. El mensaje de la excepción proporciona información que identifica las clases y publica métodos que se ven afectados con el nuevo permiso de seguridad de Java 2 correspondiente.

Solución:

Otorgue el permiso en el archivo was.policy para la aplicación:
  1. Utilice PolicyTool para editar los archivos de políticas. Siga los pasos apropiados para el sistema operativo.
  2. Añada todos los permisos al archivowas.policy que se empaqueta en el archivo EAR (Enterprise Archive ) de la aplicación. Si desea una granularidad más precisa para los permisos en el archivo was.policy para la aplicación, habilite los permisos necesarios para la aplicación basándose en las clases que necesita.
    Por ejemplo, si necesita acceder sólo a los métodos de X509BSToken, deberá añadir los siguientes permisos al archivo 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. Actualice el archivo was.policy en el archivo EAR de la aplicación.
  4. Desinstale la aplicación de WebSphere Application Server y vuélvala a instalar con el nuevo archivo EAR y el archivo was.policy actualizado.

Podría producirse una excepción cuando se confirma la integridad o confidencialidad para un elemento SOAP.

Causa:

Si un cliente confirma la integridad o confidencialidad para un elemento SOAP, pero falta el elemento en el mensaje, se emite una excepción.

Si el cliente requiere la aplicación de una firma o cifrado en un elemento SOAP, el elemento SOAP siempre debe estar presente. La presencia de este elemento no es opcional. Por ejemplo, si la configuración especifica que se debe aplicar la integridad o confidencialidad en el elemento wscontext. Si wscontext no aparece en el mensaje, se emite la siguiente excepción:

com.ibm.wsspi.wssecurity.SoapSecurityException: WSEC5636W: Objects 
se han encontrado los objetos para procesar con el dialecto 
[http://www.ibm.com/websphere/webservices/wssecurity/dialect-was] 
y la palabra clave [wscontext]

Solución:

Los desarrolladores de cliente deben asegurarse de que los elementos SOAP que son objetivo de la integridad o confidencialidad siempre aparecen en el mensaje SOAP. Si no puede garantizar que el elemento SOAP siempre estará presente, no convierta a los elementos SOAP en objeto de integridad o confidencialidad.

Excepciones de salida de cliente provocadas por la diferencia en los modelos de programación JSR-101 y JSR-109

Causa:

Algunas veces, las excepciones de salida de cliente se producen cuando se ejecuta el cliente. Las excepciones de salida de cliente podrían originarse por las diferencias en los modelos de programación JSR-101 versus JSR-109.

Puede configurar cualquier limitación de seguridad de servicios web como, por ejemplo: símbolo de nombre de usuario, símbolo X509, firma o cifrado de los elementos SOAP, etc. Por ejemplo, puede configurar la señal de nombre de usuario en un cliente y servicio de WebSphere Application Server. El cliente se configura para enviar una señal de nombre de usuario en la solicitud y el servidor se configura para esperarla. Pero si el cliente no envía una señal de nombre de usuario, el servidor rechaza la solicitud. Si el cliente no realiza una búsqueda de nombres JNDI (Java Naming and Directory Interface), el cliente probablemente no es un cliente JSR-109. Si no es un cliente JSR-109, el cliente no obtendrá la información de configuración de JSR-109, que incluye las configuraciones de seguridad, y la solicitud fallará.

Para el modelo de programación JSR-109, la invocación empieza con la búsqueda de JNDI, que permite adjuntar la información de configuración de seguridad. Para el modelo de programación JSR-101, no se realiza ninguna búsqueda de JNDI; así pues, no se puede adjuntar la información de configuración de seguridad.

Solución:

Este comportamiento no significa un problema con los modelos de programación JSR-101 y JSR-109. La seguridad de los servicios web no proporciona la información de configuración de seguridad de WebSphere Application Server a un cliente JSR-101.

La implementación de la seguridad de los servicios web funciona de acuerdo con las siguientes directrices:
  • La seguridad de los servicios web no está soportada para un cliente JSR-101.
  • Sólo puede configurar un cliente JSR-109 para utilizar la seguridad de los servicios web.

Si el cliente requiere la seguridad de los servicios web, debe ser un cliente JSR-109.

Se visualiza el mensaje de error "WSSecurityCon E WSEC5514E: se ha producido una excepción al procesar WS-Security"

Causa:

El cliente gestionado no tiene acceso al descriptor de despliegue de servicios web debido a que la llamada lookup() no ha utilizado JNDI (Java Naming and Directory Interface). Sin la llamada lookup(), el cliente no puede acceder al descriptor de despliegue. La configuración de la seguridad de servicios web está en el descriptor de despliegue de servicios web. La siguiente es una excepción detallada que se ha creado:
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)

Solución:

Para los clientes gestionados, la búsqueda de servicios se realiza mediante una búsqueda JNDI (Java Naming and Directory Interface). Consulte la información acerca de cómo configurar la seguridad de servicios web de señal de nombre de usuario, la seguridad de servicios web de firma digital y la seguridad de servicios web de la señal LTPA (Lightweight Third-Party Authentication). El siguiente es un ejemplo de una búsqueda de contexto compatible con 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();  

Cuando crea una instancia de una búsqueda de contexto para un cliente gestionado, no utilice new() como localizador de servicio. El siguiente es un ejemplo que no es compatible con JSR 109 (nuevo ServiceLocator):

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

Se muestra el mensaje de error WSEC6500E: No hay ningún candidato utilizado para el inicio de sesión

Causa:

Esta situación puede producirse en una de las condiciones siguientes:
  • La seguridad de la aplicación está habilitada, pero el mensaje SOAP de entrada no contiene la señal de seguridad necesaria en la parte de interlocutor del consumidor para el servicio.
  • Un cliente de servicio web está invocando los servicios web utilizando la seguridad de servicios web y la seguridad de aplicaciones está inhabilitada en el servidor de aplicaciones que aloja el servicio web.

Por ejemplo, es posible que se configure un servicio web para autenticación utilizando un símbolo Username o una señal LTPA. No obstante, se despliega en un servidor de aplicaciones en el que la seguridad global está inhabilitada. Cuando un cliente de servicios web invoca un servicio web, que proporciona correctamente la señal Username o LTPA, la invocación del servicio web fallará. Es posible que se devuelva el siguiente error al cliente de servicios 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>

Solución:

Si la seguridad de aplicaciones está habilitada en el servidor de aplicaciones que aloja el servicio web, asegúrese de que el cliente está configurado correctamente para enviar el símbolo de seguridad que requiere el servicio web en la configuración de la parte de interlocutor del consumidor de seguridad de los servicios web.

Si la seguridad de las aplicaciones no está habilitada en el servidor de aplicaciones que aloja el servicio web, realice una de las acciones siguientes:
  • Habilite la seguridad de las aplicaciones en el servidor de aplicaciones que aloja el servicio web.
  • Establezca la propiedad personalizada de Web Services Security com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled en el servicio web.

La propiedad com.ibm.wsspi.wssecurity.config.disableWSSIfApplicationSecurityDisabled permite que Web Services Security no procese la cabecera WS-Security si está inhabilitada la seguridad de la aplicación. Esta propiedad permite a los administradores del sistema y a los programadores de aplicaciones depurar aspectos de sus servicios en un entorno no seguro sin tener que suprimir la información de WS-Security de sus descriptores de despliegue. La utilización de esta propiedad sólo está indicada con fines de diagnóstico y no para un entorno de producción.

Los valores válidos para esta propiedad son true y false. El valor predeterminado es false.

El nivel de aplicación, el nivel de célula y el nivel de servidor son niveles de enlaces que ofrece WebSphere Application Server.

Para configurar los enlaces a nivel de servidor, que es el valor predeterminado:
  1. Pulse Servidores > Servidores de aplicaciones > <nombre_servidor>.
  2. En Seguridad, pulse Servicios Web: enlaces por omisión para Web Services Security.
  3. Realice una de las acciones siguientes:
    • Pulse >Enlaces de consumidor predeterminados > Propiedades (se puede aplicar a todas las aplicaciones de la célula).
    • Pulse Propiedades adicionales > Propiedades (se puede aplicar a todas las aplicaciones de la célula).
Para configurar los enlaces a nivel de célula y acceder a los enlaces predeterminados a nivel de célula:
  1. Pulse Seguridad > Servicios web.
  2. En Enlaces de generador predeterminados o Enlaces de consumidor predeterminados, pulse Propiedades.
  3. En Seguridad, pulse Servicios Web: enlaces por omisión para Web Services Security.
  4. Efectúe una de las acciones siguientes, especificadas en las ubicaciones siguientes, en orden de prioridad:
    • Pulse Enlaces del consumidor predeterminado > Propiedades.
    • Pulse Propiedades adicionales > Propiedades.
Para configurar una propiedad del sistema JVM:
  1. Pulse Servidores > Servidores de aplicaciones > <nombre_servidor>.
  2. En Infraestructura de servidor, pulse Java y gestión de procesos > Definición de proceso.
  3. En Propiedades adicionales, pulse Java Virtual Machine.
  4. En Propiedades adicionales, pulse Propiedades personalizadas.

El identificador de claves SHA-1 para la señal Kerberos no se consume o no se genera correctamente sin una propiedad personalizada

Causa:

Como se ha indicado en el estándar OASIS titulado Seguridad de servicios Web de OASIS: perfil de señales Kerberos 1.1, puede utilizarse una codificación base64 de un valor de clave transformado para especificar un identificador para una señal Kerberos AP-REQ. SHA-1 es una función hash criptográfica que transforma una entrada y devuelve una serie de tamaño fijo. Después de que el cliente y el proveedor de servicios intercambian un mensaje de servicios web inicial, se utiliza un identificador de clave SHA-1 para hacer referencia de forma externa al símbolo de autenticación Kerberos. Para utilizar SHA-1 con esta finalidad, debe configurar una propiedad personalizada en el enlace de políticas para generar y consumir el identificador de clave SHA-1. La propiedad personalizada com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken se añade a los enlaces de generador de señales de cliente y consumidor de señales de servicio. Esta propiedad permite que la aplicación genere y consuma correctamente el identificador de clave SHA-1 durante los intercambios subsiguientes de mensajes de servicios web cuando se utiliza la señal Kerberos como señal de autenticación.

Solución:

Si una aplicación genera o consume un identificador de clave SHA-1 para cada intercambio de mensajes de servicios web, establezca la propiedad personalizada com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken en true en el generador de símbolos y los enlaces del consumidor de símbolos para la aplicación.

Para definir la propiedad personalizada utilizando la consola de administración, siga estos pasos:
  1. Pulse Servicios > Conjuntos de políticas.
  2. Pulse Enlaces de conjunto de políticas del proveedor general > nombre_enlace.
  3. Pulse la política WS-Security en la tabla Políticas.
  4. Pulse Autenticación y protección en la sección de enlaces de políticas de seguridad.
  5. En Señales de autenticación, pulse el nombre del consumidor de señales o del generador de señales.
  6. En la sección Propiedades personalizadas, especifique la propiedad personalizada com.ibm.wsspi.wssecurity.kerberos.attach.hashKeySupportToken con el valor true.
  7. Pulse Aceptar y, a continuación, pulse Guardar.
Nota: Debe considerar la posibilidad de un ataque de personas interpuestas que puede interceptar la clave SHA-1 durante los intercambios de mensajes. Para proteger la clave SHA-1, utilice la seguridad de nivel de transporte, como SSL, o la seguridad de nivel de mensaje, incluida la signatura y el cifrado.

La señal AP_REQ binaria de Kerberos V5 no se genera ni consume correctamente sin una propiedad personalizada

Causa:

Cuando las aplicaciones de servicio web de Microsoft® solicitan mensajes utilizando un símbolo Kerberos, debe configurar una propiedad personalizada en los enlaces de políticas para que el símbolo AP_REQ de Kerberos V5 AP_REQ genere y consuma el símbolo. Añada la propiedad personalizada com.ibm.wsspi.wssecurity.kerberos.attach.apreq a los enlaces de generador de señales de cliente y consumidor de señales de servicio. Al habilitar esta propiedad, la aplicación puede generar y consumir el símbolo AP_REQ de Kerberos para cada mensaje de solicitud de servicios web.

Solución:

Si una aplicación genera o consume el símbolo AP_REQ de Kerberos V5 para cada mensaje de solicitud de servicios web, establezca la propiedad personalizada com.ibm.wsspi.wssecurity.kerberos.attach.apreq en true en el generador de símbolos y en los enlaces del consumidor de símbolos para la aplicación, como se indica a continuación:
  • Para interoperar con aplicaciones cliente de Microsoft .NET, defina la propiedad personalizada en true en los enlaces de consumidor de señales para el servicio de destino.
  • Para interoperar con servicios de Microsoft .NET, defina la propiedad personalizada en true en los enlaces de generador de señales de cliente.
  • Si una aplicación genera la señal AP_REQ de Kerberos para cada mensaje de servicios web, defina la propiedad personalizada true en los enlaces de generador de señales de cliente y los enlaces de consumidor de señales de servicio.
Nota: Generar y consumir una señal AP_REQ para cada mensaje de solicitud de servicio web tiene implicaciones para el rendimiento del producto en cuando a la eficiencia de proceso de mensajes y el uso de memoria.
Para establecer esta propiedad personalizada en la consola de administración, siga estos pasos:
  1. En la consola administrativa, pulse Servicios > Conjuntos de políticas.
  2. Pulse Enlaces de conjunto de políticas del proveedor general > nombre_enlace.
  3. Pulse en la política WS-Security en la tabla Políticas.
  4. Pulse Autenticación y protección en la sección de enlaces de políticas de seguridad.
  5. En Señales de protección, pulse el nombre del consumidor de señales o del generador de señales.
  6. En la sección Propiedades personalizadas, especifique la propiedad personalizada com.ibm.wsspi.wssecurity.kerberos.attach.apreq y el valor adecuado (true).

En lugar de emitir una excepción CertPath, se crea una vía de acceso de certificación válida en Sun Solaris cuando se utiliza un certificado no válido

Causa:

Las aplicaciones de servicios web habilitadas para WS-Security en un sistema Sun Solaris pueden crear de forma incorrecta una vía de acceso de certificación válida, incluso cuando se ha utilizado un certificado no válido. Cuando la clave del certificado en una solicitud y la clave del certificado recuperada en el servidor no coinciden, debe emitirse un mensaje de error. Sin embargo, cuando los certificados son diferentes en todos los sentidos excepto en el DN, y se utiliza el proveedor de seguridad de Sun, se devuelve la vía de acceso de certificación como válida. Este problema no se produce si se utiliza el proveedor de seguridad IBMCertPath. IBMCertPath es el proveedor de seguridad predeterminado en todos los sistemas excepto Sun Solaris, por tanto Sun Solaris es el único sistema en el que se da este problema.

  • Cuando se despliega un servicio web en sistemas que no sean Sun Solaris, se devuelve el proveedor de CertPath de IBM predeterminado (IBMCertPath). Cuando el código funcione correctamente, verá la excepción siguiente porque las claves no coinciden:
    WSEC5085E: No se puede crear una vía de acceso de certificación válida:  java.security.cert.CertPathBuilderException:  
    no se puede encontrar una vía de acceso de certificación válida para el destino solicitado
  • Cuando el servicio web se despliega en Sun Solaris, el método java.security.cert.CertPathBuilder.build devuelve el proveedor CertPath predeterminado de Sun, en lugar de IBMCertPath. El proveedor de seguridad de Sun sólo comprueba el nombre distinguido (DN) y no comprueba la información de firmas.

    La solicitud fallará debido a la clave incorrecta. No obstante, se devuelve una CertPath no válida debido a que únicamente se ha comprobado el DN. Las aplicaciones de servicios web que se ejecutan en Sun Solaris pueden haber creado incorrectamente un CertPath válido, si se les ha proporcionado entrada válida que es distinta en todos los aspectos a un certificado del extremo del servidor, salvo por el DN.

Solución:

Se ha añadido una propiedad nueva a WebSphere Application Server versión 6.0.2 y posterior: com.ibm.wsspi.wssecurity.config.CertStore.Provider

Esta propiedad permite que la seguridad de servicios web, cuando se ejecuta en WebSphere Application Server en Solaris, utilice el proveedor de IBMCertPath en lugar del proveedor de CertPath de Sun. Esta propiedad es el proveedor de seguridad que debe utilizar la seguridad de servicios web cuando se utilizan anclas de confianza, y cuando el proveedor de seguridad de almacén de certificados se ha especificado junto con el almacén de certificados.

Si se especifica com.ibm.wsspi.wssecurity.config.CertStore.Provider y un proveedor de seguridad para el almacén de certificados, el proveedor del almacén de certificados alterará temporalmente el valor para com.ibm.wsspi.wssecurity.config.CertStore.Provider.

Las solicitudes criptográficas de hardware con excepciones relacionadas con tarjetas deben utilizar software criptográfico para completar correctamente las solicitudes

Causa:

Pueden aparecer excepciones relacionadas con los dispositivos criptográficos de hardware cuando la máquina se ocupa de una carga pesada. Las solicitudes se completan correctamente porque se utiliza software criptográfico en lugar de la operación concreta que ha recibido la excepción. Sin embargo, no se utiliza el dispositivo criptográfico de hardware.

Se han visto las excepciones siguientes durante las pruebas con cargas de trabajo:
CWWSS5601E: Se ha producido la excepción siguiente al descifrar el mensaje: 
com.ibm.pkcs11.PKCS11Exception: Ya existe otra operación activa
y
CWWSS5601E: Se ha producido la excepción siguiente al descifrar el mensaje: el manejador de claves no es válido:
com.ibm.pkcs11.PKCS11Exception: El manejador de claves no es válido

Este problema sólo ocurre cuando la tarjeta criptográfica de hardware maneja un gran número de operaciones.

Solución:

No se dispone de ninguna solución. Sin embargo, las solicitudes se completan correctamente porque la criptografía de software se utiliza cuando la criptografía de hardware falla en una operación.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_troubleshoot
File name: rwbs_troubleshoot.html