Seguridad en los Servicios Web con Firma Simple
Los Servicios web se han convertido en la tecnología distribuida que jamás ha existido. Una configuración típica de un servicio web hace uso de muchas tecnologías diferentes, modelos de objetos y lenguajes de programación, que pueden incluir sencillos scripts en Perl y servicios web independientes implementados en C++ o Java, hasta las aplicaciones más sofisticadas construidas sobre servidores de aplicaciones J2EE. Ser posible interactuar sobre dichos entornos diversos es una de las fortalezas de los servicios web, pero esto tiene un precio: es dificil asegurar dichos sistemas. Es duro encontrar un estándar de seguridad común para todas las tecnologías implicadas. Hoy hablarero sobre la firma simple (single sign-on), la arquitectura de seguridad que ofrece una forma segura e interoperable de asegurar sistemas heterogéneos.
La Firma Simple -- El Concepto Básico
El principal problema cuando se usan las arquitecturas de seguridad más comunes con los servicios web es que la infraestructura de seguirad está muy distribuida y estas arquitecturas normalmente requieren que las características de seguridad y los algoritmos estén implementados en todas las partes del sistema. La verdad incontestable de todos los sistemas de seguridad es que el nivel de seguridad de la totalidad del sistema es el nivel de seguridad de la parte más débil. Esta obviamente trata con la inflexibilidad porque tenemos o que evitar ciertas tecnología o comprometer la seguridad de todo el sistema. Evitar tecnologías no es muy práctico y niega la principal razón por la que los servicios web son tan populares: pueden hacer un puente a cualquier tecnología. Una posible solución de este problema es la arquitectura "single sign-on" (SSO).
La idea básica de esta arquitectura es desplazar la complejidad de la arquitectura de seguridad al también llamado servicio SSO y así liberar otras partes del sistema de ciertas obligaciones de seguridad. En la arquitectura SSO, todos los algoritmos de seguidad se encuentra en un sólo servidor SSO que actúa como el único punto de autentificación para un dominio definido. Así, hay un segundo beneficio de la aproximación SSO para autentificación/registro: un usuario sólo tiene que firmar una vez, incluso aunque podría interactuar con muchos elementos seguros dentro de un dominio dado. El servidor SSO, que puede ser así mismo un servicio web, actúa como una envoltura alrededor de la infraestructura de seguridad existente que exporta varias características de seguridad como la autentificación
y la autorización. Principalmente nos concentraremos en la autentificación en el entorno SSO. Realmente, hay dos escenarios de SSO. Empezaremos con el más simple.
El Escenario Simple de SSO
En este escenario, la autentificación primero llama al servidor SSO y pide el token de autentificación que lo identifica en el dominio particular. Para poder obtener el token, primero debe proporcionar las credenciales de autentificación correctas. Hay varias formas para estas credenciales: deben ser, por ejemplo, un sencillo username/password o un certificado, pero también se podrían implementar otros métodos. El servidor SSO realiza una validación de las credenciales del usuario usando la infraestructura de seguridad subyancente, y sólo entonces envía un ticket que la aplicación llamante utiliza para autentificarse frente a otras aplicaciones. En el escenario simple, el token no impone ninguna información específica, simplemente es la identificación única para el usario en algún ámbito y tiempo definidos.
Después de que la aplicación invocada reciba el token, lo valida pasándolo al servidor SSO que entonces realiza el chequeo real. La siguiente imagen ilustra este concepto.
Las principales ventajas de la aproximación SSO son evidentes:
- Encapsulación de la infraestructura de seguridad subyacente en el servidor SSO. La implementación, el despliegue y el mantenimiento son más fáciles ya que ninguna de las partes comunicantes en el sistema distribuido necesita implementar individualmente todas las carecterísticas y mecanismos de seguridad.
- El interface SOAP del servidor SSO hace que la arquitectura SSO sea universal. Como mencionamos anteriormente, el SSO es él mismo un servicio web. Si el servidor SSO expone el WSDL de su interface, el API SSO se puede generar instantáneamente y puesto a disposición.
- El servidor SSO mejora la seguridad de todo el sistema ya que no se necesita pasar por todos los lados las
credenciales de seguridad. El único punto que acepta credenciales de seguridad es el propio servidor SSO. Además, la solución SSO permite la federación, por lo que la autentificación se puede realizar en un ámbito enorme (fuera del dominio de seguridad particular) mientras que la credenciales de seguridad permanecen dentro del dominio de seguridad particular.
SSO Avanzado -- usando SAML
En el ejemplo anterior eran necesarias las invocaciones al servidor SSO cada vez que se le pedía al usuario una verificación de identidad. Una aproximación más avanzada permite al propio token contener alguna información de seguridad importante que permite la validación sin tener que llamar al servidor SSO cada vez. El token contiene la información de autentificación o autorización. Esta información está 'firmada' por el servidor SSO, suponiendo que el receptor del token crea en el servidor SSO, no necesita hacer ninguna verificación posterior. El escenario descrito se muestra en el siguiente diagrama:
Hay un nuevo estándar para intercambiar información relacionada con la seguridad en XML llamado Security Assertions Markup Language (SAML). Actualmente se está completando en OASIS y su primera versión debe estar ya disponible. Básicamente, la información de seguridad descrita por SAML se expresa en forma de sentencias de asertos sobre sujetos de seguridad (por ejemplo, usuarios, máquinas o servicios). SAML define el protocolo mediante el cual el consumidor del servicio envía la solicitud SAML y la también llamada autoridad SAML devuelte la respuestas SAML con asertos. Hay tres tipos de asertos:
- La sentencia Authentication informa sobre la autentificación de un sujeto particular en un ámbito y tiempo
específicos.
- La Authorization decision permite o deniega a un sujeto el acceso a un recurso específico.
- Los Attributes además cualifican al sujeto (por ejemplo, información de la línea de crédito, ciudadanía, etc.).
El uso de SAML no está limitado al escenario SSO. Puede utilizarse en un sentido más amplio. Si nuestro servicio web entiende SAML no debería ser dificil renconfigurar la arquitectura de seguridad sin tener que re-codificar.
Podemos echar un vistazo a la solicitud de autorización SAML de abajo. Observa que contiene credenciales de usuario (nombre de usuario y password encriptada en nuestor caso) y algunas descripciones como requerimientos de respuesta, tipos de credenciales, etc.
<samlp:Request MajorVersion="1" MinorVersion="0"
RequestID="1fgtTGzMXSqpN++/LcFpBmZWrQg=">
<samlp:RespondWith>AuthenticationStatement</samlp:RespondWith>
<samlp:AuthenticationQuery>
<saml:Subject>
<saml:NameIdentifier Name="test"/>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
http://www.oasis-open.org/committies/security/docs/draft-sstc-core-25/password
</saml:ConfirmationMethod>
<saml:SubjectConfirmationData>
cGFzc3dvcmQ=
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
</samlp:AuthenticationQuery>
</samlp:Request>
La respuesta a esta solicitud contiene el aserto de autentificación con un atributo/condición que especifica el periodo de tiempo durante el cual la autentificación es válida:
<samlp:Response InResponseTo="1fgtTGzMXSqpN++/LcFpBmZWrQg="
MajorVersion="1" MinorVersion="0"
ResponseID="upuSGdmqx7ov01mExYlt+6bDCWE=">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success"/>
</samlp:Status>
<saml:Assertion AssertionID="+1UyxJDBUza+ao+LqMrE98wmhAI="
IssueInstant="2002-03-03T14:33:58.456" Issuer="WASPCard"
MajorVersion="1" MinorVersion="0">
<saml:Conditions NotBefore="2002-03-03T14:33:58.466"
NotOnOrAfter="2002-03-03T15:03:58.466"/>
<saml:AuthenticationStatement
AuthenticationInstant="2002-03-03T14:33:55.201"
AuthenticationMethod="http://www.oasis-open.org/committies/security/docs/draft-sstc-core-25/password">
<saml:Subject>
<saml:NameIdentifier Name="test" SecurityDomain="card:SQLDatabase"/>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
http://www.oasis-open.org/committies/security/docs/draft-sstc-core-25/password
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</samlp:Response>
NOTA:
El aserto de autentificación SAML está firmado, por eso la parte que lo recibe puede fácilmente hacer un chequeo del origen y decidir si cree el remitente del aserto SAML.
Instalación
Necesitaremos instalar Systinet WASP Server Advanced y WASP Card para poder ejecutar las demos. Esta sección describe los pasos básicos del proceso de instalación.
NOTA:
Necesitarás descargar la última versión (3.0.3 final) del servidor WASP para poder ejecutar las demos.
- Asegurate de tener instalado en tu máquina el Java SDK 1.3.x de Sun.
- Copia el archivo jaas.jar del paquete JAAS 1.0 de Sun (puedes descargarlo desde http://java.sun.com/products/jaas/index-10.html)
al subdirectorio lib\ext de todas las instalaciones del JRE (Java Runtime Environment).
- Copia los archivos jce1_2_1.jar, local_policy.jar, sunjce_provider.jar y US_export_policy.jar del paquete JCE 1.2.1 de Sun (puedes descargarlo desde http://java.sun.com/products/jce/index-121.html) al subdirectorio lib\ext de todas tus instalaciones del JRE (Java Runtime Environment).
- Cambia la siguiente sección en el fichero java.security en todas las instalaciones del JRE de:
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.rsajca.Provider
a
security.provider.1=com.sun.crypto.provider.SunJCE
security.provider.2=au.net.aba.crypto.provider.ABAProvider
security.provider.3=sun.security.provider.Sun
security.provider.4=com.sun.rsajca.Provider
NOTA:
Usualmente, al menos hay dos instalaciones del JRE en tu ordenador. Una está en el SDK en su subdirectorio jre y la otra en el subdirectorio JavaSoft\JRE en el directorio Program Files (por ejemplo C:\Program Files\JavaSoft\JRE). Tienes que realizar los pasos anteriores en las dos instalaciones.
- Descarga e instala el J2EE de Sun. Encontrarás el software en aquí.
- Descarga e instala WASP Server Advanced for Java versión 3.0.3. Puedes descargarlo desde http://www.systinet.com/products/wasp_advanced/download/license.html. Luego necesitarás descomprimirlo y ejecutar el script install.bat desde el subdirectorio bin.
- Instala la seguridad del Servidor WASP ejecutando el script install-security.bat desde el subdirectorio bin. Introduce todos los valores por defecto excepto el nombre de host del servidor (la primera entrada) donde deberías especificar tu nombre de host (te recomendamos utilizar "localhost").
- Descarga WASP Card desde http://www.systinet.com/eap/wasp_card/download/license.html. Copia los archivos cloudclient.jar y RmiJdbc.jar desde el subdirectorio lib\cloudscape de tu instalación del J2EE al subdirectorio etc\lib del tu directorio de instalación de WASP Card.
- Descarga
los ficheros de ejemplo. Descomprimelos en el
disco duro, para que residan en el directorio c:\wasp_demo. Luego modifica las variables de entorno para que apunten a los directorios de tus instalaciones de Java, J2EE, WASP Server y WASP Card en el fichero env.bat del directorio bin de c:\wasp_demo. Luego arranca la base de datos Cloudscape usando el script startDB.bat desdel el directorio bin de la instalación de los programas de ejemplo. Acepta todos los valores por defecto que ofrece el script.
- Para el WASP Server usando el script stopserver.bat del directorio c:\wasp_demo\bin\. NO PARES EL SERVIDOR DE UNA FORMA DISTINTA A ESTA porque si no se perderán todos los cambios realizados con la instalación de WASP Card.
- Arranca de nuevo el WASP Server usando el script startserver.bat.
- Ejecuta la consola de navegación de WASP Card apuntando tu navegador a la direccion
http://localhost:6060/waspcard/console y usa el enlace Register de la parte izquierda para registrar un usuario con el nombre de usuario test y la password password.. También necesitarás especificar algún otro atributo como dirección de correo, nombre completo, etc.
NOTA
Dependiendo de la versión de Cloudscape, podrías obtener un error cuando envies el primer comando a la consola de WASP Card
porque se podría haber actualizado la base de datos. Los comandos siguientes deberían funcionar sin ningún problema.
Ahora estamos preparados para ejecutar las demos.
Escenario Simple SSP -- ejemplo práctico
Todavía estamos intentando ganar algo de dinero en la bolsa. el ejemplo de obtención de stocks que usamos en las primeras secciones del tutorial demuestra la aproximación SSO simple. Toda la funcionalidad SSO está implementada en el cliente y en los procesadores de cabecera del servidor (com.systinet.demos.simple.ClientAuthenticator y com.systinet.demos.simple.ServerAuthenticator). El procesado de la cabecera del cliente toma el nombre de usuario y la password del contexto de llamada donde lo almacenó la aplicación cliente
(com.systinet.demos.simple.StockClient), une el servicio web del servidor SSO y luego obtiene el token de autorización llamando a su método generateAuthenticationToken proporcionándole el nombre de usuario y la password pasados. El token se adjunta al mensaje SOAP que se envía al servicio web de obtención de stocks. Aquí, es extraído del mensaje SOAP por el procesador de cabeceras del servidor (com.systinet.demos.simple.ServerAuthenticator) que lo une al servicio web SSO y llama a su método
verifyAuthenticationToken para la autentificación del token. El resultado de la autentificación y el nombre de usuario se pasan a través del contexto de llamada al servicio web del laldo del servidor. Observa que se han implementado algunos sencillos algoritmos de caché del token tanto en el cliente como en el servidor. También se utiliza Comunicación segura SOAP para hacer que hablar con el servicio web SSO y pasar el token se mantengan privados.
NOTA:
Todos los scripts utilizados en los siguientes pasos están localizados en el directorio c:\wasp_demo\bin\ de los ficheros de ejemplo.
- Ejecuta el servidor de bases de datos Cloudscaoe usando el script startDB.bat.
- Ejecuta el servidor WASP con el script startserver.bat .
- Despliega la demo del servicio web SSO usando el script deploy_simple.bat.
- Ejecuta la aplicación cliente con el script run_simple.bat y mira consolas del cliente y del servidor.
- Elimina la demo del servicio web SSO con el script undeploy_simple.bat.
NOTA:
Necesitarás especificar el nombre de usuario y la password del administrador de WASP (nombre de usuario = "admin" y password = "changeit") cuando despliegues y elimines el servicio web. Puedes aceptar los valores por defecto simplemente pulsando Enter.
Explorando SAML
La siguiente demostración muestra la autentificación usando SAML. Puedes ejecutar el GUI y envíar la solicitud SAML pulsando el botón
Get Token. Luego puedes chequear la solicitud SAML y la respuesta. El botón Call Service envía el mensaje SOAP al servicio web de autentificación con el aserto de autentificación SAML adjuntado como una cabecera SOAP, éste acepta la solicitud, la extrae del mensaje SOAP y luego realiza la verificación. Observa que la verificación se realiza verificando la firma digital del servidor SSO: no se necesita ninguna llamada al servidor SSO.
Todo el código relacionado con SAML están en las clases com.systinet.demos.saml.AuthenticatedService y
com.systinet.demos.saml.AuthenticatedServiceFrame.
Necesitarás ejecutar estos comandos para ejecutar la demo SAML:
- Ejecuta el servidor de bases de datos Cloudscaoe usando el script startDB.bat.
- Ejecuta el servidor WASP con el script startserver.bat .
- Despliega la demo del servicio web usando el script deploy_saml.bat.
- Ejecuta la aplicación cliente con el script run_saml.bat y chequea la salida de la solicitud SAML, la respuesta SAML y la descripción de la verificación del servidor.
- Elimina la demo del servicio web SSO con el script undeploy_saml.bat
Puedes usar la consola WASP (apunta el navegador HTTP a la dirección http://localhost:6060/admin/console) para ver
todos los mensajes SOAP intercambiados entre AuthenticatedService y el cliente GUI. Autentificate a tí mismo en la Consola WASP (usando admin/changeit) y expande el paquete SAMLSSO y el servicio SAMLSSO. Luego activa la depuración, ejecuta de nuevo el ejemplo y luego chequea la conversación SOAP. Deberías ver que el token SAML que se ha enviado desde el cliente GUI al servicio web AuthenticatedService en la cabecera del mensaje SOAP está firmado digitalmente. No podemos ver la firma digital en el GUI ya que se verifica de forma transparente y la elimina el marco de trabajo WASP.
NOTA:
Ninguna comunicación de este ejemplo está encriptada para poder ver el contenido del transporte. Obviamente, en los ejemplos de la vida real se debe emplear la encriptación.
Tutoriales
