Estado Del Arte Autenticacion y Autorizacion - v2.3

UNIVERSIDAD DE LA REPÚBLICA | FACULTAD DE INGENIERÍA | INSTITUTO DE COMPUTACIÓN
Proyecto de Grado
Edición 2008
Federación de Servicios en
Ambiente Heterogéneo
Estado del arte de los mecanismos de

autenticación en las plataformas Java y
.NET
Damián Konkolowicz CI: 4.333.040-8

Andrés Pereyra CI: 3.776.934-4
Docente Tutor: Laura González, Felipe Zipitria
Proyecto de Grado 2008 Página 1 de 38

Historia de revisiones
Fecha Versi Descripción Autor

ón
12/04/2008 1.0 Versión Inicial Andrés Pereyra,
Damián Konkolowicz
21/04/2008 1.1 Se completo Andrés Pereyra,
sección Damián Konkolowicz
“Herramientas
actuales”
13/05/2008 2.0 Nuevas secciones, Andrés Pereyra,
corrección de Damián Konkolowicz
errores.
25/05/2008 2.1 Se agrego la Andrés Pereyra,
sección “Resumen Damián Konkolowicz
del Trabajo” y
“Palabras clave”
19/06/2008 2.2 Corrección de Andrés Pereyra,
errores y revisión Damián Konkolowicz
general.
09/08/2008 2.3 Cambios debido a Andrés Pereyra,
creación de Damián Konkolowicz
glosario.

Contenido
RESUMEN DEL TRABAJO.....................................................................5
PALABRAS CLAVE............................................................................6
1 INTRODUCCIÓN.............................................................................7
2 MECANISMOS DE SEGURIDAD.............................................................8
2.1 Autenticación Web.....................................................................................8
2.1.1 HTTP Basic authentication...............................................................................8
2.1.2 HTTPS Client authentication (Certificados).......................................................9
2.1.3 HTTP FORM-based authentication....................................................................9
2.1.4 Mutual Authentication....................................................................................10
2.1.5 HTTP Digest authentication............................................................................11
2.1.6 Autenticación con SSL....................................................................................12
2.2 Java (J2EE)................................................................................................13
2.2.1 Realms, usuarios, grupos y roles....................................................................13
2.2.2 Autenticación Web.........................................................................................14
2.2.3 Java Authentication and Authorization Service (JAAS)....................................14
2.2.3.1 Autenticación con JAAS ...........................................................................15
2.2.3.2 Autorización con JAAS..............................................................................15
2.2.3.3 Transporte con JSSE.................................................................................16
2.2.3.4 Seguridad en Web Services.....................................................................16
2.3 Microsoft (.NET)........................................................................................17
2.3.1 Active Directory (Sistema Operativo).............................................................17
2.3.1.1 Usuarios...................................................................................................17
2.3.1.2 Security Principals....................................................................................17
2.3.1.3 Grupos.....................................................................................................18
2.3.2 Kerberos........................................................................................................18
2.3.3 Estructura de seguridad .NET.........................................................................19
2.3.4 Autenticación de IIS.......................................................................................19
2.3.4.1 Anónimo...................................................................................................20
2.3.4.2 Basic........................................................................................................20
2.3.4.3 Digest......................................................................................................20
2.3.4.4 Autenticación de Windows.......................................................................21
2.3.4.5 Certificado del cliente .............................................................................21
2.3.5 Autenticación de ASP.NET..............................................................................21
2.3.5.1 Windows (autenticación por defecto).......................................................22
2.3.5.2 Forms.......................................................................................................22
2.3.5.3 Live ID......................................................................................................23
2.3.5.4 Predeterminada.......................................................................................23
2.3.6 Autorización de ASP.NET................................................................................24
2.4 Conclusión................................................................................................26
3 HERRAMIENTAS ACTUALES...............................................................28
3.1 Java..........................................................................................................28
3.1.1 JOSSO.............................................................................................................28
3.1.2 OPENSSO.......................................................................................................30
3.1.3 CAS................................................................................................................30
3.2 Microsoft..................................................................................................32
3.2.1 Active Directory.............................................................................................32
3.2.2 ASP.NET.........................................................................................................32
3.2.3 .NET Framework.............................................................................................33
3.2.4 IIS...................................................................................................................34
4 GLOSARIO...............................................................................36

5 REFERENCIAS............................................................................36
5.1 Herramientas...........................................................................................37
5.2 Imagenes.................................................................................................38

Resumen del trabajo

Autenticación y autorización son los principales conceptos de la
seguridad de los sistemas. Los temas a desarrollar a lo largo de este
trabajo trataran estos conceptos a través de la exploración de los
mecanismos de seguridad y las herramientas que los implementan.
Las plataformas en las cuales se basa este estudio son Microsoft y Java.
Java expone la seguridad en la plataforma J2EE por medio de conceptos
tales como realms, usuario, grupos y roles.
Para las aplicaciones Web se pueden encontrar otros medios de
autenticación a nivel del protocolo HTTP que van desde el HTTP Basic
authentication el cual no ofrece garantías en cuanto a confidencialidad
de los datos ingresados hasta ejemplos tales como HTTP Digest
authentication con su cifrado de datos y el SSL para agregar seguridad
al canal por el cual se enviarán los datos.
Dada la necesidad de mejores mecanismos de seguridad Java diseño

una API que lograra resolver las deficiencias existentes cuyo nombre es
JAAS.
JAAS es un mecanismo flexible sobre una arquitectura PAM, esto
proporciona la capacidad de integrar una amplia gama de tecnologías de
autenticación. La autorización se resuelve mediante el Java 2 Security
Manager, los permisos son asociados mediante políticas.
Para la seguridad en el tránsito de los datos Java dispone de JSSE, este
permite asegurar las comunicaciones por medio de SSL/TLS.
Por ultimo la seguridad en Web Services por medio de SOAP se utiliza

XML Encryption así como Firmas Digitales.
Por otro lado tenemos a Microsoft, la seguridad en esta plataforma es

implementada mediante el Active Directory, el cual utiliza los conceptos
de usuarios, security principals y grupos. Active Directory se apoya en
herramientas como Kerberos para la implementación de mecanismos
como por el ejemplo el llamado “Single Sign-On”.
Para la seguridad Web la estructura de seguridad esta definida por la

plataforma (framework) .NET y el servicio de Windows IIS. Dentro de los
esquemas de autenticación manejados por el IIS se encuentra la
autenticación integrada de Windows, la misma puede utilizar sistemas
como NTLM o Kerberos V5.
Luego del IIS se encuentra el ASP.NET, parte de la plataforma .NET
utilizada para el desarrollo de aplicaciones Web. ASP.NET basa su

infraestructura de autenticación en la seguridad brindada por el IIS y

