Materia: Web Security.

Tema: Autenticación y Autorización con JAAS de Java.

Autenticación
La autenticación es garantizar que los usuarios realmente son quienes dicen ser es una gran parte de la seguridad informática.
Los modelos actuales de autenticación restringen el acceso a ciertos aspectos de un programa, permiten a los usuarios
conectarse a una red y regular los recursos disponibles para los usuarios de la red. Java utiliza el Servicio de Autenticación
y Autorización de Java (JAAS) para autenticar y autorizar a los usuarios. JAAS se basa en un plug-in, que permite que el
Kerberos y el inicio de sesión único se implanten para autenticación y autorización.

Kerberos
Kerberos es un protocolo de código abierto libremente disponible desarrollado en el MIT. Emplea la criptografía de clave
secreta para autenticar a los usuarios en una red y para mantener la integridad y privacidad de las comunicaciones de la red.
La autenticación en un sistema Kerberos es manejada por el sistema Kerberos principal y un servicio de concesión de tickets
secundario (TGS). El sistema Kerberos principal autentica la identidad de un cliente al TGS, que a su vez autentica los
derechos del cliente para acceder a servicios de red específicos.

Cada cliente de la red comparte una clave secreta con el sistema Kerberos. Esta clave secreta puede ser utilizada por
múltiples TGS en el sistema Kerberos. El cliente comienza introduciendo un nombre de inicio de sesión y una contraseña
en el servidor de autenticación Kerberos, que mantiene una base de datos de todos los clientes de la red. El servidor de
autenticación devuelve un Ticket-Granting Ticket (TGT) cifrado con la clave secreta del cliente que compartió con el
servidor de autenticación.

Dado que la clave secreta sólo es conocida por el servidor de autenticación y el cliente, sólo el cliente puede descifrar el
TGT, autenticando así la identidad del cliente. A continuación, el cliente envía el TGT descifrado al Servicio de concesión
de tickets para solicitar un ticket de servicio, que autoriza el acceso del cliente a servicios de red específicos. Los boletos
de servicio tienen un tiempo de caducidad establecido. Los boletos pueden ser renovados por la TGS.

Inicio de sesión único

Para acceder a múltiples aplicaciones en diferentes servidores, los usuarios deben proporcionar una contraseña separada
para la autenticación en cada uno. Es impráctico recordar las contraseñas múltiples.

Los sistemas de inicio de sesión único permiten a los usuarios iniciar sesión una vez con una sola contraseña. Los usuarios
pueden acceder a múltiples aplicaciones. Es importante asegurar las contraseñas de inicio de sesión único, ya que si la
contraseña está disponible para los hackers, se puede acceder a todas las aplicaciones y atacarlas.
Existen tres tipos de servicios de inicio de sesión único: scripts de inicio de sesión de estación de trabajo, scripts de servidor
de autenticación y tokens. Los scripts de inicio de sesión de la estación de trabajo son la forma más simple de inicio de
sesión único. Los usuarios inician sesión en sus estaciones de trabajo y luego eligen las aplicaciones de un menú. El script
de inicio de sesión de la estación de trabajo envía la contraseña del usuario a los servidores de aplicaciones y el usuario se
autentica para el acceso futuro a dichas aplicaciones. Los scripts de inicio de sesión de estación de trabajo no proporcionan
una cantidad suficiente de seguridad ya que las contraseñas de usuario se almacenan en la estación de trabajo en texto plano.
Cualquier persona que pueda acceder a la estación de trabajo puede obtener la contraseña del usuario. Los scripts de servidor
de autenticación autentican a los usuarios con un servidor central. El servidor central controla las conexiones entre el usuario
y las aplicaciones a las que el usuario desea acceder. Los scripts de servidor de autenticación son más seguros que los scripts
de inicio de sesión de la estación de trabajo porque las contraseñas se mantienen en el servidor, lo cual es más seguro que
el PC individual.

Los sistemas de inicio de sesión único más avanzados utilizan autenticación basada en tokens. Una vez que un usuario es
autenticado, un token no reutilizable se emite al usuario para acceder a aplicaciones específicas. El inicio de sesión para
crear el token está protegido con cifrado o con una sola contraseña, que es la única contraseña que el usuario necesita para
1
M. en C. Alejandro Cifuentes A.
recordar o cambiar. El único problema con la autenticación de token es que todas las aplicaciones deben construirse para
aceptar tokens en lugar de contraseñas de inicio de sesión tradicionales.

Java Authentication and Authorization Service (JAAS)

