Autenticacion unica

521 views
486 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
521
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Autenticacion unica

  1. 1. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTECATEDRA: PROTOCOLOS DE COMUNICACIÓNDOCENTE: ING. JUAN CARLOS PEÑA MORANALUMNOS: MARROQUIN PANIAGUA KENNY GUADALUPE PALACIOS PACHECO JOSE DAMIAN SALINAS RODRIGUEZ ARTURO ERNESTO SANTA ANA 25 DE JUNIO 2012
  2. 2. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 INDICEIntroducción……………………………………………………………………………………………………………………. 3Diagrama………………………………………………………………………………………………………………………….. 4Configuracion de Heartbeat para dar soporte de alta disponibilidad………………………………… 5Codificación de aplicaciones …………………………………………………………………………………………….. 7Instalación y configuración de apache2…………………………………………………………………………….. 11Instalación de Servidor Tomcat6……………………………………………………………………………………….. 14Instalación de monitor de desempeño para Servers Apache……………………………………………… 15PROTOCOLOS DE COMUNICACION Página 2
  3. 3. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 INTRODUCCIONEl presente documento contiene los pasos necesarios para el montaje de un escenario quecontiene 2 Servidores HTTP(Apache2, Tomcat6), 2 Servers LDAP (Máster, Respaldo) para elalmacenaje de credenciales de los usuarios (user, password), donde el Master es el server defaultpara loguearse desde las aplicaciones alojadas en los servers Apache2 y Tomcat6, si el Master seve afectado por algún circunstancia como por ejemplo se desconectó el cable, se quedó sinenergía eléctrica, etc, el Server de Respaldo entra a funcionar de manera transparente en lasaplicacions php y java, manteniendo la misma dirección IP del Server Master, con esto se logra unescenario con soporte de alta disponibilidad . Además se cuenta con 1 Balanceador de carga parapeticiones HTTP de Apache2.El tema principal de este documento radica en la implementación de un sistema Single Sing One(SSO) el cual consiste en que si se tienen varias aplicaciones dentro del mismo dominio (ya sea enel mismo servidor físico o no) el usuario que se loguea en una de las aplicaciones debe quedarlogueado para todo el dominio, es decir si se loguea en una aplicación y luego abre una nuevapestaña en el navegador e introduce la Url del loguin de otro sitio(perteneciente al mismo dominiopor supuesto) la aplicación debe ser capaz de saber si el usuario ya esta logueado o no, en caso deestar logueado el usuario será redireccionado a la pantalla principal de la aplicación que estasolicitando sin introducir su usuario y contraseña nuevamente, este mecanismo se esta volviendouna necesidad debido a que los usuarios muchas veces manejan usuarios y password diferentes encada aplicación creando un gran reto para los usuarios de recordar muchos usuarios ycontraseñas.El mecanismo SSO brinda la posibilidad al usuario de manejar credenciales únicas para todas lasaplicaciones que utiliza, evitando además la carga en los servidores HTTP y LDAP para laspeticiones de logueo, manejando únicamente las sesiones concernientes a la funcionalidadprincipal de las aplicaciones.El mecanismo en el cual se basa este documento para lograr el SSO, son las cookies, las cuales a lahora de crearse se hacen explícitamente visibles en todo el dominio (protocolos.xxx).El primer paso es crear las pantallas de login en las aplicaciones desplegadas en Apache2 yTomcat6, los cuales en su etiqueta <form></form> contendrán el action que será el encargado detomar los datos ingresados por el usuario(user,password) y compararlos contra sus credencialesalmacenadas en el server LDAP, si la comparación es exitosa se crea la sesión y las cookies en lascuales se almacenara el nickname ingresado por el usuario. Además de esto hay que tomar encuenta,que a la hora de ingresar al loguin hay que verificar si existe o no la cookie que contiene elnickname, en caso de existir dicha cookie entonces el usuario se saltará la pantalla de loginingresando automáticamente a la pantalla principal de la aplicación, además en todas las pantallaspertenecientes a las aplicaciones a la hora de ser requeridas tienen que asegurarse de que lacookie existe en caso de existir permitir el acceso, caso contrario se redireccionara a la pantalla delogueo.PROTOCOLOS DE COMUNICACION Página 3
  4. 4. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 DIAGRAMAPara tener una mejor panorámica proporcionamos el diagrama de conexión y disposición delsistema de servidores:La imagen muestra que los Servers Apache y Tomcat usan como repositorio de datos unadirección IP virtual la cual es soportada por el server Master(Arturo) que en caso de caerse elserver de respaldo entra a funcionar manteniendo la misma Ip del Maester, esto es gracias aHeartbeat con lo que podemos brindar un sistema de alta disponibilidad.Este How To está basado en pcs con S.O Linux Debian 6 (Squeeze).PROTOCOLOS DE COMUNICACION Página 4
  5. 5. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012CONFIGURACION DE HEARTBEAT PARA DAR SOPORTE DE ALTADISPONIBILIDAD A NUESTROS SERVER LDAPPartiendo del supuesto en que ya se tiene instalado y configurado Ldap en los 2 servers con unárbol como el siguiente:  El primer paso para la configuración de nuestro servicio de alta disponibilidad es instalar el paquete Heartbeat: #apt - get install heartbeatUna vez instalado nos cercioramos de que se creó el directorio /etc/ha.d/  Seguidamente procedemos a crear el siguiente archivo (en los servidores ldap) /etc/ha.d/ha.cf el cual contendrá lo siguiente:PROTOCOLOS DE COMUNICACION Página 5
  6. 6. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012  bcast eth0: Interfaz de red donde se levantará heartbeat  keepalive 2: Envía pings cada 2 segundos al otro nodo  deadtime 10: Tras 10 segundos sin recibir respuesta del otro nodo, se considera como muerto  crear el archivo /etc/ha.d/authkeys (en ambos servers) el cual contendrá lo siguiente:  crear el archivo /etc/ha.d/haresources (en ambos servers) el cual contendrá lo siguiente:El cual tiene definido el nombre del server que actuara como master seguido de la ip que serácompartida por ambos server además de la interfaz por la se saldrá al exterior con dicha ip ademásse especifica el servicio que se estará soportando en esa ip para nuestro caso es slapd.  Debe reiniciar heartbeat #/etc/init.d/heartbeat restartA manera de prueba , ingresar a jxplorer (cliente grafico para arboles ldap, su instalación es muysencilla: $apt-get install jxplorer) y en server coloque la ip 192.168.1.25 (ip definida en losarchivos de configuración heartbeat) ejecute ldap en modo debug ($slapd –d 16383)en el serverque se definió como máster en heartbeat(Arturo) podrá notar que a la hora de acceder a Jxplorer,el log se mueve , mientras que el log del server de respaldo permanece estático, seguidodesconecte de la red o apague el server principal y vuelva a ingresar a Jxplorer con la misma ip(192.168.1.25) y vera que el acceso se mantiene ya que esta siendo soportado por el server derespaldo.Con esto ya tenemos configurado nuestro servicio de alta disponibilidad para nuestros serversLDAP.PROTOCOLOS DE COMUNICACION Página 6
  7. 7. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 CODIFICACION DE APLICACIONESAhora procedemos a la codificación de las aplicaciones que serán objeto del SSO en nuestrodominio, comenzaremos por la aplicación desarrollada en Php para ser subida a nuestro serverapache2.  crear un formulario de logueo conteniendo un textbox para usuario y otro para contraseña y un botón para el envio de datos.  Escribir nuestro archivo procesar.php en el cual se recuperaran las credenciales proporcionadas por el usuario (user,pass) y será este el encargado de confrontarlo con el server LDAP(que esta escuchando en la ip 192.168.1.25 gracias a HeartBeat). Dicho archivo tiene que lucir de la siguiente manera:PROTOCOLOS DE COMUNICACION Página 7
  8. 8. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012Como se puede notar en $ldap[‘host’] definimos la ip donde esta alojado nuestro servicio LDAP,definimos el puerto y el árbol en donde se desea hacer la búsqueda de nuestros usuarios.Si existe el usuario y las credenciales son correctas ($ldap[‘bind’]) entonces se procederá a lacreación de un cookie que será visible para todo el dominio .protocolos.xxx y redireccionará aasegurada.php que será una fake page para simular la principal de una aplicación. Caso contrarioserá redirigido a la pantalla de logueo para proporcionar nuevamente las credenciales.Ahora regresamos a la pantalla login.php y hay que agregar el siguiente código para preguntar siexiste la cookie a la hora de ingresar al login, en caso de ser verdadero pues redirecciona a laprincipal de la aplicación, caso contrario pues carga la pantalla login.PROTOCOLOS DE COMUNICACION Página 8
  9. 9. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012Seguido nos disponemos a la codificación de nuestra aplicación Java, la cual será alojada en unserver tomcat6, para ello creamos un archivo llamado index.jsp en el cual se contendrán 2textobos (user y pass) y un botón de acción para ejecutar la búsqueda, quedando de la siguientemanera:Luego codificamos en el archivo test.jsp el cual contedra las siguientes definiciones:PROTOCOLOS DE COMUNICACION Página 9
  10. 10. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012Dicho archivo hace referencia a una clase llamada conexión en el cual será el que soportara ellogueo de la aplicación en LDAP, dicha clase debe lucir de la siguiente manera:La ip del server hace referencia a la ip que se ha definido en heartbeat. De igual forma que en phpsi el usuario existe y coincide con su contraseña creara la cookie y el usuario será redirigido a laprincipal de la aplicación.Por ultimo falta activar el sso en nuestra pantalla de login, para ello será necesario codificar losiguiente en dicha vista:PROTOCOLOS DE COMUNICACION Página 10
  11. 11. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 INSTALACION Y CONFIGURACION DE APACHE2Instalar en el server que dará soporte al balance de carga y también hay que instalarlo en los 2equipos que serán los servidores HTTP como tal, para ello instalamos los siguientes paquetes: #apt-get install apache2 apache2-prefork-dev apache2.2-common apache2 utilsUna vez instalado procedemos a la configuracion del server de carga (192.168.1.3) configuramos el archivo /etc/apache2/ports.conf .Quedando de la siguiente manera, en el cual estamos especificando que se tendrá un sitio alojadoen esa ip por medio del puerto 80. crear un archivo dentro de la carpeta /etc/apache2/sites-available. Este archivo deberá contener el nombre de PhpApp: #nano /etc/apache2/sites-avalable/PhpAppPROTOCOLOS DE COMUNICACION Página 11
  12. 12. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012Ahora hay que codificar de forma que luzca de la siguiente manera:Una vez terminado el archivo PhpApp hay que desmontar el sitio default que vienen en lainstalación de Apache2 y luego dar de alta al sitio que será manejado por el archivo PhpApp,además hay que dar de alta a algunos módulos necesarios para el balance de carga y por ultimoreiniciar nuestro apache2: #a2dissite deafult #a2ensite PhpApp #a2enmod proxy_balancer #a2enmod proxy #a2enmod proxy_http #/etc/init.d/apache2 restartCon esto tenemos listo nuestro server que será el encargado de balancear la carga en los serversapche2.PROTOCOLOS DE COMUNICACION Página 12
  13. 13. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 configuración de los servidores apache2 (192.168.1.4,192.168.1.5) Para la configuración llamaremos balancer1 al sitio montado en el primer server y balancer2 alsegundo server, para ello simplemente hay que crear un archivo en /etc/apache2/sites-availabledenominado balancerx (x representa el numero del server), quedando de la siguiente manera:El contenido del archivo es el mismo para ambos servidores con la única diferencia es en ladefinición de la Ip y probablemente la ubicación del directorio del sitio, luego de eso nos situamosen el archivo /etc/apache2/ports.conf (en ambos servidores) en el cual solo variamos la ip paracada server.PROTOCOLOS DE COMUNICACION Página 13
  14. 14. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012Ahora solo falta reiniciar nuestro servicio apache en los 2 servers #/etc/init.d/apache2 restartYa que las aplicaciones que han sido alojadas en apache2 están escritas en Php se nos hacenecesaria la instalación de los paquetes #apt-get install php5 libapache-mod-php5 INSTALACION DE SERVIDOR TOMCAT6La instalación de este servidor es sumamente sencillo solo basta con instalarlo desde elrepositorio: #apt-get install tomcat6 tomcat6-adminPara comprobar que el servicio ha sido instalado vamos al navegador y digitamos la siguiente urlhttp://localhost:8080 y nos deberá aparecer una patalla similar a la siguiente:PROTOCOLOS DE COMUNICACION Página 14
  15. 15. UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012 INSTALAR MONITOR PARA APACHE2Existe un monitor muy bueno para el monitorear el rendimiento de nuestro servidor para elloinstalamos el siguiente paquete: #apt-get install apachetopPara ejecutarlo basta con escribir lo siguiente: #apachetop –f /var/log/apache2/acces.logY nos mostrara una ventana similar a la siguiente:El cual es un resumen del total de peticiones atendías y los últimos archivos solicitados…PROTOCOLOS DE COMUNICACION Página 15

×