Windows, luego se encarga de la autorización por medio de archivos de
configuración como ser el machine.config o configuraciones a nivel de
aplicación por medio del llamado web.config.
Dentro de los controles implementados se pueden encontrar los .NET
Objetos Principales, Listas de Control de Acceso, entre otros.
Para finalizar, este trabajo cuenta con una breve conclusión acerca de
las ideas que se desprenden del estudio de ambas plataformas.
Palabras clave
Autorización, Autenticación, .NET, JAAS, J2EE, IIS, SSO

1 Introducción
El objetivo principal de este documento es analizar los mecanismos de
autenticación y autorización utilizados por las plataformas Java y .NET
Para ello se analizarán las soluciones existentes y los mecanismos de
seguridad de ambas plataformas.
En la sección “Mecanismos de Seguridad” se trataran los mecanismos

implementados por las plataformas Java y .NET .
En la sección “Herramientas actuales” se describirán de forma breve
algunas de las herramientas que implementan los mecanismos de
seguridad expuestos en la sección anterior.
Por último en la sección “Referencias” se encuentran todas las reseñas a
la información utilizada en este documento así como a las imágenes
manejadas en el mismo.

2 Mecanismos de Seguridad
Hoy en día es importante para las empresas que se cumplan las metas
de la seguridad para el desarrollo y despliegue de código. Para las
plataformas y ambientes en tiempo de ejecución se deben proporcionar
mecanismos para el correcto manejo (autenticación, autorización,
integridad, confidencialidad, etc.) de los datos.
La responsabilidad de estas tareas se propaga a través de múltiples
elementos en una plataforma de n niveles típicos en la arquitectura de
las aplicaciones. En esta sección se tratarán los mecanismos de
seguridad adoptados por Microsoft (.Net) y Java (J2EE) centrándose
principalmente en un ambiente Web.
2.1 Autenticación Web

Los siguientes métodos de autenticación Web son independientes de la
plataforma utilizada para la seguridad.
2.1.1 HTTP Basic authentication
Los pasos a seguir con la autenticación básica son los siguientes:

1 – Un usuario solicita el acceso a cierta información
2 – El servidor envía una petición de usuario y contraseña en un
formulario
3 – El usuario ingresa y envía la información solicitada
4 – El servidor autentica y valida la información recibida y en caso
de ser válida devuelve la información solicitada.
En la Figura 1 se muestra un esquema de los pasos mencionados

anteriormente.
Figura 1 – Esquema Básic Authentication

HTTP Basic Authentication no es especialmente segura. Este

mecanismo envía nombres de usuario y contraseñas a través de Internet
como texto que es uu-encoded (Unix-to-Unix encoded), pero no
encriptada. Esta forma de autenticación, que utiliza la codificación
Base64, puede exponer los nombres de usuario y contraseñas a menos
que todas las conexiones sean a través de SSL. Si alguien puede
interceptar la transmisión, el nombre de usuario y contraseña pueden
ser fácilmente descifrados. Basic Authentication se definió originalmente
en la RFC 1945 (Hypertext Transfer Protocol – HTTP/1.0), aunque más
información sobre este método puede encontrarse en el RFC 2616
(Protocolo de transferencia de hipertexto - HTTP/1.1) y RFC 2617 (HTTP
Autenticación: Básica y Digest De autenticación de acceso).
2.1.2 HTTPS Client authentication (Certificados)
La autenticación de certificados de cliente es un método más seguro que

los de autenticación básica o autenticación basada en formularios. El
mismo utiliza HTTP sobre SSL, en la que el servidor y, opcionalmente, el
cliente se autentican mutuamente mediante certificados de clave
pública. Secure Socket Layer (SSL) proporciona cifrado de datos,
servidor de autenticación, integridad de mensajes y autenticación de
cliente opcional para una conexión TCP / IP. El certificado es emitido por
una organización de confianza, lo que se llama una autoridad de
certificación (CA), y proporciona la identificación de su portador.
Si se especifica la autenticación de certificados de cliente, el servidor

Web autenticará al cliente utilizando el certificado X.509 del mismo, un
certificado de clave pública que se ajusta a un estándar que se define
por X.509 de la infraestructura de clave pública (PKI).
2.1.3 HTTP FORM-based authentication
La autenticación basada en formularios consiste en diseñar en el

servidor una página de autenticación (Login) y una página de error. Los
pasos que son utilizados para la autenticación de un usuario que solicita
una determinada información se muestran en la Figura 2.

Figura 2 – Esquema Form-based Authentication
El usuario solicita acceso a información y en el caso de que el mismo no

se encuentre autenticado el servidor lo redireccionará a la página de
autenticación (Login). Luego de que el usuario ingrese su usuario y
contraseña y envíe la solicitud, el servidor autenticará los datos
recibidos. En el caso de que la información sea válida se mostrará la
información solicitada, en caso contrario se direccionará a una página de
error.
2.1.4 Mutual Authentication
Usando este mecanismo de autenticación el cliente y el servidor se

autentican mutuamente. Existen 2 formas de autenticación mutua:
• Certificate-based mutual authentication
• User name and password-based mutual authentication
Figura 3 – Esquema 1 Mutual Authentication

En la Figura 3 se muestran los pasos que son realizados para la
autenticación mediante certificados.

Los pasos que son dados por el servidor y el cliente son los siguientes:
1. Un cliente solicita el acceso a un recurso protegido.
2. El servidor Web presenta su certificado al cliente.
3. El cliente comprueba el certificado del servidor.
4. Si tiene éxito, el cliente envía su certificado al servidor.
5. El servidor comprueba las credenciales del cliente.
6. Si tiene éxito, el servidor permite el acceso a los recursos
solicitados por el cliente.
La otra manera de utilizar la autenticación mutua se muestra en los

siguientes pasos:
1. Un cliente solicita el acceso a un recurso protegido.
2. El servidor Web presenta su certificado al cliente.
3. El cliente comprueba el certificado del servidor.
4. Si tiene éxito, el cliente envía su nombre de usuario y la
contraseña al servidor, el cual verifica las credenciales del
cliente.
5. Si la verificación es positiva, el servidor permite el acceso a
los recursos solicitados por el cliente.
Figura 4 – Esquema 2 Mutual Authentication
2.1.5 HTTP Digest authentication

Al igual que la autenticación básica HTTP, HTTP Digest authentication

realiza la autenticación de un usuario sobre la base de un nombre de
usuario y una contraseña. Sin embargo, la autenticación se realiza
mediante la transmisión de la contraseña encriptada, de forma que es
mucho más segura que la simple codificación mediante base64 la cual
es utilizada por Basic.
La ventaja de este método es que la contraseña sin formato está

protegida en la transmisión, y la misma no puede ser determinada a
partir de la recopilación que se presenta por el cliente al servidor.
La contraseña de autenticación apoya el concepto de digerir

