Estado Del Arte Autenticacion y Autorizacion_v2.3

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

Proyecto de GradoEdició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-8Andrés Pereyra CI: 3.776.934-4

Docente Tutor: Laura González, Felipe Zipitria

Proyecto de Grado 2008 Página 1 de 37


Historia de revisiones

Fecha Versión

Descripción Autor

12/04/2008 1.0 Versión Inicial Andrés Pereyra, Damián Konkolowicz

21/04/2008 1.1 Se completo sección “Herramientas actuales”

Andrés Pereyra, Damián Konkolowicz

13/05/2008 2.0 Nuevas secciones,corrección de errores.


25/05/2008 2.1 Se agrego la sección “Resumen del Trabajo” y “Palabras clave”


19/06/2008 2.2 Corrección de errores y revisión general.


09/08/2008 2.3 Cambios debido a creación de glosario.




Contenido HISTORIA DE REVISIONES...............................................................3 CONTENIDO...............................................................................4 RESUMEN DEL TRABAJO.................................................................6 PALABRAS CLAVE........................................................................71 INTRODUCCIÓN..........................................................................82 MECANISMOS DE SEGURIDAD........................................................9

2.1 Autenticación Web.....................................................................................92.1.1 HTTP Basic authentication...............................................................................92.1.2 HTTPS Client authentication (Certificados).....................................................102.1.3 HTTP FORM-based authentication..................................................................102.1.4 Mutual Authentication....................................................................................112.1.5 HTTP Digest authentication............................................................................132.1.6 Autenticación con SSL....................................................................................13

2.2 Java (J2EE)................................................................................................142.2.1 Realms, usuarios, grupos y roles....................................................................142.2.2 Autenticación Web.........................................................................................152.2.3 Java Authentication and Authorization Service (JAAS)....................................15

2.2.3.1 Autenticación con JAAS ...........................................................................162.2.3.2 Autorización con JAAS..............................................................................172.2.3.3 Transporte con JSSE.................................................................................172.2.3.4 Seguridad en Web Services.....................................................................18

2.3 Microsoft (.NET)........................................................................................182.3.1 Active Directory (Sistema Operativo).............................................................18

2.3.1.1 Usuarios...................................................................................................182.3.1.2 Security Principals....................................................................................192.3.1.3 Grupos.....................................................................................................19

2.3.2 Kerberos........................................................................................................192.3.3 Estructura de seguridad .NET.........................................................................202.3.4 Autenticación de IIS.......................................................................................21

2.3.4.1 Anónimo...................................................................................................212.3.4.2 Basic........................................................................................................222.3.4.3 Digest......................................................................................................222.3.4.4 Autenticación de Windows.......................................................................222.3.4.5 Certificado del cliente .............................................................................23

2.3.5 Autenticación de ASP.NET..............................................................................232.3.5.1 Windows (autenticación por defecto).......................................................232.3.5.2 Forms.......................................................................................................242.3.5.3 Live ID......................................................................................................242.3.5.4 Predeterminada.......................................................................................25

2.3.6 Autorización de ASP.NET................................................................................252.4 Conclusión................................................................................................28

3 HERRAMIENTAS ACTUALES..........................................................293.1 Java..........................................................................................................29

3.1.1 JOSSO.............................................................................................................293.1.2 OPENSSO.......................................................................................................313.1.3 CAS................................................................................................................31

3.2 Microsoft..................................................................................................333.2.1 Active Directory.............................................................................................333.2.2 ASP.NET.........................................................................................................333.2.3 .NET Framework.............................................................................................34



3.2.4 IIS...................................................................................................................364 GLOSARIO..............................................................................375 REFERENCIAS..........................................................................37

5.1 Herramientas...........................................................................................385.2 Imagenes.................................................................................................39



Resumen del trabajoAutenticació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 claveAutorización, Autenticación, .NET, JAAS, J2EE, IIS, SSO



1 IntroducciónEl objetivo principal de este documento es analizar los mecanismos de autenticación y autorización utilizados por las plataformas Java y .NETPara 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 WebLos 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 formulario3 – El usuario ingresa y envía la información solicitada4 – 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 AuthenticationEn 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 rolesPara 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 PrincipalsLos 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 GruposLos 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 cre-cido 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 convertir-se en una solución universal para la autenticación distribuida y el proble-ma de permitir la autorización universal "Single Sign-On" dentro de y en-tre 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ónimoEsta 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 BasicEste esquema de autenticación tiene el mismo comportamiento que el ya descripto en la sección “Autenticación Web”.

2.3.4.3 DigestEste esquema de autenticación tiene el mismo comportamiento que el ya descripto en la sección “Autenticación Web”.

2.3.4.4 Autenticación de WindowsLa 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 Este esquema de autenticación tiene el mismo comportamiento que el 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.

ProsAutentificadores utilizan cuentas de Windows, de modo que no necesitan escribir ningún código de autenticación personalizado.

ContrasPuede 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 JOSSOJOSSO, 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.7Esta 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.

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

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.

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



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 DirectoryComponente 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.NETASP.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 Esta herramienta se puede encontrar en la sección Glosario

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 Esta herramienta se puede encontrar en la sección Glosario



4 GlosarioVer 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://www.onjava.com/pub/a/onjava/2002/06/12/form.html

http://www.freebsddiary.org/openssl-client-authentication.php

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security.html

http://www.ibm.com/developerworks/java/library/j-pj2ee9.html

http://www.jaasbook.com/pdfs/jaas-in-action_chapter01-05.pdf

http://www.jaasbook.com/

http://java.sun.com/developer/technicalArticles/Security/jaasv2/

http://www.tech-faq.com/lang/es/understanding-ssl.shtml

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security.html

http://www.fing.edu.uy/inco/cursos/fsi/teorico/2008/FSI-2008-IAA.pdf

http://www.cgisecurity.com/lib/J2EEandDotNetsecurityByGerMulcahy.pdf


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 GuideAño publicación: 2003ISBN: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/


http://www.asp.net/


https://opensso.dev.java.net/

http://www.josso.org/

http://www.alu.ua.es/f/fgc10/CERTIFICADOS%20X.509.ppt

http://www.kerberos.org/

http://www.faqs.org/rfcs/rfc1945.html


http://technet.microsoft.com/en-us/library/bb727067.aspx

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

http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html

http://java.boot.by/wcd-guide/ch05s03.html

http://java.sun.com/products/jndi/tutorial/ldap/security/digest.html


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


30. Figura 8





http://www.josso.org/

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html

http://www.iis.net/default.aspx?tabid=1

http://www.microsoft.com/net/

Estado Del Arte Autenticacion y Autorizacion_v2.3

Documents

Transcript of Estado Del Arte Autenticacion y Autorizacion_v2.3