autenticacion unica

UNIVERSIDAD DE EL SALVADOR

FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE

CCAATTEEDDRRAA::

PPRROOTTOOCCOOLLOOSS DDEE CCOOMMUUNNIICCAACCIIÓÓNN

DDOOCCEENNTTEE::

IINNGG.. JJUUAANN CCAARRLLOOSS PPEEÑÑAA MMOORRAANN

AALLUUMMNNOOSS::

MMAARRRROOQQUUIINN PPAANNIIAAGGUUAA KKEENNNNYY GGUUAADDAALLUUPPEE

PPAALLAACCIIOOSS PPAACCHHEECCOO JJOOSSEE DDAAMMIIAANN

SSAALLIINNAASS RROODDRRIIGGUUEEZZ AARRTTUURROO EERRNNEESSTTOO

SSAANNTTAA AANNAA 2255 DDEE JJUUNNIIOO 22001122

UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE 2012

PROTOCOLOS DE COMUNICACION Página 2

INDICE

Introducción……………………………………………………………………………………………………………………. 3

Diagrama…………………………………………………………………………………………………………………………..

4

Configuracion de Heartbeat para dar soporte de alta disponibilidad………………………………… 5

Codificación de aplicaciones …………………………………………………………………………………………….. 7

Instalación y configuración de apache2……………………………………………………………………………..

11

Instalación de Servidor Tomcat6………………………………………………………………………………………..

14

Instalación de monitor de desempeño para Servers Apache……………………………………………… 15



INTRODUCCION El presente documento contiene los pasos necesarios para el montaje de un escenario que

contiene 2 Servidores HTTP(Apache2, Tomcat6), 2 Servers LDAP (Máster, Respaldo) para el

almacenaje de credenciales de los usuarios (user, password), donde el Master es el server default

para loguearse desde las aplicaciones alojadas en los servers Apache2 y Tomcat6, si el Master se

ve afectado por algún circunstancia como por ejemplo se desconectó el cable, se quedó sin

energía eléctrica, etc, el Server de Respaldo entra a funcionar de manera transparente en las

aplicacions php y java, manteniendo la misma dirección IP del Server Master, con esto se logra un

escenario con soporte de alta disponibilidad . Además se cuenta con 1 Balanceador de carga para

peticiones 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 en

el mismo servidor físico o no) el usuario que se loguea en una de las aplicaciones debe quedar

logueado para todo el dominio, es decir si se loguea en una aplicación y luego abre una nueva

pestaña en el navegador e introduce la Url del loguin de otro sitio(perteneciente al mismo dominio

por supuesto) la aplicación debe ser capaz de saber si el usuario ya esta logueado o no, en caso de

estar logueado el usuario será redireccionado a la pantalla principal de la aplicación que esta

solicitando sin introducir su usuario y contraseña nuevamente, este mecanismo se esta volviendo

una necesidad debido a que los usuarios muchas veces manejan usuarios y password diferentes en

cada aplicación creando un gran reto para los usuarios de recordar muchos usuarios y

contraseñas.

El mecanismo SSO brinda la posibilidad al usuario de manejar credenciales únicas para todas las

aplicaciones que utiliza, evitando además la carga en los servidores HTTP y LDAP para las

peticiones de logueo, manejando únicamente las sesiones concernientes a la funcionalidad

principal de las aplicaciones.

El mecanismo en el cual se basa este documento para lograr el SSO, son las cookies, las cuales a la

hora 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 y

Tomcat6, los cuales en su etiqueta <form></form> contendrán el action que será el encargado de

tomar los datos ingresados por el usuario(user,password) y compararlos contra sus credenciales

almacenadas en el server LDAP, si la comparación es exitosa se crea la sesión y las cookies en las

cuales se almacenara el nickname ingresado por el usuario. Además de esto hay que tomar en

cuenta,que a la hora de ingresar al loguin hay que verificar si existe o no la cookie que contiene el

nickname, en caso de existir dicha cookie entonces el usuario se saltará la pantalla de login

ingresando automáticamente a la pantalla principal de la aplicación, además en todas las pantallas

pertenecientes a las aplicaciones a la hora de ser requeridas tienen que asegurarse de que la

cookie existe en caso de existir permitir el acceso, caso contrario se redireccionara a la pantalla de

logueo.



DIAGRAMA Para tener una mejor panorámica proporcionamos el diagrama de conexión y disposición del

sistema de servidores:

La imagen muestra que los Servers Apache y Tomcat usan como repositorio de datos una

dirección IP virtual la cual es soportada por el server Master(Arturo) que en caso de caerse el