contraseñas de los usuarios. Esto hace que las versiones almacenadas
de las contraseñas se codifiquen en una forma que no es fácilmente
reversible, pero que el servidor Web puede utilizar para la autenticación.
Desde una perspectiva de usuario, Digest Authentication es casi idéntica
a Basic, en la que se dispara un cuadro de diálogo de autenticación
(Login). La diferencia entre la autenticación básica y Digest es que en la
conexión de red entre el navegador y el servidor, la contraseña está
encriptada, incluso en una conexión que no sea SSL. En el servidor, la
contraseña puede ser almacenada en texto plano o texto encriptado.
2.1.6 Autenticación con SSL
Las contraseñas no están protegidas por la confidencialidad con HTTP

básica o la autenticación basada en formularios, lo que significa que las
contraseñas enviadas entre un cliente y un servidor en una sesión sin
protección pueden ser vistas e interceptadas por terceros. Para superar
esta limitación, se puede ejecutar estos protocolos de autenticación
sobre SSL y garantizar que todos los contenidos de los mensajes están
protegidos por la confidencialidad.
La tecnología SSL (Secure Socket Layer) permite que los navegadores

Web y servidores Web puedan comunicarse a través de una conexión
segura. En esta conexión segura, los datos que se están enviando son
encriptados antes de ser enviados y luego son decodificados al ser
recepcionados y antes de que los mismos sean procesados. Tanto el
navegador y el servidor cifran todo el tráfico antes de enviar los datos.
SSL contiene las siguientes consideraciones de seguridad:

• Autenticación
• Confidencialidad
• Integridad
Para instalar y configurar el soporte SSL en un servidor web, se

necesitan los siguientes componentes.
- Un certificado de servidor de almacén de claves.
- Un conector HTTPS.
2.2 Java (J2EE)
2.2.1 Realms, usuarios, grupos y roles

Para J2EE un usuario es similar a un usuario del sistema operativo.
Normalmente, ambos tipos de usuarios representan a las personas. Sin
embargo, estos dos tipos de usuarios no son los mismos. La
autenticación del servidor J2EE no tiene conocimiento del nombre de
usuario y la contraseña que el usuario proporciona cuando entra al
sistema operativo. La autenticación del servidor J2EE no está conectada
al mecanismo de seguridad del sistema operativo. Los dos servicios de
seguridad gestionan usuarios que pertenecen a diferentes realms.
El servidor J2EE de autenticación incluye e interactúa con los siguientes

componentes:
• Realm: Una colección de usuarios y grupos que están controladas

por la misma política de autenticación.
• Usuario: Una persona (o programa de aplicación) que se ha
definido en el servidor de aplicaciones. Los usuarios pueden estar
asociados con un grupo.
• Grupo: Un conjunto de usuarios autenticados, clasificados por los
rasgos comunes, definidos en el Application Server.
• Rol: Un nombre abstracto para el permiso a acceder a un conjunto
particular de recursos en una aplicación. Una función puede
compararse a una llave que puede abrir un candado. Muchas
personas podrían tener una copia de la clave. El bloqueo no esta
basado en cual sea el usuario, solo que el mismo tenga la clave
correcta.

2.2.2 Autenticación Web
Los mecanismos de seguridad utilizados para aplicaciones Web por la

plataforma J2EE son los que se muestran a continuación.
• HTTP Basic authentication

• HTTPS Client authentication (Certificados)
• HTTP FORM-based authentication
• Mutual Authentication
• HTTP Digest authentication
• SSL
2.2.3 Java Authentication and Authorization Service

(JAAS)
La Autenticación y Autorización de Java Service (JAAS) fue diseñada para

mejorar la infraestructura necesaria para la autenticación y autorización.
JAAS es una API que permite a las plataformas Java acceder a los
servicios de autenticación y acceso.
Proporciona un mecanismo flexible para la autenticación de usuarios y

verificación de su capacidad para garantizar el acceso de recursos. JSSE
(Java Secure Socket Extensión) define un mecanismo de Java para
asegurar el tráfico por la Web sobre un Secure Socket Layer (SSL).
Mediante la combinación de estas dos tecnologías, se puede ofrecer a
las aplicaciones la capacidad de:
• Verificar que el usuario es quien dice ser (autenticación)

• Asegurarse de que el usuario tenga permisos sobre los recursos
solicitados (autorización)
• Manejar el intercambio sobre una red segura (transporte)
Tradicionalmente los sistemas operativos (como UNIX) realizan la

autenticación en un principal o entidad a través de algún tipo de
mecanismo de challenge-response. Un usuario y contraseña es la
combinación más importante de estos. Esta técnica se utiliza también
para proteger los recursos Web utilizando el esquema de autenticación
básica HTTP. El reto, sin embargo, puede ser más complejo: por ejemplo,
la información puede ser codificada o depender de la posesión de
información específica, como el nombre de soltera de la madre o de una
respuesta a una pregunta seleccionada por el usuario. La respuesta
entonces debe ser válida basada en el tipo de desafío.

Para más información sobre el modelo de seguridad implementado por

JAAS ver la sección referencias.
2.2.3.1 Autenticación con JAAS
JAAS está construido sobre una arquitectura de seguridad conocida

como PAM (Pluggable Authentication Module). La arquitectura de PAM es
modular, lo que significa que está diseñado para apoyar el intercambio
de un componente de un protocolo de seguridad por otro. El mismo
cuenta con interfaces bien definidas en el marco de permitir la inclusión
de tecnologías de autenticación y de múltiples mecanismos de
autenticación, sin cambiar o interferir con cualquiera de los servicios de
acceso existentes. La arquitectura PAM, como así JASS, es capaz de
integrar una amplia gama de tecnologías de autenticación, incluyendo
RSA, DCE, Kerberos, y S/Key.
El esquema de autenticación utilizado por JAAS se basa en dos

importantes entidades: principals y subjects. La persona o el servicio
que actualmente es autenticado se denomina subject. Un principal es
una entidad única, como el nombre de una persona o grupo, un número
de cuenta, un número de seguro social, o similares identificador único.
Con el fin de identificar de forma exclusiva un subject (que es un
componente crucial de la autenticación), uno o más principals pueden
estar asociados a un subject. Por último, un subject puede poseer
atributos relacionados con la seguridad, los cuales son conocidos como
credenciales. Una credencial puede ser cualquier cosa desde una simple
contraseña hasta una compleja clave criptográfica.
2.2.3.2 Autorización con JAAS
Una vez que la identidad del usuario se ha confirmado, se deben

examinar sus derechos de acceso. Una vez que sus derechos han sido
confirmados, el usuario puede acceder a los recursos solicitados del
sistema.
En otras palabras, una vez que el usuario o el servicio ha sido

autentificado, se crea un objeto, el cual es utilizado para representar a la
entidad autenticada. Este objeto se transmite luego por JAAS a cualquier
componente de autorización que se haya establecido para proteger el
acceso a sistemas sensibles o de recursos.
Para determinar la autorización, se suministra al Java 2 Security

Manager con el objeto de la entidad y sus principals, así como los
privilegios con los que el mismo cuenta (lectura / escritura al sistema de

ficheros, acceso a bases de datos, etc.). El Security Manager consulta a