Java aborda los problemas frecuentemente asociados con la autenticación de usuarios y el control del acceso con la API
Java Authentication and Authorization Service (JAAS). Mientras que los archivos de políticas y permisos protegen a un
usuario de ejecutar programas maliciosos, JAAS protege las aplicaciones de usuarios no autorizados.

La arquitectura PAM (Pluggable Authentication Module) es el método estándar de autenticación en el que se basa JAAS.
El marco PAM admite múltiples sistemas de autenticación, incluidos los tickets Kerberos y las tarjetas inteligentes. Además,
PAM permite combinar diferentes sistemas para crear aún mayores niveles de seguridad. Los desarrolladores determinan
qué formas de autenticación se utilizarán en la política de seguridad asociada. PAM también admite sistemas de inicio de
sesión único. La implantación de Java de PAM en JAAS permite a los programas de Java identificar a los usuarios,
permitiendo a los desarrolladores establecer controles de acceso para proteger esos programas del acceso no autorizado.

Una vez que un usuario ha sido autenticado, JAAS puede otorgar o restringir el acceso a ciertos recursos de una aplicación.
JAAS puede controlar el acceso mediante políticas de seguridad basadas en grupos, usuarios o roles. El control de acceso
basado en el usuario controla el acceso a los recursos de forma individual. Después de proporcionar una contraseña, un
ticket Kerberos u otros medios de identificación a la aplicación Java, se determinan y aplican los privilegios del usuario
individual. La autorización basada en grupo identifica a un usuario como parte de un grupo y concede acceso a ciertos
recursos basados en el grupo identificador. El control de acceso basado en roles (RBAC) se utiliza además del control de
acceso de grupo, lo que permite un mayor control sobre los recursos. Los usuarios solicitan roles específicos, cada uno de
los cuales tiene los privilegios correspondientes, en función de las tareas que el usuario necesitará acceder. Los roles y los
permisos correspondientes se basan en la organización de la empresa. Lo que separa los roles de los grupos es el hecho de
que, por definición, los roles no están habilitados. Esta característica aumenta la seguridad permitiendo a los usuarios
acceder sólo a las aplicaciones necesarias.

La clase AuthenticateNT (en el código siguiente) utiliza un módulo de inicio de sesión de muestra de JAAS que
autentica al usuario actual con el sistema de autenticación de Windows. También se crea un nuevo LoginContext con
el nombre AuthenticateNT. Este LoginContext está asociado con un módulo de conexión específico en el archivo
de configuración. Luego, se invoca el método login de la clase LoginContext. Esto inicia el proceso de autenticación.
El módulo de inicio de sesión de ejemplo de Windows NT no solicita al usuario información de inicio de sesión,
simplemente obtiene las credenciales para el usuario que ha iniciado sesión actualmente. Otros módulos de acceso pueden
utilizar un CallbackHandler para pedirle al usuario que introduzca un nombre de usuario, una contraseña y otra
información de autenticación. Si el inicio de sesión es satisfactorio (es decir, el método de invocación de inicio de sesión
no genera excepciones), se imprime un mensaje que así lo indica.
// AuthenticateNT.java
// Se autentica un usuario utilizando el módulo NTLogin y ejecuta una WriteFileAction
PrivilegedAction.
import javax.swing.*;
import javax.security.auth.*;
import javax.security.auth.login.*;
public class AuthenticateNT {
public static void main( String[] args ){ //
try { // se autentica al usuario y ejecuta PrivilegedAction
// se crea LoginContext para el contexto de AuthenticateNT
LoginContext loginContext = new LoginContext( "AuthenticateNT" );
loginContext.login(); // el login
System.out.println( "Login Successful" ); // login sin errores.
Subject subject = loginContext.getSubject();//Subject de LoginContext
System.out.println( subject ); // display Subject details
Subject.doAs( subject, new WriteFileAction() ); // perform the
WriteFileAction as current Subject
2
M. en C. Alejandro Cifuentes A.
 loginContext.logout(); // sale del actual current Subject
System.exit( 0 );
}catch ( LoginException loginException ) { // exception del loggin
loginException.printStackTrace();
System.exit( -1 );
}
}
}

También, se obtiene un Subject desde el actual LoginContext. Un Subject representa un usuario particular u otra
entidad (por ejemplo, un servicio automatizado) que solicita una acción. Cada Subject tiene Principal asociados.
Estos Principal representan los diferentes roles o identidades que un usuario puede asumir durante una sesión de inicio
de sesión determinada. Las restricciones de seguridad establecidas para una aplicación en particular pueden conceder
permisos para que los Principal realicen ciertas solicitudes (por ejemplo, leer un archivo determinado). Allí se imprime
la información del Subject, incluyendo una lista de los Principal del Subject.