server de respaldo entra a funcionar manteniendo la misma Ip del Maester, esto es gracias a

Heartbeat con lo que podemos brindar un sistema de alta disponibilidad.

Este How To está basado en pcs con S.O Linux Debian 6 (Squeeze).



CONFIGURACION DE HEARTBEAT PARA DAR SOPORTE DE ALTA

DISPONIBILIDAD A NUESTROS SERVER LDAP

Partiendo 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 heartbeat

Una 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:



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ás

se especifica el servicio que se estará soportando en esa ip para nuestro caso es slapd.

Debe reiniciar heartbeat

#/etc/init.d/heartbeat restart

A manera de prueba , ingresar a jxplorer (cliente grafico para arboles ldap, su instalación es muy

sencilla: $apt-get install jxplorer) y en server coloque la ip 192.168.1.25 (ip definida en los

archivos de configuración heartbeat) ejecute ldap en modo debug ($slapd –d 16383)en el server

que 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, seguido

desconecte 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 de

respaldo.

Con esto ya tenemos configurado nuestro servicio de alta disponibilidad para nuestros servers

LDAP.



CODIFICACION DE APLICACIONES Ahora procedemos a la codificación de las aplicaciones que serán objeto del SSO en nuestro

dominio, comenzaremos por la aplicación desarrollada en Php para ser subida a nuestro server

apache2.

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:



Como 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 la

creación de un cookie que será visible para todo el dominio .protocolos.xxx y redireccionará a

asegurada.php que será una fake page para simular la principal de una aplicación. Caso contrario

será 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 si

existe la cookie a la hora de ingresar al login, en caso de ser verdadero pues redirecciona a la

principal de la aplicación, caso contrario pues carga la pantalla login.



Seguido nos disponemos a la codificación de nuestra aplicación Java, la cual será alojada en un

server tomcat6, para ello creamos un archivo llamado index.jsp en el cual se contendrán 2

textobos (user y pass) y un botón de acción para ejecutar la búsqueda, quedando de la siguiente

manera:

Luego codificamos en el archivo test.jsp el cual contedra las siguientes definiciones:



Dicho archivo hace referencia a una clase llamada conexión en el cual será el que soportara el

logueo 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 php

si el usuario existe y coincide con su contraseña creara la cookie y el usuario será redirigido a la

principal de la aplicación.

Por ultimo falta activar el sso en nuestra pantalla de login, para ello será necesario codificar lo

siguiente en dicha vista:



INSTALACION Y CONFIGURACION DE APACHE2

Instalar en el server que dará soporte al balance de carga y también hay que instalarlo en los 2

equipos 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 utils

Una 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 alojado

en 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/PhpApp



Ahora 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 la

instalació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 ultimo

reiniciar nuestro apache2:

#a2dissite deafult

#a2ensite PhpApp

#a2enmod proxy_balancer

#a2enmod proxy

#a2enmod proxy_http

#/etc/init.d/apache2 restart

Con esto tenemos listo nuestro server que será el encargado de balancear la carga en los servers

apche2.



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 al

segundo server, para ello simplemente hay que crear un archivo en /etc/apache2/sites-available

denominado 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 la

definición de la Ip y probablemente la ubicación del directorio del sitio, luego de eso nos situamos

en el archivo /etc/apache2/ports.conf (en ambos servidores) en el cual solo variamos la ip para

cada server.



Ahora solo falta reiniciar nuestro servicio apache en los 2 servers

#/etc/init.d/apache2 restart

Ya que las aplicaciones que han sido alojadas en apache2 están escritas en Php se nos hace

necesaria la instalación de los paquetes

#apt-get install php5 libapache-mod-php5

INSTALACION DE SERVIDOR TOMCAT6

La instalación de este servidor es sumamente sencillo solo basta con instalarlo desde el

repositorio:

#apt-get install tomcat6 tomcat6-admin

Para comprobar que el servicio ha sido instalado vamos al navegador y digitamos la siguiente url

http://localhost:8080 y nos deberá aparecer una patalla similar a la siguiente:

http://localhost:8080/



INSTALAR MONITOR PARA APACHE2 Existe un monitor muy bueno para el monitorear el rendimiento de nuestro servidor para ello

instalamos el siguiente paquete:

#apt-get install apachetop

Para ejecutarlo basta con escribir lo siguiente:

#apachetop –f /var/log/apache2/acces.log

Y nos mostrara una ventana similar a la siguiente:

El cual es un resumen del total de peticiones atendías y los últimos archivos solicitados…

autenticacion unica

Documents