un archivo de políticas, que asocian a los principals y los permisos. Si el
objeto asociado al principal tiene derechos para realizar una acción
específica, entonces el usuario o servicio podrá realizar la acción
solicitada; en otro caso el acceso será denegado y se lanza una
excepción de seguridad.
2.2.3.3 Transporte con JSSE
Por medio de JAAS se tiene la capacidad de identificar a los usuarios que

acceden al sistema y restringir su acceso a las partes del sistema que
están autorizados a utilizar. Mientras que JAAS es un buen comienzo
para alcanzar una aplicación Web segura, la aplicación de seguridad no
está completa sin seguridad en el transporte de la información.
En este punto, todavía se transmite información segura (incluyendo la
información de autenticación), en formato de texto plano, es decir,
HTTP, TCP / IP, FTP, etc. Así que se debe asegurar, que en tránsito, los
datos no son accesibles a terceros no autorizados. También se debe
estar seguro que, en la llegada, los datos no han sido modificados
durante el tránsito, ya sea intencionalmente o no. Para ambas de estas
funciones podemos utilizar los protocolos Secure Sockets Layer (SSL)
(explicado anteriormente) y Transport Layer Security (TLS).
SSL y TLS no son protocolos específicos de Java, sino más bien de la

capa de red diseñados para mantener la integridad y la privacidad de
tráfico a través de un socket. Java Secure Socket Extension (JSSE)
permite asegurar las comunicaciones por Internet con SSL / TLS. En él se
ofrece un framework (una versión Java de los protocolos SSL y TLS)
completo con toda la gama de funcionalidad incluyendo, cifrado de
datos, servidor de autenticación, integridad de mensajes, y más. Usando
JSSE, podemos definir secure socket connections entre un cliente y
servidor corriendo cualquier protocolo de aplicación, incluidos HTTP,
TCP / IP, FTP, o incluso Telnet. Desde un punto de vista de cifrado de
datos, JSSE abarca muchos de los mismos conceptos y algoritmos como
los de la JCE (Java Cryptography Extension). A pesar de que es más
importante, se aplica de manera automática según sea necesario bajo
un simple stream socket API.
2.2.3.4 Seguridad en Web Services
La seguridad puede ser aplicada a los Web Services, tanto en el nivel del
transporte como en el nivel de los mensajes.

En el caso de la seguridad en el mensaje, la seguridad de la

información viaja a lo largo de la Web con los mensajes del Web service.
WSS en la capa SOAP es el uso de XML Encryption y las Firmas Digitales
para garantizar mensajes SOAP. WSS utiliza varios tokens de seguridad
incluidos certificados X.509, SAML assertions, y nombre de usuario /
contraseña para lograrlo.
La seguridad en la capa del mensaje difiere de la de la capa de

transporte, en que la capa del mensaje puede ser utilizada para
desacoplar la protección del mensaje del mensaje en si, de manera que
los mensajes sigan estando protegidos aun después de la transmisión
del mismo.
2.3 Microsoft (.NET)
2.3.1 Active Directory (Sistema Operativo)
El sistema operativo utiliza un usuario o cuenta para autenticar la

identidad del usuario o del computador y autorizar o denegar el acceso a
recursos del dominio.
2.3.1.1 Usuarios
Un usuario requiere una cuenta en el Active Directory para acceder a un

computador de un dominio. La cuenta establece una identidad para el
usuario, el sistema operativo utiliza esta identidad para autenticar el
usuario y para la concesión de la autorización para acceder a recursos
específicos del dominio.
Las cuentas de usuario también se pueden utilizar como cuentas de

servicio para algunas aplicaciones. Es decir, un servicio puede ser
configurado para acceder (autenticar) como una cuenta de usuario, y
entonces se concede el acceso a determinados recursos de la red a
través de esa cuenta de usuario.
2.3.1.2 Security Principals

Los usuarios del Active Directory (así como los grupos, incluidos más
adelante) se conocen como los security principals, un término que hace
hincapié en la seguridad que el sistema operativo lleva a cabo para
estas entidades. Los Security Principals son objetos de directorio que se
le asignan SID's(Security Identifier) automáticamente cuando se crean.

Objetos con SID pueden conectarse a la red y pueden acceder a

recursos del dominio.
2.3.1.3 Grupos
Los grupos de Active Directory son objetos que pueden contener
usuarios, contactos, computadoras y otros grupos. En Windows, los
grupos se crean en dominios, utilizando los usuarios y herramientas del
Active Directory. Se pueden crear grupos en el dominio raíz, en
cualquier otro dominio, en cualquier unidad de la organización, o en
cualquier clase de objetos contenedores. Como los usuarios y las
cuentas, los grupos de Windows son los security principals, que son
objetos de directorio para los que se asignan SID's en el momento de su
creación.
2.3.2 Kerberos
Kerberos, desarrollado originalmente por el MIT's Project Athena, ha

crecido hasta convertirse en la más ampliamente implementado sistema
de autenticación y autorización en las redes de computadoras
modernas. Kerberos actualmente se suministra con todos los principales
sistemas operativos de computadoras y está en una posición única para
convertirse en una solución universal para la autenticación distribuida y
el problema de permitir la autorización universal "Single Sign-On" dentro
de y entre las empresas federadas y comunidades peer-to-peer.
Kerberos provee seguridad, single-sing-on, confiable, servicio third-party

y mutual authentication.
Seguridad
Kerberos es seguro ya que nunca trasmite contraseñas sobre la red en

forma legible. Es único en el uso de tickets, mensajes criptográficos de
tiempo limitado que proveen una identidad al usuario la cual es dada al
servidor sin el envío de contraseñas sobre la red o mediante el
almacenamiento de las contraseñas en cache en el disco local del
usuario.
Single-sing-on (ver Glosario)
Trusted third-party
Refiere al hecho de que Kerberos trabaja a través de un servidor de

autenticación centralizadaza que todos los sistemas en la red confían.

Todas las solicitudes de autenticación son ruteadas a través del servidor

central de Kerberos
Mutual authentication (ver Glosario)
2.3.3 Estructura de seguridad .NET
Figura 5
En la Figura 5 se puede apreciar la arquitectura propuesta por la

plataforma de Microsoft.
Antes de comenzar a hablar sobre la seguridad ofrecida por ASP.NET

debemos mencionar un aspecto importante en la plataforma de
seguridad de Microsoft, el IIS; el IIS es el punto de entrada de las
aplicaciones Web.
2.3.4 Autenticación de IIS
El Internet Information Services (IIS) proporciona varios esquemas de

autenticación:
 Anónimo (activada por defecto)

 Basic
 Digest
 Autenticación de Windows (activada por defecto)
 Certificado del cliente
Independientemente de que el método que se elija, después que el IIS

autentica al cliente se pasa un token de seguridad a ASP.NET. Si
configuramos ASP.NET para utilizar la autenticación de Windows y

habilitamos la impersonalización, ASP.NET personificará al usuario