Se invoca al método doAs de la clase Subject para realizar una petición utilizando el Subject dado. El método doAs
toma como argumentos el Subject para la solicitud y una PrivilegedAction que contiene la solicitud. En este caso,
se pasa un nuevo WriteFileAction, que escribe un mensaje simple en un archivo de texto. Enseguida, se desconecta
del LoginContext actual.

La clase WriteFileAction implanta la interfaz Privileged-Action. Los PrivilegedActions se ejecutan en

el contexto de un AccessController, que verifica que el Subject que invoca PrivilegedAction tiene los
permisos adecuados. La interfaz PrivilegedAction requiere que las implantaciones definan el método run(). El
método run de la clase WriteFileAction crea un archivo de texto y escribe un mensaje en ese archivo de texto.
// WriteFileAction.java
// WriteFileAction es implantación de PrivilegedAction que sólo guarda un archivo en el
sistema local.
import java.io.*;
import java.security.PrivilegedAction;
public class WriteFileAction implements PrivilegedAction {
public Object run(){ // PrivilegedAction intenta escribir mensaje al archivo.
try {
File file = new File( "D:/", "privilegedFile.txt" );
FileWriter fileWriter = new FileWriter( file );
fileWriter.write( "Welcome to JAAS!" ); // escribe mensaje al archivo.
fileWriter.close();
}catch ( IOException ioException ) {// exception de escritura en el archivo.
ioException.printStackTrace();
}
return null;
}
}

El archivo de configuración especifica los LoginModules que se utilizarán para AuthenticateNT LoginContext.
También se especifica que el Subject debe autenticarse con el NTLoginModule para un inicio de sesión correcto. Los
LoginContexts pueden requerir una secuencia de varios LoginModules para una autenticación apropiada.

El archivo de políticas otorga permisos al Principal especificado cuando se ejecuta código en el codeBase
especificado. JAAS ofrece un control fino de permisos. Este ejemplo concede leer y escribir FilePermission al
Principal "santry" al ejecutar el código en el codebase file:d JavaProjects/miProyect/src/-.

3
M. en C. Alejandro Cifuentes A.
El archivo de políticas especifica los permisos para JAAS y para el codeBase de la clase AuthenticateNT. Enseguida,
las líneas otorgan AllPermission a la extensión estándar JAAS. Este permiso habilita a JAAS para realizar la autenticación
en beneficio de esta aplicación. Luego se otorga permiso para ejecutar PrivilegedActions utilizando el método doAs
y se otorga permiso para leer y escribir el archivo de texto D:\privileged-File.txt.
// jaas.config
// Se configura JAAS para utilizar NTLoginModule en la autenticación.
AuthenticateNT {
com.sun.security.auth.module.NTLoginModule required debug=false;
};

// jaas.policy
// Archivo de política Policy que define los permisos para Principal
grant codeBase "file:D:/JavaProjects/advjhtp1/src/-",
Principal com.sun.security.auth.NTUserPrincipal "santry" {
permission java.io.FilePermission "D:/privilegedFile.txt", "write";
permission java.io.FilePermission "D:/privilegedFile.txt","read";
};

// java.policy
// Archivo Policy que garantiza AllPermission a módulos JAAS y permisos específicos a
D:\Projects\Java codebase.
grant codebase "file:/D:/jdk1.3.1/jre/lib/ext/jaas.jar" {
permission java.security.AllPermission;
};
grant codebase "file:/D:/JavaProjects/advjhtp1/src/-" {
permission javax.security.auth.AuthPermission "createLoginContext";
permission javax.security.auth.AuthPermission "doAs";
permission java.io.FilePermission "D:/privilegedFile.txt", "write";
permission java.io.FilePermission "D:/privilegedFile.txt", "read";
};

Ejecutar el ejemplo AuthenticateNT requiere varias opciones de línea de comandos para la máquina virtual Java.
Escribir lo siguiente en una ventana de consola:
java -Djava.security.policy==java.policy
-Djava.security.auth.policy==jaas.policy
-Djava.security.auth.login.config==jaas.config
com.misPaquetes.security.jaas.AuthenticateNT

Donde java.policy es el archivo de políticas, jaas.policy es el archivo de políticas y jaas.config es el archivo de

configuración.

NOTA: Desarrollar el reporte completo que incluya imágenes y los detalles explícitos de cada paso del ejercicio.

4
M. en C. Alejandro Cifuentes A.