Autenticacion unica

UNIVERSIDAD DE EL SALVADOR

FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE

CATEDRA:

PROTOCOLOS DE COMUNICACIÓN

DOCENTE:

ING. JUAN CARLOS PEÑA MORAN

ALUMNOS:

MARROQUIN PANIAGUA KENNY GUADALUPE

PALACIOS PACHECO JOSE DAMIAN

SALINAS RODRIGUEZ ARTURO ERNESTO

SANTA ANA 25 DE JUNIO 2012

UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA DE OCCIDENTE
2012

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

PROTOCOLOS DE COMUNICACION Página 2

2012
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.


2012
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).


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


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


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


2012

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.


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


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


2012
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


2012
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.


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 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.


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


2012
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

Más contenido relacionado

La actualidad más candente

Similar a Autenticacion unica

Autenticacion unica