representado por este token de seguridad.
Impersonalización es cuando ASP.NET ejecuta código en el contexto de

un cliente autenticado y autorizado. De forma predeterminada, ASP.NET
no utiliza la impersonalización y ejecuta todo el código utilizando la
misma cuenta de usuario del proceso ASP.NET, que por lo general es la
cuenta ASPNET. Esto es contrario al comportamiento predeterminado de
ASP, que usa la impersonalización por defecto.
2.3.4.1 Anónimo
Esta autenticación ofrece a los usuarios el acceso a las áreas públicas de
su sitio Web sin petición de un nombre de usuario o contraseña. Aunque
está dentro de los esquemas de autenticación, no realiza ninguna
autenticación de clientes, ya que el cliente no está obligado a
suministrar ninguna credencial. En lugar de ello, IIS proporciona
credenciales almacenadas en Windows utilizando una cuenta de usuario
especial, IUSR_machinename. Por defecto, IIS controla la contraseña
para esta cuenta. Quiera o no el control de contraseña de IIS afecta a los
permisos de la cuenta de usuario anónimo. Cuando IIS controla la
contraseña, una DLL (iissuba.dll) autentica al usuario mediante un
código de acceso de red. La función de esta DLL es la validación de la
contraseña proporcionada por IIS y para informar a Windows que la
contraseña es válida, con lo que se autentica al cliente. Sin embargo, en
realidad no proporciona una contraseña para Windows. Cuando IIS no
controla la contraseña, IIS llama a la API LogonUser () en Windows y
proporciona el nombre de cuenta, contraseña y nombre de dominio para
iniciar sesión en el usuario utilizando un código de acceso local. Después
de que el código de acceso, IIS guarda en el cache los token de
seguridad y impersonaliza la cuenta. Un código de acceso local hace
posible que el usuario anónimo pueda acceder a los recursos de la red,
mientras que un código de acceso de red no.
2.3.4.2 Basic
Este esquema de autenticación tiene el mismo comportamiento que el
ya descripto en la sección “Autenticación Web”.
2.3.4.3 Digest
ya descripto en la sección “Autenticación Web”.

2.3.4.4 Autenticación de Windows

La autenticación integrada de Windows (anteriormente conocida como la
autenticación NTLM y Windows NT autenticación Challenge/Response),
puede utilizar las autenticaciones NTLM o Kerberos V5 y sólo funciona
con Internet Explorer 2,0 o posterior.
Cuando Internet Explorer intenta acceder a un recurso protegido, IIS

envía dos cabezales del tipo WWW-Authenticate, Negotiate y NTLM.
Si Internet Explorer reconoce un cabezal Negotiate, será seleccionado

por ser la primera opción en la lista. Cuando se utiliza Negotiate, el
navegador ofrece la información de ambas NTLM y Kerberos. En el
servidor, IIS utilizará Kerberos si tanto el cliente (Internet Explorer 5,0 y
posterior) y el servidor (IIS 5,0 y posterior) está utilizando Windows
2000, o posterior, y ambos son miembros del mismo dominio o dominios
de confianza. De lo contrario, el servidor por defecto utilizará NTLM.
Si el Internet Explorer no entiende Negotiate, éste utilizará NTLM.
Así, el mecanismo que se usa depende de una negociación entre

Internet Explorer y IIS.
Cuando se utiliza en combinación con la autenticación Kerberos v5, IIS

puede delegar las credenciales de seguridad entre los ordenadores con
Windows 2000 (y posteriores), que son de confianza para la delegación
y configurarse para la delegación. La delegación permite el acceso
remoto de los recursos en nombre del usuario delegado.
La autenticación integrada de Windows es un buen sistema de

autenticación en un entorno de intranet, donde los usuarios tienen
cuentas de dominio de Windows, sobre todo cuando se utiliza Kerberos.
La autenticación integrada de Windows, como la autenticación Digest,
no pasa la contraseña de usuario a través de la red. En cambio, se
intercambia un valor codificado.
2.3.4.5 Certificado del cliente

ya descripto para la plataforma Java.
2.3.5 Autenticación de ASP.NET
En esta sección describiremos los métodos o esquemas de

autentificación propuestos por ASP.NET. Cabe destacar que ASP.NET
implementa esquemas de autenticación adicionales usando la

autenticación de diversos proveedores, que son independientes y sólo se

aplican después de la autenticación de los regímenes de IIS. ASP.NET es
compatible con los siguientes proveedores de autenticación:
 Windows
 Forms
 Live ID (antes Live ID)
 Predeterminada
2.3.5.1 Windows (autenticación por defecto)
El proveedor de autenticación de Windows se basa en IIS para realizar la

autenticación requerida por un usuario. Después que el IIS autentica al
usuario, éste le entrega un token de seguridad a ASP.NET. Luego
ASP.NET construye y asigna un objeto de la clase WindowsPrincipal a la
aplicación basada en el token de seguridad que recibe del IIS.
Pros
Autentificadores utilizan cuentas de Windows, de modo que no necesitan
escribir ningún código de autenticación personalizado.
Contras
Puede requerir el uso y manejo de las diferentes cuentas de usuario de
Windows.
Además, se debe tener en cuenta que cada esquema de autenticación

IIS tiene sus propias ventajas y desventajas asociadas, las cuales deben
ser consideradas al momento de elegir un modelo de seguridad.
2.3.5.2 Forms
El proveedor de autenticación Forms es un sistema de autenticación que

permite a la aplicación recolectar credenciales utilizando un formulario
HTML directamente del cliente. El cliente presenta las credenciales
directamente al código de la aplicación para su autenticación. Si la
aplicación autentica al cliente, emite una cookie al cliente que el cliente
presenta en solicitudes posteriores. Si una solicitud de protección de los
recursos no contiene la cookie, la aplicación redirige al cliente a la
página de inicio de sesión. Cuando se autentican credenciales, la
aplicación puede almacenar las credenciales de varias maneras, como
por ejemplo un archivo de configuración o de una base de datos SQL
Server.

Pros
 Hace posible que los sistemas de autenticación sean personalizados
utilizando criterios arbitrarios.
 Puede ser utilizado para la autenticación o personalización.
 No requiere cuentas de Windows que se correspondan con el usuario
a autenticar.
Contras
 Está sujeto a ataques de repetición durante toda la vida de la cookie,
a menos que utilicen SSL / TLS.
 Es sólo aplicable a los recursos que sean mapeados a
Aspnet_isapi.dll.
2.3.5.3 Live ID
El proveedor de autenticación Live ID es un servicio de autenticación

