Introducción a los Servicios Web en Java

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.

1. Asegurate de tener instalado en tu m�quina el Java SDK 1.3.x de Sun.
2. 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).
3. 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).
4. 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.

5. Descarga e instala el J2EE de Sun. Encontrar�s el software en aqu�.
6. 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.
7. 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").
8. 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.
9. 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.
10. 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.
11. Arranca de nuevo el WASP Server usando el script startserver.bat.
12. 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.

1. Ejecuta el servidor de bases de datos Cloudscaoe usando el script startDB.bat.
2. Ejecuta el servidor WASP con el script startserver.bat .
3. Despliega la demo del servicio web SSO usando el script deploy_simple.bat.
4. Ejecuta la aplicaci�n cliente con el script run_simple.bat y mira consolas del cliente y del servidor.
5. 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:

1. Ejecuta el servidor de bases de datos Cloudscaoe usando el script startDB.bat.
2. Ejecuta el servidor WASP con el script startserver.bat .
3. Despliega la demo del servicio web usando el script deploy_saml.bat.
4. 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.
5. 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.