Relación entre la seguridad de servicios web y la seguridad Java Platform, Enterprise Edition
En este artículo se describe la relación entre los modelos de seguridad de servicios web (seguridad a nivel de mensaje) y de seguridad de Java™ EE (Java Platform, Enterprise Edition). También incluye información sobre las comprobaciones de autorización basadas en roles de Java EE.
WebSphere Application Server da soporte a JSR (Java Specification Requests) 101 y JSR 109. JSR 101 y 109 definen servicios web para la arquitectura Java EE, para que pueda desarrollar y ejecutar servicios web en la arquitectura de componentes Java EE.
Protección de servicios web con la seguridad de WebSphere Application Server (seguridad basada en roles de Java EE)

El puerto de servicios web se puede proteger utilizando la seguridad basada en roles de Java EE. El remitente de los servicios web envía los datos de autenticación básica utilizando la cabecera HTTP. SSL (HTTPS) se puede utilizar para proteger el transporte. Cuando WebSphere Application Server recibe el mensaje SOAP, el contenedor web autentica al usuario (en este ejemplo, usuario1) y establece el contexto de seguridad de la llamada. Después de establecer el contexto de la llamada, el servlet del direccionador SOAP envía la solicitud a la implementación de los servicios web (la implementación puede ser JavaBeans o archivos de enterprise bean). Para las implementaciones de enterprise bean, el contenedor de EJB realiza una comprobación de autorización con la identidad de usuario1.
El puerto de servicios web también se puede proteger mediante el rol de Java EE. A continuación, el contenedor web realiza la autenticación antes de que se asigne la solicitud SOAP a la implementación de servicios web.
Protección de servicios web con la seguridad de servicios web a nivel de mensajes
También puede proteger los servicios web utilizando la seguridad de servicios web a nivel de mensajes. En este caso, puede firmar digitalmente o cifrar parte del mensaje. La seguridad de servicios web también da soporte a la propagación de señales de seguridad dentro del mensaje SOAP. En el ejemplo siguiente, se supone que el puerto de servicios web no está protegido con la seguridad basada en roles de Java EE y que el enterprise bean está protegido con la seguridad basada en roles de Java EE.

En este caso, el puerto de servicios web no está protegido con la seguridad basada en roles de Java EE. El motor de servicios web procesa el mensaje SOAP antes de que el cliente lo envíe al puerto de servicios web. El tiempo de ejecución de la seguridad de servicios web actúa según las restricciones de seguridad, por ejemplo, la firma digital, el cifrado o la generación (e inserción) de señales de seguridad en la cabecera SOAP. En este caso, se genera <wsse:UsernameToken> utilizando usuario1 y la contraseña. En el lado del servidor (receptor), los servicios web procesan el mensaje entrante y la seguridad de servicios web aplica las restricciones de seguridad. La aplicación de las restricciones incluye comprobar que los mensajes están firmados, cifrados y descifrados correctamente, autenticar la señal de seguridad y configurar el contexto de seguridad con la identidad autenticada. En este caso, usuario1 es la identidad autenticada. Por último, el mensaje SOAP se asigna a la implementación de servicios web (si la implementación es un archivo de enterprise bean, el contenedor de EJB (Enterprise JavaBeans) realiza una comprobación de autorización con usuario1). En este ejemplo también se puede utilizar SSL.
Combinación de los dos
El segundo caso muestra que la seguridad de servicios web puede complementar a la seguridad basada en roles de Java EE. Por ejemplo, se puede habilitar SSL a nivel de transporte para proporcionar un canal seguro. Asimismo, si la implementación de servicios web es un archivo de enterprise bean, puede optimizar la autorización basada en roles EJB realizando comprobaciones de autorización. El tiempo de ejecución de la seguridad de servicios web aprovecha la infraestructura de seguridad para establecer la identidad autenticada en el contexto de seguridad. La identidad autenticada se puede utilizar en la llamada en sentido descendente a los recursos Java EE (o a otros tipos de recursos).
La combinación de estos dos ejemplos puede tener pequeñas consecuencias. Por ejemplo, si el transporte HTTP envía datos de autenticación básica con usuario1 y la contraseña en la cabecera HTTP, pero se inserta también <wsse:UsernameToken> con usuario99 y letmein en la cabecera SOAP. En los casos anteriores, se realizan dos autenticaciones. El contenedor web realiza una autenticación de usuario1, y la seguridad de servicios web realiza otra para autenticar usuario99. El tiempo de ejecución de la seguridad de servicios web se ejecuta después del contenedor web y usuario99 es la identidad autenticada que se establece en el contexto de seguridad.
La seguridad de servicios web también puede propagar señales de identidad desde el remitente al receptor del transporte SOAP a través de JMS (Java Message Service).
Comprobaciones de autorización basadas en roles de Java EE
No existe un estándar para la autorización para los servicios web. No obstante, IBM y Microsoft Corporation han publicado conjuntamente un documento técnico una guía técnica sobre seguridad para los servicios web llamada Seguridad en un mundo de servicios web: arquitectura y mapas propuestos que incluye una propuesta para la especificación de WS-Authorization. No obstante, la especificación de WS-Authorization no se ha publicado.
La implementación existente de la seguridad de servicios web se basa en la especificación Servicios web para Java EE o la especificación JSR (Java Specification Requirements) 109. La implementación de la seguridad de servicios web se aprovecha de estas comprobaciones de autorización basadas en roles Java EE. Para obtener información sobre conceptos, consulte el tema sobre la autorización basada en roles. Si desarrolla un servicio web que requiera comprobaciones de autorización a nivel de método, debe utilizar beans de sesión sin estado para implementarlo. Para obtener más información sobre cómo utilizar beans de sesión sin estado para implementar un servicio web, lea los temas "Implementación de aplicaciones de servicios web con JAX-WS" o "Implementación de aplicaciones de servicios web con JAX-RPC", en función del modelo de programación. Asimismo, lea el tema sobre la protección de aplicaciones de enterprise bean. Si desarrolla un servicio web que se implemente como un servlet, puede utilizar la autorización basada en URL o más general en el contenedor web. No obstante, en esta situación, no puede utilizar la identidad de la seguridad de servicios web para las comprobaciones de autorización. En su lugar, puede utilizar la identidad del transporte. Si utiliza SOAP a través de HTTP, la identidad está en el transporte HTTP.