centralizado proporcionado por Microsoft que ofrece un único código de
acceso y servicios de perfil básicos para los sitios miembros. Live ID es
una forma de autenticación basada en el servicio. Cuando se registra en
los sitios miembros de Live ID, el servicio de Live ID asigna claves
específicas para cada sitio. El servidor de autentificación (Login) de Live
ID utiliza esta clave para cifrar y descifrar los strings de consulta
pasados entre los sitios miembros y el propio servidor.
Pros
• Compatible con inicio de sesión único a través de varios
dominios.
• Compatible con todos los navegadores.
Contras
• Se producen dependencias externas para el proceso de
autenticación.
2.3.5.4 Predeterminada
Para los casos en que la autenticación no es requerida o es necesaria

una implementación personalizada se puede optar por el proveedor de
autenticación predeterminado de Windows. Para lograr desarrollar
esquemas propios de autenticación puede ser utilizado un filtro ISAPI
que autentifica usuarios manualmente y crea un objeto de la clase
GenericPrincipal.

Pros
• Ofrece control total del proceso de autenticación
proporcionando una máxima flexibilidad.
• Proporciona el más alto rendimiento si no se implementa un
método de autenticación.
Contras
• Implementaciones personalizadas de esquemas de
autenticación son raramente tan seguros como los
proporcionados por el sistema operativo.
• Requiere trabajo extra implementar un régimen de
autenticación personalizada.
2.3.6 Autorización de ASP.NET
Después de la autenticación principal, el siguiente paso es determinar si

el usuario tiene permiso para acceder a los recursos que está
solicitando. ASP.NET funciona en conjunción con su entorno primario,
Internet Information Services (IIS), para proporcionar servicios de
autenticación y autorización a las aplicaciones.
Hay varios esquemas para determinar si un usuario autenticado tiene

autorización para acceder a un recurso en particular. La seguridad de
una aplicación ASP.NET se basa en la infraestructura de seguridad de IIS
y Windows. Toda comunicación entre el cliente y la solicitud debe pasar
primero por IIS y cualquier proceso que se ejecuta en un servidor de
Windows lo hace en el contexto de una cuenta de usuario autenticado.
Cuando se utiliza el sistema de archivos NTFS, Windows mantiene una
lista de control de acceso (ACL) para todos los recursos que controla,
que sirve como la autoridad máxima de los permisos de acceso a los
recursos.
Además, las aplicaciones ASP.NET pueden utilizar archivos de

configuración para obtener información de autorización. Todas las
aplicaciones ASP.NET en una máquina en particular heredan su
configuración de seguridad de un archivo denominado machine.config.
Cada aplicación ASP.NET puede anular a su vez algunos de los ajustes
en machine.config utilizando una aplicación a nivel de configuración
llamado Web.config. Es importante recordar que los permisos que
figuran en una lista de control de acceso sobrescriben cada permiso
concedido por los archivos de configuración. También es importante
tener en cuenta que ASP.NET es una extensión ISAPI, que sólo controla

el acceso a los recursos que se encuentren mapeados con el

Aspnet_isapi.dll.
Los controles de autorización en una aplicación ASP.NET son los

siguientes:
 Listas de Control de Acceso (ACLs)

 Permisos por Servidor Web
 Autorización de URL
 .NET Objetos Principales
 Funciones y Niveles de Seguridad
Listas de control de acceso de Windows
Utilizando ACLs de Windows, se pueden crear archivos de permisos del

sistema en archivos específicos de una aplicación. Esta solución
funciona mejor si su autenticación de usuarios se realiza a través de
cuentas de Windows. Para utilizar Windows ACLs, se debe utilizar el
sistema de archivos NTFS.
Permisos por Servidor Web
Se puede configurar IIS para especificar los permisos de los directorios

del sitio Web, tales como acceso de lectura y el directorio de
navegación. Es importante comprender la distinción entre los permisos
de servidor Web y permisos NTFS. A diferencia de NTFS, los permisos de
servidor Web se aplican a todos los usuarios que accedan a la página
Web y sitios FTP. Los permisos NTFS sólo se aplican a un determinado
usuario o grupo de usuarios con una cuenta válida de Windows. NTFS
controla el acceso físico a los directorios en su servidor, mientras que los
permisos de Web y FTP controlan el acceso a directorios virtuales en tu
Web o sitio FTP.
Autorización de URL
La clase UrlAuthorizationModule mapea usuarios y roles a los elementos

dentro del espacio de nombre de la URI, que es definida por un URL.
Este módulo implementa authorization assertions tanto positivas como
negativas. El módulo puede ser utilizado para permitir o denegar
selectivamente determinados usuarios el acceso a los elementos
arbitrarios al espacio de nombres de la URI. Por ejemplo, es posible
basar el acceso de usuarios en función de los roles de usuario.

.NET Objetos Principals
• Objeto WindowsPrincipal
El espacio de nombres del System.Security.Principal proporciona una
clase WindowsPrincipal para representar el contexto de seguridad
bajo el cual el código está en ejecución. Este objeto se crea
automáticamente cuando se utiliza autenticación de Windows en IIS.
Permite comprobar la pertenencia al grupo de Windows de una
cuenta de usuario de Windows y restringir el acceso en consecuencia.
• Objeto GenericPrincipal
Se puede crear un objeto de la clase GenericPrincipal basado en un
rol. Esto debe ser utilizado si se tiene un usuario/rol para la base de
datos. Es posible rellenar el objeto principal en el caso
OnAuthenticate. También se puede tener una tabla personalizada
asignada a las cuentas de Windows en la que se accede a este
evento. Utilizando esa información, se puede crear un objeto principal
personalizado para el usuario autenticado. Para retornar usuarios
autenticados, se puede usar una cookie para recrear el objeto
principal.
Funciones y Niveles de Seguridad
Es posible que en ciertos casos sea necesario utilizar el método de

niveles de seguridad para restringir que métodos principales puede
llamar un cliente en particular. Hay varios métodos para este tipo de
seguridad.
Si se está utilizando cuentas de Windows, se deben crear roles para los

usuarios mediante la creación de grupos de Windows.
2.4 Conclusión
A través de la información recolectada en este informe podemos

apreciar que más allá de algunas diferencias especificas de cada
plataforma, los mecanismos de seguridad implementados son muy
similares y se basan en los mismos conceptos básicos.
Ambas plataformas se mantienen al día con los conceptos de seguridad

que se manejan y estudian en el mundo. Las fortalezas y debilidades
que cada plataforma exponga con respecto a la otra no radican en una

posible diferencia entre mecanismos que cada una maneje sino en la

eficacia y/o eficiencia en la implementación de los mismos.

