facultat d’informÀtica de barcelona single sign-on miquel trilla
TRANSCRIPT
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Single Sign-On
Miquel Trilla
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Contenido de la presentación
¿Qué es Single Sign-On (SSO)?
Arquitecturas para un sistema SSO
Situación actual en la Facultat d’Informàtica de Barcelona
Conclusiones
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
¿Qué es Single Sign-On?
Definición Single Sign-on (SSO):
Concepto que consiste en la autentificación única por parte del usuario para acceder a sus recursos
La idea es introducir una única vez el nombre de usuario y contraseña, sin necesidad de volver introducirlo a la hora de acceder a nuevos recursos en los que aún no se había autentificado.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
¿Qué es Single Sign-On?
Características:
Multiplataforma: facilita las tareas de inicio de sesión y de acceso a recursos de red desde distintas plataformas
Transparencia: el acceso a los recursos de sistemas se efectúa de forma transparente al usuario debido a la automatización del inicio de sesión
Facilidad de uso: el usuario se autentifica una única vez y el sistema le permite acceder a los recursos para los cuales esta autorizado. Así se evita las interrupciones producidas por la solicitud de usuario y contraseña para el acceso a diferentes recursos
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
¿Qué es Single Sign-On?
Características:
Gestión sencilla: el uso de SSO aconseja la sincronización de contraseñas e información de los usuarios. Esto implica la simplificación de la gestión de los recursos por parte de los administradores.
Control de acceso: no se ve afectado por el uso de este sistema, SSO implica cambiar los mecanismos de autentificación del cliente y/o servidor, pero no modifica los permisos de los recursos.
Seguridad: depende de la arquitectura usada, pero en todos los casos la información viaja cifrada por la red (SSL, certificados...)
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Contenido de la presentación
¿Qué es Single Sign-On (SSO)?
Arquitecturas para un sistema SSO
Situación actual en la Facultat d’Informàtica de Barcelona
Conclusiones
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Clasificación
Clasificación de las arquitecturas SSO:
Simple
AutentificaciónCentralizada
AutentificaciónMúltiple
Basada en Tokens
Basada en PKI’s
Compleja
Sincronizaciónde contraseñas
Caché enel cliente
Caché enel servidor
SSO
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Solución simple
Single Sign-On con un único Servidor de Autentificación
Recurso
Servidor de Autentificación
ID PW
ID PW
BD de usuarios
Primer Sign-On
Intercambio de Autentificación
ID | PW
Token
ID | PW Confianza Validación
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Solución simple
Etapas en la Solución Simple:
1. El usuario desea acceder a un recurso. Se le pide un usuario y una contraseña que son enviados al servidor de autentificación.
2. El servidor de autentificación comprueba la validez de los datos introducidos, y genera un token de sesión para el cliente.
3. El cliente envía al servidor del recurso que quiere acceder el token recibido.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Solución simple
Etapas en la Solución Simple:
4. El servidor del recurso valida este token contra el servidor de autentificación (existe una relación de confianza entre los recursos y el servidor de autentificación).
5. Si el token es valido y se dispone de acceso al recurso, el cliente puede acceder él. En caso contrario, se deniega su acceso.
6. El usuario desea acceder a un nuevo recurso. De forma transparente a él, el cliente envía el token al servidor del recurso, repitiendo las etapas 4 y 5.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Credencial unica
Single Sign-On basado en el paso de Token
Autoridad de Autentificación
Primaria ID PW
ID PW
BD Primaria
Primer Sign-On
Segundo Sign-On transparente usando
Token Temporal
ID | PW
Token
ID | PW
Confianza
BD Secundaria
Token Temporal
Autoridad de Autentificación
Secundaria
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Basado en token
Etapas en la Solución basada en Token:
1. El usuario desea acceder a un recurso. Se le pide un usuario y una contraseña que son enviados al servidor de autentificación de ese recurso.
2. El servidor de autentificación comprueba la validez de los datos introducidos, y genera un token de sesión para el cliente, que le permite acceder al recurso.
3. El usuario desea acceder a un nuevo recurso que pertenece a otra Autoridad de Autentificación. El cliente de forma transparente envía el token recibido de la primera autoridad a esta segunda.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Basado en token
Etapas en la Solución basada en Token:
4. La segunda Autoridad Autentificadora mantiene una relacion de confianza con la primera Autoridad, con la que comprueba la validez del token (o ticket).
5. El usuario tiene acceso a los recursos que pertenecen a la segunda autoridad autentificadora gracias al token y a la confianza establecida con el generador de ese token.
6. Ejemplos: Kerberos, Passport, …
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Credencial unica
Single Sign-On basado en el uso de PKI:
Autoridad de Autentificación
Primaria ID PW
ID PW
BD
Registro del Usuario
Segundo Sign-On transparente usando Llave Pública como Credencial
(Certificado y Clave privada)
ID | PW
Confianza
Emisión Certificado
Autoridad de Autentificación
Secundaria
Certificado CA
Certificado CA
Certificado Usuario
Certificado CA
Clave Privada
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Basado en PKI
Etapas en la Solución basada en PKI:
1. El usuario se da de alta en un centro de autentificación (autoridad certificadora primaria) y recibe un certificado que consta de una clave privada, otra publica e información sobre la Autoridad certificadora y del usuario.
2. Cuando el usuario desea acceder a un servicio, éste le pide autentificación. El servidor usa el certificado público como credencial para comprobar la autentificación del cliente.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Pros y Contras
Autentificación Centralizada
Basado en Ventajas Desventajas
Token Tiene un único conjunto de credenciales simplifica la vida al administrador y al usuario. El software normalmente viene incorporado con el Sistema.
Requiere una infraestructura de autentificación homogénea. Se basa en criptografía simétrica.
PKI Tiene un único conjunto de credenciales simplifica la vida al administrador y al usuario. El software normalmente viene incorporado con el Sistema. Se basa en criptografía asimétrica.
Solo puede trabajar con un único conjunto de credenciales. Algoritmo complejo de validación de certificado. Requiere mucho cálculo en el lado del cliente. Requiere una infraestructura de autentificación homogénea (todos los servicios deben tener activado el mecanismo PKI)
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Caché en Cliente
Single Sign-On con autentificación múltiple y basado en caché cliente:
Autoridad de Autentificación
Primaria ID PW
ID PW
BD PrimariaPrimer
Sign-On
Segundo Sign-On transparente usando
credenciales almacenadas en
cliente
ID | PW
Token
Confianza
BD SecundariaAutoridad de
Autentificación Secundaria
ID | PW
Caché Cliente Segura
ID | PW
ID | PW
Token
PW
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Caché en Cliente
Etapas en la Solución Caché en el Cliente:
1. El usuario introduce una contraseña para acceder a su base de datos (almacenada en su ordenador).
2. En la base de datos se encuentran almacenadas las credenciales (usuario y contraseña) de los dominios a los cuales tiene acceso.
3. Cada vez que accedemos a un recurso de un dominio en el que no estamos autentificados, el cliente envía de forma transparente la credencial a la autoridad de autentificación, y esta le devuelve un token de sesión para los recursos del dominio.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Caché en Cliente
Etapas en la Solución Caché en el Cliente:
4. Cuando el usuario accede aun recurso del cual no tiene la credencial almacenada, el usuario introduce el nombre de usuario y contraseña, y esta credencial queda almacenada en la caché del cliente.
5. Existe una relación de confianza desde las autoridades de autentificación secundarias con la primaria.
Ejemplos:Windows XP, Windows .NET, Entrust Entellingence, …
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Caché en Servidor
Single Sign-On con autentificación múltiple y basado en caché servidor:
Autoridad de Autentificación
Primaria ID PW
ID PW
BD Primaria
Primer Sign-On
Segundo Sign-On transparente usando
Credenciales proporcionadas por
AAP2
ID | PW
Token
ID | PW
Confianza
Credenciales para AAS1
Autoridad de Autentificación
Secundaria
Peticiones credenciales sucesivas
Token
ID | PW
BD Secundaria
ID | PW
1 Autoridad de Autentificación Secundaria2 Autoridad de Autentificación Primaria
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Caché en Servidor
Etapas en la Solución Caché en el Servidor:
1. El usuario se valida en la primera autoridad de autentificación, y le devuelve un token para acceder a los recursos del dominio de esta autoridad.
2. Cuando el usuario desea acceder a un recurso que pertenece a otra autoridad de autentificación, de forma transparente toma la credencial de la segunda autoridad accediendo a la caché de la primera.
3. El cliente usa esta credencial (usuario y contraseña) y se valida en la segunda autoridad, devolviéndole esta un nuevo token para su dominio de recursos.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Caché en Servidor
Etapas en la Solución Caché en el Servidor:
4. Existe una relación de confianza desde las autoridades de autentificación secundarias con la primaria.
Ejemplos:Tivoli SecureWay SSO, CA Entrust SSO, …
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Pros y Contras
Autentificación Múltiple
Basado en Ventajas Desventajas
Caché Cliente
Puede trabajar con diferentes gestores de credenciales. No requiere una infraestructura de autentificación homogénea. Tiene un impacto importante en el cliente (requiere software extra o un SO que lo soporte).
Requiere una caché “segura” de credenciales en el lado del cliente – no recomendado su uso en dispositivos portatiles. Múltiples gestores de credenciales complica la vida al usuario y al administrador.
Caché Servidor
Puede trabajar con diferentes gestores de credenciales. No requiere una infraestructura de autentificación homogénea. Tiene un impacto importante en el cliente (requiere software extra).
Requiere un mecanismo de sincronización de credenciales (puede formar parte del producto SSO). Múltiples gestores de credenciales complica la vida al usuario y al administrador. Requiere software extra en el lado del servidor.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Arquitecturas SSO – Soluciones existentes
Las dos alternativas más importantes para arquitecturas SSO actualmente son:
Liberty Alliance Project: método basado en Federaciones
Passport.NET: es el componente principal de la estrategia .NET i soporta KerberosV
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Contenido de la presentación
¿Qué es Single Sign-On (SSO)?
Arquitecturas para un sistema SSO
Situación actual en la Facultat d’Informàtica de Barcelona
Conclusiones
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Situación actual en la FIB
Actualmente en la FIB tenemos un arquitectura de autentificación que se acerca al SSO simple.
Características:
Multiplataforma: Solaris, Windows 98, Windows XP, Linux
Sincronización de credenciales: único usuario y contraseña para la autentificación.
Credenciales centralizadas: un único servidor de autentificación valida los diferentes sistemas.
Seguridad: Uso de SSL (Secure Sockets Layer)
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Situación actual en la FIB
Características de autentificación en diferentes sistemas:
Credenciales centralizadas en un único servidor de autentificación implementada en un servidor LDAP (Lightweight Directory Access Protocol) con SSL.
Plataformas Solaris, Windows 98, XP y Linux que validan su autentificación sobre el servidor LDAP mediante PAM (Pluggable Authentication Modules).
Racó de la FIB autentificados mediante el modulo mod_auth_ldap del servidor web Apache.
Correo de alumnos (IMAP/POP+SSL y Webmail) autentificados mediante PAM.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Situación actual en la FIB
Esquema de la situación actual:
Servidor LDAP
Replica del Servidor
LDAP
Racò WEB+ Webmail
ServidorIMAP/POP
PC Aules(Samba)
Terminales(Solaris)
SSL SSL SSLSSLServidorFTP
SSL
PAM_LDAPPAM_LDAP PAM_LDAPMOD_AUTH_LDAP
PAM_LDAP
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Situación actual en la FIB
Descripción de los sistemas que participan en la autentificación:
Windows 98, XP y Linux sobre Arquitectura x86:Autentificación mediante Samba sobre Enos y Laika.• Enos• Laika
Terminales Sunray sobre Arquitectura Ultra-SPARC:Autentificación mediante PAM.• Moonrey• Universia• Ada• Solfoc
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Situación actual en la FIB
Descripción de los sistemas que participan en la autentificación:
Racó Web + Webmail desde Racó:Autentificación mediante modulo LDAP de Apache.• Xino / Xano• Emilio
FTP + POP/IMAP + Webmail fuera del Racó:Autentificación mediante PAM.• Emilio
LDAP:Servicio de Directorio donde se almacenan las credenciales.• Xino / Xano• Sanrey
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Consideraciones
Consideraciones a tener en cuenta a la hora de realizar la implantación de un sistema SSO:
Los verdaderos sistemas SSO requieren estar integrados en el Sistema Operativo (Login / Logout)
El proceso de autentificación es realizado por diferentes componentes según el SO (disparidad de mecanismos):
• NT / 2K / XP: GINA - LSA• Netware: GINA (4.x) o NMAS (5.0)• UNIX / Linux: PAM, NIS …
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Consideraciones
Consideraciones a tener en cuenta a la hora de realizar la implantación de un sistema SSO:
Especialmente molesto en el mundo Web:
• ¡ Se requiere hacer un login previo simplemente para acceder al navegador y autentificarnos de nuevo !
• Un buen sistema SSO debe contemplar la autentificación vía web como una parte más del sistema
Un buen sistema SSO combina elementos de una VPN (Virtual Private Network):
• Transporte seguro a nivel de Gestión• Transporte seguro a nivel de Aplicación
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Técnicas
Desarrollo de una API intermedia:
Ventajas:
• Las librerías del sistema son siempre las más eficientes.• Más fácil de localizar puntos de seguridad dentro de la aplicación.
Inconvenientes:
• Requiere retocar todas las aplicaciones.• Complicado de acoplar con aplicaciones existentes de hace
tiempo.• Imposible de llevar a cabo con aplicaciones externas.
Ejemplos: SASL, GSS-API, JAAS,…
Software
API
Lib. Dinámica
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Técnicas
Reemplazo de Librerías Dinámicas (DLL/.so):
Ventajas:
• No hay que retocar las aplicaciones existentes.• Transparente a las aplicaciones.
Inconvenientes:
• Puede provocar conflictos con alguna aplicación.• Difícil determinar exactamente que librerías hay que modificar
para que el sistema funcione. Varia según el sistema operativo.• Las actualizaciones del sistema operativo pueden destruir
nuestras librerías dinámicas.
Software
Lib. Dinámica
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Técnicas
Reemplazo de las Aplicaciones:
Ventajas:
• El nivel más alto de transparencia.
Inconvenientes:
• No es escalable (hay que cambiar TODO).• No es interoperable.• Se depende de la solución comercial.
Software
API
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Kerberos
Kerberos: última versión - KerberosV
Es un método de autentificación que sigue la arquitecturaSSO basada en el paso de tokens, llamados aquí tickets.
La autentificación vía Kerberos funciona de la siguiente manera:
• El usuario se valida a un servidor de autentificación Kerberos que le devuelve una clave de sesión, es un ticket general de comunicación con el servidor de autentificación.
• Cada vez que el cliente quiere acceder a un recuso, el servidor de autentificación genera un ticket para el recurso determinado.
• El servidor del recurso comprueba que el ticket enviado por el cliente es válido, y permite el acceso.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Kerberos
Soluciones kerberos para los diferentes servicios:
Soluciones SSH y SFTP:
• Secure Shell (Windows, Unix y Linux)• OpenSSH (Unix, Linux y Windows con Cygwin)
Soluciones FTP y Telnet:
• FileZilla (FTP para Windows)• FTP y Telnet del propio KerberosV (UNIX y Linux)• No se encuentran soluciones interesantes de telnet para
Windows.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Kerberos
Soluciones kerberos para los diferentes servicios:
Soluciones Servidores Correo:
• UW IMAP permite autentificación con Kerberos V.• Courier IMAP: mediante PAM• Cyrus IMAP: mediante SASL
Soluciones Clientes Correo:
• Eudora Mail y aparentemente Outlook Express (Windows)• Uso de Evolution (Linux, y UNIX + Gnome)• Posibles problemas en Netscape Mail. Solución: Uso de filtros o
Servicio en lado cliente + Cliente Gráfico de Mail (UNIX, Linux y Windows)
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Kerberos
Soluciones kerberos para los diferentes servicios:
Soluciones Web (webmail y racó)
• PubCookie: permite SSO extendiendo cualquier tipo de autentificación, pero hace falta generar la cookie al entrar.
• Módulos Kerberos para Apache.
• En Web existen múltiples soluciones que deben ser estudiadas y probadas antes de elegir una, que se adapte fácilmente al resto del sistema SSO.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - Kerberos
Riesgos de seguridad en Kerberos:
Los problemas con claves de usuario sencilla se mantienen (prueba y error, fuerza bruta ..)
Tampoco nos protege de ataques debidos a troyanos, como por ejemplo una pagina de login falsa que captura lo que introducimos en ella
Potencialmente es posible llegar a conseguir la clave que esta siendo usada y utilizarla, aunque solo nos será útil durante el tiempo de sesión (en nuestro caso esto sería difícil)
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - PKI
PKI: Certificados digitales
Este método de autentificación esta basado enla arquitectura SSO con certificados digitales (PKI).
La autentificación mediante PKI funciona de la siguiente forma:
• El usuario ha de tener un certificado digital formado por una clave privada, otra clave publica y información de la autoridad certificación y del propio usuario.
• Cada vez que un cliente quiere acceder a un recurso, el servidor solicita la autentificación mediante certificados. Para ello ha de confiar en la autoridad certificadora que emite el certificado.
• El servidor del recurso comprueba que la credencial (certificado) del cliente es válido, y permite el acceso.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - PKI
Soluciones PKI para los diferentes servicios:
Soluciones SSH y SFTP:
• Secure Shell (Windows, Unix y Linux)• OpenSSH (Unix , Linux, Windows con Cygwin)
Soluciones FTP:
• GSIFtp (UNIX, Linux y Windows, es un cliente java)
Soluciones Telnet:
• No hemos encontrado soluciones que se autentifiquen mediante certificados.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - PKI
Soluciones PKI para los diferentes servicios:
Soluciones de Correo:
• Indicar al servidor IMAP que use una autentificación externa (mediante PAM o SASL).
• Creación de un Servicio en el lado del cliente
Soluciones Web (webmail y racó)
• PubCookie: permite SSO extendiendo cualquier tipo de autentificación, pero hace falta generar la cookie al entrar.
• Navegadores como Netscape, Internet Explorer, Mozilla,… permiten utilizar la autentificación mediante certificados.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Implantación - PKI
Riesgos de seguridad en PKI:
Soluciones de Correo:
• Indicar al servidor IMAP que use una autentificación externa (mediante PAM o SASL).
• Creación de un Servicio en el lado del cliente
Soluciones Web (webmail y racó)
• PubCookie: permite SSO extendiendo cualquier tipo de autentificación, pero hace falta generar la cookie al entrar.
• Navegadores como Netscape, Internet Explorer, Mozilla,… permiten utilizar la autentificación mediante certificados.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Contenido de la presentación
¿Qué es Single Sign-On (SSO)?
Arquitecturas para un sistema SSO
Situación actual en la Facultat d’Informàtica de Barcelona
Conclusiones
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Conclusiones
La implementación / implantación de un sistema SSO siempre es más compleja de lo que uno piensa inicialmente.
Analizar qué arquitectura encaja mejor en nuestro entorno.
Hay que realizar un análisis de requerimientos que nos marque claramente unos objetivos:
Implementar el sistema de forma progresiva, por fases.
FA
CU
LT
AT
D’IN
FO
RM
ÀT
ICA
DE
BA
RC
EL
ON
A
Conclusiones
Facilidad de uso y seguridad son características normalmente contrapuestas:
Hay que tener una atención especial en este aspecto
No hay ningún producto que lo contemple todo:
Existen muchas maneras diferentes de hacer una cosa, hay que buscar la combinación que resulte mejor en cada caso