|
Requerimientos de Software:
Cuando se usen los ejemplos SASL, necesitaremos los ficheros ldapbp.jar y jaas.jar adem�s de los requerimientos de software listados en la lecci�n Preparaciones. Estos pueden descargarse como parte del proveedor de servicio LDAP desde la JNDI Web site. |
El protocolo LDAP v3 usa SASL para soportar autentificaci�n enchufable. Esto significa que el cliente LDAP y el servidor pueden configurarse para negociar y usar posibles mecanismos no est�ndar y/o personalizados para la autentificaci�n, dependiendo del nivel de protecci�n deseada por el cliente y el servidor. El protocolo LDAP v2 no soporta SASL.
Actualmente se han definido varios mecanismos SASL:
- An�nimo (RFC 2245)
- CRAM-MD5 (RFC 2195)
- Digest-MD5 (RFC 2831)
- External (RFC 2222)
- Mecanismos GSSAPI (RFC 2222)
- Kerberos V4 (RFC 2222)
- Kerberos V5
- SecurID (RFC 2808)
- Secure Remote Password (draft-burdis-cat-srp-sasl-03.txt)
- S/Key (RFC 2222)
- X.509 (draft-ietf-ldapext-x509-sasl-03.txt)
�Mecanismos SASL Soportados por los Servidores LDAP
De los mecanismos de la lista anterior, los servidores LDAP m�s populares (como aquellos de Netscape y Innosoft) actualmente soportan CRAM-MD5 y External. (La RFC 2829) propone el uso de DIGEST-MD5 como mecanismo obligatorio por defecto para servidores LDAP v3.
Aqu� tenemos un sencillo programa para encontrar la lista de mecanismos SASL que soporta un servidor LDAP:
// Create initial context
DirContext ctx = new InitialDirContext();
// Read supportedSASLMechanisms from root DSE
Attributes attrs = ctx.getAttributes(
"ldap://localhost:389", new String[]{"supportedSASLMechanisms"});
Aqu� podemos ver la salida producida por la ejecuci�n de este programa en un servidor que soporta mecanismo SASL externo.
{supportedsaslmechanisms=supportedSASLMechanisms: EXTERNAL}
�Especificar el Mecanismo de Autentificaci�n
Para usar un mecanismo SASL particular, especificamos su "Internet Assigned Numbers Authority" (IANA)-nombre de mecanismo registrado en la propiedad de entorno Context.SECURITY_AUTHENTICATION. Tambi�n podemos especificar una lista de mecanismos para que pruebe el proveedor LDAP. Esto se hace especificando una lista ordenada y separada por espacios con los nombres de los mecanismos. El proveedor LDAP usar� el primer mecanismo para el que encuentre una implementaci�n.
Aqu� hay un ejemplo que le pide al proveedor LDAP que intente obtener una implementaci�n del mecanismo DIGEST-MD5, y si no est� disponible use una para CRAM-MD5.
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5 CRAM-MD5");
Podr�amos obtener esta lista de mecanismos de autentificaci�n del usuario de nuestra aplicaci�n. O podr�amos obtenerla pregunt�ndole al servidor LDAP. mediante una llamada similar a la mostrada anteriormente. El propio proveedor LDAP no consulta al servidor sobre esta informaci�n. Simplemente intenta localizar y usar la implementaci�n de los mecanismos especificados.
El provedor LDAP de Sun tiene soporte interno para los mecanismos SASL CRAM-MD5 y External; podemos a�adir soporte adicional para otros mecanismos. Puedes ver la secci�n Usar Mecanismos SASL arbitrarios.
�Especificar el Nombre Distinguido de "Bind"
La autentifiaci�n SASL consiste en un intercambio de mensajes SASL embebidos entre el cliente y el servidor dentro de solicitudes y respuestas "bind". La solicitud "bind" contiene un campo nombre, que es el DN (nombre Distinguido) del objeto directorio con el que el cliente desea autentificarse. El valor de este campo podr�a ser null (es decir, no especificado) dependiendo del mecanismo SASL (que podr�a embeber el DN dentro de las credenciales que intercambia con el servidor).
El valor de la propiedad de entorno Context.SECURITY_PRINCIPAL se usa como el DN del "bind".
�Especificar Entrada para el Mecanismo de Autentificaci�n
Algunos mecanismos, como External, no requieren ninguna entrada adicional, s�lo el nombre del mecanismo es suficiente para proceder a la autentificaci�n. La p�gina Ejemplo External muestra c�mo usar el mecanismo SASL External.
La mayor�a de los otros mecanismos necesitan alguna entrada adicional. Dependiendo del mecanismo, el tipo de entrada podr�a variar. Abajo podemos ver algunas entradas requeridas por los mecanismos:
- Authentication id. La identidad de la entidad que realiza la autentificaci�n.
- Authorization id. La identidad de la entidad para la que deber�an chequearse los accesos si la autentificaci�n tiene �xito.
- Authentication credentials. Por ejemplo, un password o una clave.
Las identidades de autentificaci�n y de autorizaci�n podr�an ser diferentes si el programa (como un servidor proxy) se est� autentificando desde detr�s de otra entidad. La identidad de autentifiaci�n se especifica usando la propiedad de entorno Context.SECURITY_PRINCIPAL. Su tipo es java.lang.String.
La password/clave de la identidad de autentificaci�n se especifica usando la propiedad de entorno Context.SECURITY_CREDENTIALS . Su tipo es java.lang.String, array de char (char[]), o array de byte (byte[]). Si la password es un array de byte, se transforma en un array de char usando codificaci�n UTF-8.
Por defecto, tambi�n se usa el valor de la propiedad de entorno Context.SECURITY_PRINCIPAL, adem�s de la identidad de autentificaci�n como identidad de autorizaci�n. Si necesitamos especificar una identidad de autorizaci�n que sea diferente de la identidad de autentificaci�n, entonces se usa la propiedad de entorno "java.naming.security.sasl.authorizationId". Su valor debe ser del tipo java.lang.String.
El ejemplo CRAM-MD5 muestra c�mo usar las propiedades Context.SECURITY_PRINCIPAL y Context.SECURITY_CREDENTIALS para autentificaci�n CRAM-MD5.
Si un mecanismo requiere una entrada distinta a las ya descritas, entonces necesitamos definir un objeto callback para el mecanismo a usar. Puedes ver un ejemplo de c�mo hacer esto en la p�gina Retrollamadas.