3 Herramientas actuales
Es esta sección describiremos algunas de las herramientas con las que
se cuenta en la actualidad para la implementación de sistemas de
autenticación y autorización de usuarios.
3.1 Java
3.1.1 JOSSO
JOSSO, o Java Open Single Sign-On, es un J2EE open source basado en la
infraestructura SSO (Single Sign On) destinada a proporcionar una
solución para la centralización, plataformas neutrales, autenticación y
autorización del usuario.
Características principales (fragmento extraído de la página principal de

JOSSO):
• J2EE Transparent Single Sign-On cross domain/cross organization.
• Pluggable Framework to allow the implementation of multiple
authentication schemes and stores using Spring or built-in IoC
container.
• Runs in Apache Tomcat.
• Runs in JBoss application server.
• Runs in BEA WebLogic 9 application server
• Runs in Apache Geronimo application server
• Integrates with Spring Acegi.
• Provides Identity information to Web applications and EJBs through
the standard Servlet and EJB Security API respectively.
• Supports Strong Authentication using X.509 client certificates.
• LDAP support for storing user information and credentials.
• Database support for storing user information and credentials.
• Client API for PHP. This allows to build SSO-enabled PHP
applications.
• Client API for Microsoft ASP. This allows to build SSO-enabled ASP
applications.
• Compatibility with Apache Pluto Portlet Container
• Standard Based: JAAS, Web Services/SOAP, EJB, Struts,
Servlet/JSP,J2EE.
• 100% Java
Actualmente esta herramienta se encuentra en su versión 1.7

Esta herramienta se puede encontrar en la sección Glosario.

Figura 6 – JOSSO Vista de la arquitectura

3.1.2 OPENSSO
El proyecto Open Web SSO (OpenSSO) proporciona servicios de

identidad básicos para simplificar el inicio de sesión único (SSO) y
transparente al usuario como un elemento de seguridad en una
infraestructura de red. OpenSSO proporciona la base para la integración
de distintas aplicaciones Web que puedan operar normalmente en un
conjunto heterogéneo de repositorios de identidad los cuales son
alojados en una variedad de plataformas, tales como los servidores Web
y de aplicaciones. Este proyecto se basa en la base de código de Sun
Java System Access Manager, un núcleo de identidad que ofrece la
infraestructura de producto de Sun Microsystems.
3.1.3 CAS
El JA-SIG Central Authentication Service fue originalmente desarrollado

por la Universidad de Yale. Desde entonces se ha convertido en un
proyecto JA-SIG.
Desde la disponibilidad de la implementación y el protocolo CAS, se han

desarrollado muchos programas cliente para compatibilizar con CAS
esas aplicaciones que pueden utilizar CAS para la autenticación de los
usuarios.
CAS es una solución empresarial de Single Sign-on para Web services.

Un número de soluciones out-of-the-box existen para permitir servicios
Web escritos en lenguajes específicos, o basado en un framework, para
utilizar CAS. Esto permitiría a los desarrolladores aplicar una solución
SSO en cuestión de horas.

Figura 7 – Esquema de CAS

3.2 Microsoft
Continuando con la temática de esta sección, pasaremos a comentar las

herramientas existentes para la plataforma Microsoft.
Como vimos en la sección anterior la plataforma de autenticación y

autorización de Microsoft se basa en los siguientes elementos:
• Active directory
• ASP.NET
• .NET Framework
• IIS
3.2.1 Active Directory

Componente central de la plataforma Windows, el servicio de directorios
del Active Directory proporciona los medios necesarios para gestionar
las identidades y las relaciones que conforman los entornos de red.
3.2.2 ASP.NET
ASP.NET es un modelo de desarrollo Web unificado que incluye los
servicios necesarios para construir aplicaciones empresariales Web con
un mínimo de codificación. ASP.NET es parte de la. NET Framework, y
cuando se codifican aplicaciones en ASP.NET se tiene acceso a clases en
el. NET Framework. Se puede codificar aplicaciones en cualquier
lenguaje compatible con el lenguaje común en tiempo de ejecución
(CLR), incluidos Microsoft Visual Basic, C #, JScript. NET, J # y. Estos
idiomas le permiten desarrollar aplicaciones ASP.NET que se benefician
del CLR , tipo de seguridad, la herencia, etc.
ASP.NET incluye (fragmento extraído de la página principal de ASP.NET):

• A page and controls framework
• The ASP.NET compiler
• Security infrastructure
• State-management facilities
• Application configuration
• Health monitoring and performance features
• Debugging support
• An XML Web services framework
• Extensible hosting environment and application life cycle
management
• An extensible designer environment

Actualmente esta herramienta se encuentra en su versión 3.5 (ultima

versión para el .NET Framework 3.5)
Esta herramienta se puede encontrar en la sección Glosario
3.2.3 .NET Framework
El. NET Framework es un componente integral de Windows que soporta

la creación y funcionamiento de la próxima generación de aplicaciones y
servicios Web XML. El. NET Framework está diseñado para cumplir los
siguientes objetivos:
 Ambiente de programación orientada a objetos coherente donde el

código objeto se almacena y ejecuta a nivel local, ejecutado a
nivel local pero distribuido en Internet, o ejecutado remotamente.
 Proporcionar un entorno de ejecución de código que reduzca al

mínimo la distribución del software y el conflicto de versiones.
 Proporcionar un entorno de ejecución de código que promueve la

ejecución de código seguro, incluyendo el código creado por un
desconocido o semi-tercero de confianza.
 Proporcionar un entorno de ejecución de código que elimine los

problemas de rendimiento o de entornos con interpretes o scripts.
 Experiencia del desarrollador consistente a través de una amplia

variedad de tipos de aplicaciones, como las aplicaciones basadas
en Windows y aplicaciones basadas en la Web.
 Construir todo tipo de comunicación sobre las normas de la

industria para garantizar que el código basado en el .NET
Framework puede integrarse con cualquier otro código.
El .NET Framework tiene dos componentes principales: the common

language runtime(CRL) y el .NET Framework class library. El CRL es la
base del .NET Framework. Se puede ver al CRL como un agente que
administra el código en tiempo de ejecución, suministrando servicios
básicos tales como la gestión de memoria, gestión de threads, y
remoting, a la vez forzando estrictos tipos de seguridad y otras formas
de código preciso que promueven la seguridad y robustez. De hecho, el
concepto de gestión de código es un principio fundamental de la
ejecución. La biblioteca de clases, el otro componente principal de la.
NET Framework, es un proceso global, orientado a objetos de la

colección de tipos reutilizables que puede utilizar para desarrollar

aplicaciones que van desde la tradicional línea de comandos o
aplicaciones de interfaz gráfica de usuario (GUI) a aplicaciones
basadas en últimas innovaciones proporcionados por ASP.NET, como los
Formularios Web y servicios Web XML.
La siguiente ilustración muestra la relación entre el CRL y la biblioteca

de clases a las aplicaciones y al sistema general. La ilustración también
muestra cómo funciona el código administrado dentro de un concepto
más amplio de la arquitectura.
Figura 8 – Arquitectura .NET Framework
Actualmente esta herramienta se encuentra en su versión 3.5

3.2.4 IIS
Este servicio convierte a un ordenador en un servidor de Internet o
Intranet es decir que en las computadoras que tienen este servicio

instalado se pueden publicar páginas Web tanto local como

remotamente (servidor Web).
El servidor Web se basa en varios módulos que le dan capacidad para

