En esta p�gina veremos una presentaci�n sobre la seguridad y los servicios web. Empezaremos revisando algunos conceptos b�sicos, luego veremos algunas de las t�cnicas de seguridad m�s comunes como SSL (Secure Socket Layer). Despu�s examinaremos el proceso implicado en la autentificaci�n y autorizaci�n, as� como la privacidad de datos.
�Introducci�n a la Seguridad en los Servicios Web
Empezaremos con una breve introducci�n de los conceptos y arquitecturas que hay bajo la seguridad de un Servicio Web.
�Criptograf�a Asim�trica -- Claves Privada y P�blica
Durante la Segunda Guerra Mundial, la marina de los EEUU encontr� que una de las mejores formas de encriptar las transmisiones de radio era hablar en el idioma de los Indios Navajos, un idioma al que no se le conocia ninguna conexi�n ling�itisca con ning�n otro idioma. Nunca se pudo romper esta t�cnica rudimentaria, y se crearon libros de c�digo m�s complejos y mecanismos computacionales.
La criptograf�a moderna ha avanzado considerablemente desde entonces. Para los prop�sitos de esta explicaci�n, hay dos tipos b�sicos de algoritmos de criptograf�a: sim�trico (o convencional) y asim�trico (tambi�n conocido como criptograf�a de clave p�blica-privada). Para la encriptaci�n sim�trica, la clave (o c�digo) que se usa para encriptar el mensaje es el mismo que se usa para desencriptarlo. Para la encriptaci�n asim�trica, se utilizan dos claves diferentes para bloquear y desbloquear (encriptar y desencriptar) los mensajes y ficheros. Las dos clase se enlazan matem�ticamente pero la derivaci�n de una de la otra no es factible matem�ticamente hablando. Una clave p�blica de un individuo se distribuye a otros usuarios y estos la utilizan para encriptar mensajes para ese individuo. El individuo mantiene en secreto la clave privada y la usa para desencriptar los mensajes enviados con la clave p�blica.
Desde el punto de vista computacional, pasar mensajes usando la encriptaci�n sim�trica es m�s eficiente y consume menos recursos que el m�todo asim�trico. La asimetr�a tiene sus ventajas cuando se trabaja en grandes comunidades porque se puede distribuir libremente la clave 'p�blica'.
�Identidades
La identidad es la piedra angular que permite que los servicios web funcionen juntos. Hoy en d�a la mayor�a de los servicios web trabajan en solitario, pero todo el mundo habla de ensamblar Servicios Web para crear servicios de negocios m�s complejos y poderosos. El ensamblaje de servicios web requiere que los servicios compartan informaci�n, particularmente una vez que hemos empezado a a�adir seguridad a nuestros servicios.
Consideremos como implementan la seguridad la mayoria de los Servicios Web de hoy en d�a. Cada negocio que ofrece un Servicio Web seguro mantiene una lista de usuarios autorizados, y cada usuario se autentifica a s� mismo usando un reto userid/password. Esto no tiene sentido para servicios web complejos, y est� es una de las razones por las que hemos oido como grandes compa��as como Microsoft anuncian que Passport soportar� autentificaci�n federada usando Kerberos V5.0, y Sun lanza el proyecto Liberty Alliance.
Las identidades se usaban durante la autentificaci�n entre puntos de comunicaci�n, permitiendo la identificaci�n y por lo tanto la autorizaci�n, auditor�a, etc. La aproximaci�n m�s com�n hoy en d�a es que cada identidad de seguridad tiene un nombre, una clave privada y un certificado X.509. Este certificado contiene caracter�sticas p�blicas (credenciales aka) de una identidad particular, incluyendo la clave p�blica.
�La Firma de Datos
La firma de datos es s�lo proporcionar el origen de los datos. Si uno encripta los datos usando la clave privada entonces cualquiera que pueda descriptarlos correctamente puede f�cilmente acceder al origen de los datos: una desencriptaci�n correcta significa que los datos fueron encriptados con la correspondiente clave privada. Como la clave privada siempre se mantiene privada y nunca abandona la posesi�n de la persona que la gener�, la correcta desencriptaci�n de los datos protege su origen.
Desafortunadamente, los algoritmos asim�tricos son bastante lentos, por eso se usan funciones especiales (como MD5 o SHA). Estas funciones hash especiales primero calculan la huella de los datos (por ejemplo, 16 bytes para MD5 y 20 bytes para SHA) que luego es firmada. La parte receptora calcula la huella usando la misma funci�n, desencripta la huella firmada usando la clave p�blica, y finalmente compara las huellas calculadas y la desencriptada. Si ambas huellas son iguales entonces se ha verificado el origen de los datos.
�Certificados Verdaderos
Veamos como se crean los certificados. Primero se genera la pareja de claves (p�blica y privada). Luego, se crea un Certificate Signing Request (CSR). Un CSR simplemente es una colecci�n de datos que contiene toda la informaci�n que se incluir� en el certificado (incluyendo la clave p�blica) y que se firma con la clave privada generada. Luego, el CSR se env�a a una Autoridad de Certificaci�n que crea el certificado y lo firma con su clave privada. Firmando el certificado la Autoridad de Certificaci�n verifica que el certificado contiene datos v�lidos. Cualquiera que crea en el Autoridad de Certificaci�n puede usar su certificado (m�s precisamente su clave p�blica) y verificar el certificado firmado. El echo de que creamos en algunas identidades se expresa almacenando sus certificados en un almacen especial. La verificaci�n del certificado se puede extender m�s niveles, un certificado puede estar firmado por alguna identidad que est� firmada por otra entidad, etc. Si alguno de los certificados de la cadena se considera como verdadero esto significa que todos los dem�s certificados de la cadena tambi�n son verdaderos.
�Los Servicios Web y los Mecanismos del API Secure
Las tecnolog�as de seguridad tradicionales no son suficientes para los Servicios Web. El principal problema es su dependencia del transporte. Por ejemplo, la tecnolog�a de seguridad m�s usada, SSL (Secure Socket Layer), est� atada a un punto final de la comunicaci�n de red. M�s precisamente, la identidad s�lo se puede asignar con el punto de la comunicaci�n que normalmente comparten muchos Servicios Web.
Otras tecnolog�as de seguridad, como GSS-API (Generic Security Service Application Programmers Interface) y mecanismos de seguridad basadas en �sta como SPKM (Simple Public Key Mechanism) y Kerberos, est�n dise�ados especificamente para usarlos en arquitecturas de acoplamiento d�bil. GSS-API es independiente tanto del transporte como de los mecanismos de seguridad (independencia de los mecanismos de seguridad significa que las tecnolog�as subyacentes para la criptograf�a, representaci�n de identidad y firma de datos est�n totalmente encapsuladas). El mecanismo de seguridad en Servicios Web sigue siendo SSL pero se est� incrementando el uso de SPKM y Kerberos. SPKM est� basado en elementos de criptograf�a asim�trica explicados m�s arriba, por eso es ideal para entornos de Servicios Web altamente dispersos; Kerberos usa criptograf�a sim�trica.
�Seguridad en Acci�n: Autentificaci�n, Autorizaci�n y Privacidad de los Datos
La autentificaci�n, la autorizaci�n y la privacidad de los datos son los tres elementos principales de una arquitectura de seguridad. Veamos un sencillo ejemplo que muestra estos conceptos. Empezar� con una simple implementaci�n de una funcionalidad de cuenta bancaria. Echa un vistazo al c�digo de la clase AccountImpl.java:
/*
* AccountImpl.java
*
* Created on December 13, 2001, 9:25 AM
*/
package com.systinet.demos.bank;
// imports of WASP security
import org.idoox.security.AuthResult;
import org.idoox.security.Credentials;
import org.idoox.security.PrincipalAuthenticator;
import org.idoox.security.server.Current;
import org.idoox.webservice.server.Initializable;
import org.idoox.webservice.server.WebServiceContext;
/**
* Account implementation
*/
public class AccountImpl
implements Account, Initializable {
private double balance = 0;
private String number = "";
public AccountImpl() {
this.number = ""+System.currentTimeMillis();
}
public void init(WebServiceContext context) {
authenticate();
}
public void destroy() {
// do nothing here
}
/**
* Deposits to the account
* @param amount amount of many to deposit
* @throws AuthenticationException if authentication fails
*/
synchronized public void deposit(double amount)
throws AuthenticationException {
checkAuth();
this.balance += amount;
}
/**
* Withdraw from the account
* @param amount amount to withdraw
* @throws UnsufficientFundsException thrown if account doesn't hava enough funds
* @throws AuthenticationException if authentication fails
*/
synchronized public void withdraw(double amount)
throws UnsufficientFundsException, AuthenticationException {
checkAuth();
if(amount < this.balance) {
this.balance = this.balance - amount;
}
else {
throw new UnsufficientFundsException("The withdrawal of " + amount +
" was requested but the balance is only " +
this.balance+" .");
}
}
/**
* Returns the account balance
* @return the actual balance of the account
* @throws AuthenticationException if authentication fails
*/
synchronized public double getBalance()
throws AuthenticationException {
checkAuth();
return this.balance;
}
/**
* Sets the account balance
* @param amount the actual balance of the account
* @throws AuthenticationException if authentication fails
*/
synchronized public void setBalance(double amount)
throws AuthenticationException {
checkAuth();
this.balance = amount;
}
/**
* Returns the account number
* @return account number
* @throws AuthenticationException if authentication fails
*/
public String getAccountNumber()
throws AuthenticationException {
checkAuth();
return this.number;
}
/**
* Sets the account number
* @param accountNumber account number
* @throws AuthenticationException if authentication fails
*/
public void setAccountNumber(String accountNumber)
throws AuthenticationException {
checkAuth();
this.number = accountNumber;
}
/**
* Close the account
* @throws AuthenticationException if authentication fails
*/
public void close()
throws AuthenticationException {
checkAuth();
org.idoox.webservice.server.WebServiceContext context =
org.idoox.webservice.server.WebServiceContext.getInstance();
org.idoox.webservice.server.LifeCycleService lc =
context.getLifeCycleService();
lc.disposeServiceInstance(this);
}
/**
* Creates and sets the security identity credentials if they are
* not alread set
*/
private synchronized void authenticate() {
Current current = Current.getInstance();
if (current.getCredentials() == null) {
PrincipalAuthenticator auth = current.getAuthenticator();
AuthResult result = auth.authenticate("bank-server", "password".getBytes());
if (result.resultCode != AuthResult.AUTH_STATUS_SUCCESS) {
System.err.println("Unable to authenticate");
}
current.setCredentials(new Credentials[] { result.creds });
}
}
/**
* Performs very simple authorization based on the hardcoded
* identity name, which is able to manipulate the account.
*
* @throws AuthenticationException if the client is not authorized
*/
private void checkAuth()
throws AuthenticationException {
Current current = Current.getInstance();
Credentials credentials = current.getReceivedCredentials();
if(credentials != null) {
String caller = credentials.getName();
if(caller == null || !caller.equals("john")) {
throw new AuthenticationException("Access denied.");
}
}
}
}
Todo el c�digo relacionado con la seguridad est� en los dos m�todos que hay al final de la clase authenticate y checkAuth. El m�todo authenticate abre un almacen de certificados local y recupera las credenciales p�blicas protegidas por password (representadas por la clave privada de la identidad y el certificado X.509) que posteriormente se utilizan para la autentificaci�n del servicio. El c�digo del cliente es casi id�ntico. Chequea el c�digo de la clase BankClient.java que realiza la autentificaci�n al prinicipio de su m�todo main:
/*
* This is a WASP client.
* BankClient.java
* Created on December 13, 2001, 10:41 AM
*/
package com.systinet.demos.bank;
import org.idoox.webservice.client.WebServiceLookup;
import org.idoox.wasp.Context;
// imports of WASP security
import org.idoox.security.AuthResult;
import org.idoox.security.Credentials;
import org.idoox.security.PrincipalAuthenticator;
import org.idoox.security.client.Current;
/**
* Bank client application
*/
public class BankClient extends Object {
/**
* Runs the demo on the client-side
* @param args the command line arguments
*/
public static void main (String args[])
throws Exception {
String username = args[0];
String password = args[1];
if(username == null)
username = "john";
if(password == null)
password = "password";
System.out.println("Authenticating user "+username);
// init the lookup
WebServiceLookup lookup = (WebServiceLookup)
Context.getInstance(Context.WEBSERVICE_LOOKUP);
// obtain and set the crededentials
Current current = Current.getInstance();
PrincipalAuthenticator auth = current.getAuthenticator();
AuthResult result = auth.authenticate(username, password.getBytes());
if (result.resultCode != AuthResult.AUTH_STATUS_SUCCESS) {
System.err.println("Unable to authenticate");
return;
}
current.setCredentials(new Credentials[] { result.creds });
// get the proxy to the Web Service from the lookup
Account account = (Account)
lookup.lookup("http://localhost:6060/AccountImpl/", Account.class);
// now, call the methods on your Web Service interface
System.out.println("Account #" + account.getAccountNumber() + " created.");
System.out.println("Putting $10 000 on account #" +
account.getAccountNumber() + " .");
account.deposit(10000);
System.out.println("Getting $7 000 from account #" +
account.getAccountNumber() + " .");
account.withdraw(7000);
System.out.println("Account #" + account.getAccountNumber() + " balance is "
+ account.getBalance());
account.close();
}
}
Despu�s de que el c�digo del cliente llame al servicio, se realiza la autentificaci�n m�tua. B�sicamente, se intercambia las credenciales p�blicas (certificados), y si la parte remota cree en el certificado del otro lado tiene lugar la comunicaci�n.
checkAuth realiza la autorizaci�n b�sica. Primero, se recuperan las credenciales del llamante de la llamada entrante. En nuestro ejemplo, se chequea el nombre del cliente, y si es igual a 'john', la autorizaci�n tiene �xito. De otro modo, la autorizaci�n falla. Dicha validaci�n dentro del c�digo es la m�s simple posible, pero a menos que todos los clientes de nuestro banco se llamen 'john', s�lo es viable para prop�sitos de demostraci�n. en el mundo real de Johns, Jacks y Janes, deber�amos utilizar las tecnolog�as como JAAS (Java Authentication and Authorization Service) para propagar la identidad del lado del llamante en el c�digo Java, y realizar chequeos de autorizaci�n (normalmente en un fichero de pol�tica). La aproximaci�n JAAS permite una mejor integraci�n de la seguridad de los Servicios Web con los Servidores de aplicaciones J2EE que ya usan esta tecnolog�a para prop�sitos de autentificaci�n y autorizaci�n.
Para la usar la integraci�n JAAS del API de Seguridad WASP, el interface Credentials tiene el m�todo getSubject() que obtiene el ejemplar de JASS javax.security.auth.Subject.
La privacidad es la �ltima caracter�stica (pero no la menos importante) de la arquitectura de seguridad de los Servicios Web. La privacidad de los datos asegura que los datos recibidos no se han modificado en el transporte, y tambi�n tiene cuidado de la confidencialidad de los datos. Normalmente, los datos se encriptan usando alg�n cifrado sim�trico (como Triple DES o RC5) porque son mucho m�s r�pidos que los asim�tricos. Generalmente, las cifrados asim�tricos s�lo se usan para un intercambio seguro de claves sim�tricas. Si miras los mensajes intercambiados en nuestro ejemplo, deber�as ver una comunicaci�n totalmente encriptada. En algunos casos, especialmente en escenarios de enrutados complejos de mensajes, tiene sentido encriptar s�lo las partes espec�ficas del mensaje para dejar que los intermediarios de la comunicaci�n accedan a las cabeceras. De forma similar, tambi�n se puede realizar la firma de datos, s�lo en los elementos de mensaje que lo requieran.
�Instrucciones para Ejecutar el Ejemplo
Descarga el archivo 
con el c�digo fuente y descomprimelo en el directorio c:\wasp_demo. Todo las clases del ejemplo residen en el paquete com.systinet.demos.bank y podr�s localizar todos los scripts en el subdirectorio bin.
PASOS ADICIONALES DE INSTALACI�N:
Necesitar�s instalar algunos a�adidos de seguridad para los ejemplos. Es absolutamente necesario que sigas los pasos de instalaci�n de JCE y JASS de la p�gina security installation document de WASP. Tambi�n puedes encontrar este documento en la gu�a de tu instalaci�n local de WASP en (doc/htmldata/installation_guide_body.html#security_install).
Tambi�n necesitar�s ejecutar el script install-security.bat situado en el subdirectorio bin de tu instalaci�n de WASP. Este script es interactivo. Por favor, especifica localhost como tu nombre de host y acepta todos los dem�s valores por defecto.
Finalmente, necesitas modificar el script env.bat situado en el directorio c:\wasp_demo\bin. Por favor, corrige los valores de las variables de entorno WASP_HOME y WASP_DEMO. Para hacer esto necesitar�s realizar las instalaci�n de seguridad de JCE, JAAS y WASP mencionadas arriba. Luego arranca el entorno de servicios web con el script serverstart del directorio WASP_HOME\bin. El siguiente paso es la generaci�n de todas las identidades usadas en la demo (habr�s observado que en el c�digo se utilizan las identidades bank-server y john). Estas identidades se generan en los almacenamientos seguros apropiados. Tambi�n, y como esta demo no usa ninguna autoridad de certificaci�n, ambas identidades se insertan en los almacenes creibles del otro lado de la comunicaci�n. Esta es la forma m�s simple de hacer que est�s entidades sean cre�das. Luego, se crea la identidad jack del lado del cliente. Esta identidad s�lo se crea en el lado del cliente, por lo que no es buena en el lado del servidor. Por favor, ejecuta el script createAccounts que crea autom�ticamente todas las identidades requeridas. Finalmente, podemos usar los scripts deploy y run para desplegar y ejecutar la demos. Observa que necesitar�s especificar un nombre de usuario y una password para el administrador de WASP, luego despliegua la demo en el entorno de ejecuci�n (nuestra demo usa los valores por defecto). La aplicaci�n cliente deber�a autentificar perfectamente al usuario john, pero deber�a fallar con el usuario jack.
NOTA:
Podr�as haber observado que el servicio web Account tiene estado: recuerda el n�mero de la cuenta y el estado del balance entre llamadas sucesivas. Si ejecutar�mos dos aplicaciones cliente en paralelo, se crear�an dos ejemplares separados de Account.
El �ltimo paso es eliminar la demo usando el script undeploy (de nuevo necesitar�s especificar el nombre y password del adminstrador de WASP.
NOTA:
En las siguientes p�ginas del tutorial no vamos a utilizar seguridad, por eso necesitamos poner el servidor WASP en modo no seguro ejecutando el script unsecure. Por favor, para el servidor WASP antes de hacer esto, de otro modo se perder�an los cambios hechos en los ficheros de configuraci�n.