procesar distintos tipos de páginas, por ejemplo Microsoft incluye los de
Active Server Pages (ASP) y ASP.NET. También pueden ser incluidos los
de otros fabricantes, como PHP o Perl.
Actualmente esta herramienta se encuentra en su versión 7

4 Glosario
Ver Glosario_vX.X.doc
5 Referencias
1. J2EE and .NET security
www.cgisecurity.com/lib/J2EEandDotNetsecurityByGerMulcahy.pdf
2. Seguridad Informática – Identificación, Autenticación, Autorización

http://www.fing.edu.uy/inco/cursos/fsi/teorico/2008/FSI-2008-IAA.pdf
3. The J2EE 1.4 Tutorial

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security.html
4. Understanding SSL
http://www.tech-faq.com/lang/es/understanding-ssl.shtml
5. Java Authentication and Authorization Service (JAAS) in Java 2, Standart Edition

(J2SE) 1.4
http://java.sun.com/developer/technicalArticles/Security/jaasv2/
6. Introducción a JAAS
http://www.jaasbook.com/ (01 - Introducing JAAS)
7. J2EE pathfinder: Java security with JAAS and JSSE

http://www.ibm.com/developerworks/java/library/j-pj2ee9.html
8. The J2EE Tutorial - Security

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security.html
9. J2EE Application Security Model – JAVA DEVELOPER’S JOURNAL

http://java.sys-con.com/read/36655.htm
Para más información sobre alguno de los temas:

10. The FreeBSD Diary – Client Authentication with SSL
http://www.freebsddiary.org/openssl-client-authentication.php
11. ONJava.com – J2EE Form Based Authentication

http://www.onjava.com/pub/a/onjava/2002/06/12/form.html
12. Digest – MD5 Authentication

http://java.sun.com/products/jndi/tutorial/ldap/security/digest.html
13. Compare and Contrast the authentication types (BASIC, DIGEST, FORM, and
CLIENT-CERT): describe
http://java.boot.by/wcd-guide/ch05s03.html
14. JDK 5.0 Security-Related API & Developer Guides

http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html
15. ASP.NET Overview

http://msdn2.microsoft.com/en-us/library/4w3ex9c2.aspx
16. Active Directory

http://technet.microsoft.com/en-us/library/bb727067.aspx
17. .NET Framework Conceptual Overview

http://msdn2.microsoft.com/en-us/library/zw4w595w.aspx
18. RFC 1945

http://www.faqs.org/rfcs/rfc1945.html
19. Kerberos
• Libro: Kerberos: The Definitive Guide
Año publicación: 2003
ISBN:0596004036
• http://www.kerberos.org/
20. Certificado X.509

http://www.alu.ua.es/f/fgc10/CERTIFICADOS%20X.509.ppt
5.1 Herramientas
21. JOSSO
http://www.josso.org
22. OPENSSO
https://opensso.dev.java.net/
23. CAS
http://www.ja-sig.org/products/cas/
24. ASP.NET
http://www.asp.net/

25. .NET Framework

http://www.microsoft.com/net/
26. IIS
http://www.iis.net/default.aspx?tabid=1
5.2 Imagenes
27. Figuras 1 a 4
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html
28. Figura 6
http://www.josso.org
29. Figura 7
http://www.ja-sig.org/products/cas/
30. Figura 8
http://msdn2.microsoft.com/en-us/library/zw4w595w.aspx

Estado Del Arte Autenticacion y Autorizacion - v2.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estado Del Arte Autenticacion y Autorizacion - v2.3

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE LA REPÚBLICA | FACULTAD DE INGENIERÍA | INSTITUTO DE COMPUTACIÓN

Estado del arte de los mecanismos de

Damián Konkolowicz CI: 4.333.040-8

Docente Tutor: Laura González, Felipe Zipitria

Proyecto de Grado 2008 Página 1 de 38

Fecha Versi Descripción Autor

Proyecto de Grado 2008 Página 2 de 38

Proyecto de Grado 2008 Página 3 de 38

Proyecto de Grado 2008 Página 4 de 38

Resumen del trabajo

Dada la necesidad de mejores mecanismos de seguridad Java diseño

Por ultimo la seguridad en Web Services por medio de SOAP se utiliza

Por otro lado tenemos a Microsoft, la seguridad en esta plataforma es

Para la seguridad Web la estructura de seguridad esta definida por la

Proyecto de Grado 2008 Página 5 de 38

infraestructura de autenticación en la seguridad brindada por el IIS y

Proyecto de Grado 2008 Página 6 de 38

En la sección “Mecanismos de Seguridad” se trataran los mecanismos

Proyecto de Grado 2008 Página 7 de 38

2.1 Autenticación Web

2.1.1 HTTP Basic authentication

Los pasos a seguir con la autenticación básica son los siguientes:

En la Figura 1 se muestra un esquema de los pasos mencionados

Figura 1 – Esquema Básic Authentication

Proyecto de Grado 2008 Página 8 de 38

HTTP Basic Authentication no es especialmente segura. Este

2.1.2 HTTPS Client authentication (Certificados)

La autenticación de certificados de cliente es un método más seguro que

Si se especifica la autenticación de certificados de cliente, el servidor

2.1.3 HTTP FORM-based authentication

La autenticación basada en formularios consiste en diseñar en el

Proyecto de Grado 2008 Página 9 de 38

Figura 2 – Esquema Form-based Authentication

El usuario solicita acceso a información y en el caso de que el mismo no

2.1.4 Mutual Authentication

Usando este mecanismo de autenticación el cliente y el servidor se

Figura 3 – Esquema 1 Mutual Authentication

Proyecto de Grado 2008 Página 10 de 38

La otra manera de utilizar la autenticación mutua se muestra en los

Figura 4 – Esquema 2 Mutual Authentication

2.1.5 HTTP Digest authentication

Proyecto de Grado 2008 Página 11 de 38

Al igual que la autenticación básica HTTP, HTTP Digest authentication

La ventaja de este método es que la contraseña sin formato está

La contraseña de autenticación apoya el concepto de digerir

2.1.6 Autenticación con SSL

Las contraseñas no están protegidas por la confidencialidad con HTTP

La tecnología SSL (Secure Socket Layer) permite que los navegadores

SSL contiene las siguientes consideraciones de seguridad:

Proyecto de Grado 2008 Página 12 de 38

Para instalar y configurar el soporte SSL en un servidor web, se

2.2 Java (J2EE)

2.2.1 Realms, usuarios, grupos y roles

El servidor J2EE de autenticación incluye e interactúa con los siguientes

• Realm: Una colección de usuarios y grupos que están controladas

Proyecto de Grado 2008 Página 13 de 38

2.2.2 Autenticación Web

Los mecanismos de seguridad utilizados para aplicaciones Web por la

• HTTP Basic authentication

2.2.3 Java Authentication and Authorization Service

La Autenticación y Autorización de Java Service (JAAS) fue diseñada para

Proporciona un mecanismo flexible para la autenticación de usuarios y

• Verificar que el usuario es quien dice ser (autenticación)