El concepto Single Sign On

El concepto de Single Sign-On se refiere al acceso a múltiples recursos por medio de un único proceso de ingreso. Gran cantidad de las arquitecturas implementadas en diferentes organizaciones han sido diseñadas con el objeto de dar acceso a los usuarios a múltiples servicios Web y/o aplicaciones. En la mayoría de los casos se encuentra que cada uno de los servicios o aplicaciones cuenta con su propio componente de seguridad, lo cual generalmente compromete la seguridad de todo el sistema, dado que el nivel de seguridad de todo un sistema es igual al nivel de seguridad del componente más inseguro que lo compone.

Tipos de Single Sign On

Hay cinco tipos principales de SSO, también se los llama reduced sign on systems (en inglés, sistemas de autenticación reducida).

• Enterprise single sign-on (E-SSO): también llamado legacy single sign-on, funciona luego de una autenticación primaria, interceptando los requerimientos de login presentados por las aplicaciones secundarias para completar los mismos con el usuario y contraseña. Los sistemas E-SSO permiten interactuar con sistemas que pueden deshabilitar la presentación de la pantalla de login.
• Web single sign-on (Web-SSO): también llamado Web access management (Web-AM) trabaja sólo con aplicaciones y recursos accedidos vía web. Los accesos son interceptados con la ayuda de un servidor proxy o de un componente instalado en el servidor web destino. Los usuarios no autenticados que tratan de acceder son redirigidos a un servidor de autenticación y regresan solo después de haber logrado un acceso exitoso. Se utilizan cookies, para reconocer aquellos usuarios que acceden y su estado de autenticación.
• Kerberos: es un método popular de externalizar la autenticación de los usuarios. Los usuarios se registran en el servidor Kerberos y reciben un ticket, luego los clientes de acceso lo presentan para obtener acceso.
• Federation: es una nueva manera de concebir este tema, también para aplicaciones Web. Utiliza protocolos basados en estándares para habilitar que las aplicaciones puedan identificar los clientes sin necesidad de autenticación redundante.
• OpenID: es un proceso de SSO distribuido y descentralizado donde la identidad se compila en una url que cualquier aplicación o servidor puede verificar.

Arquitecturas Single Sign On

Existen diferentes tipos de arquitecturas que permiten implementar SSO. Cada una de ellas posee características que la hace más apropiada para algún tipo de organización. La decisión de adoptar una u otra arquitectura básicamente depende de los recursos computacionales y/o económicos disponibles, y las decisiones de diseño establecidas por el equipo del proyecto.
Las diferentes arquitecturas SSO están compuestas por tres componentes básicos:

• Interface: El modo en que el SSO interactúa con una determinada aplicación. Usualmente reside en el cliente, y es conocido como Agente SSO.
• Administración: El mecanismo que permite configurar, mantener y monitorear el proceso de SSO.
• Credenciales: Cada aplicación a la que se accede requiere información confidencial (nombre de usuario, contraseña, etc.), que agrupada recibe el nombre de credenciales. Las credenciales deben almacenarse de manera protegida para que sea únicamente el agente SSO quien pueda acceder a ellas.

Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página.

Son muchas las empresas que deciden pasar sus aplicaciones a la arquitectura modelo vista controlador para documentar más fácilmente el código, ahorrar espacio y en caso de no disponer de diseñadores web, poder contratar los servicios de un diseñador que no sepa mucho de programación que les haga las vistas.

El Modelo es todo acceso a datos, y las funciones que llevan lo que llaman “lógica de negocio”, o sea datos y reglas de negocio. Lleva un registro de las vistas y controladores del sistema. Cada acceso a datos se pone en su función individual porque, de esta forma, si se cambia de gestor de bases de datos este cambio sólo afecta a estas funciones, no al resto de la aplicación. Tener el modelo bien delimitado permite la existencia de varias aplicaciones que compartan el mismo modelo (por ejemplo, una aplicación “tienda” y una “contabilidad” que accedan a las bases de datos de inventario, ventas, etc.).

La Vista, en una aplicación web, es el HTML y lo necesario para convertir datos en HTML. O sea muestra la información del modelo al usuario. Tienen un registro de su controlador asociado (normalmente porque además lo instancia).

Pueden dar el servicio de “Actualización()”, para que sea invocado por el controlador o por el modelo. Tener la vista separada del controlador permite cambiar la aplicación para que genere, en lugar de HTML, algo distinto (por ejemplo, WML), sin tener que tocar más que una parte completamente delimitada del código.

El Controlador es lo que une la vista y el modelo. Por ejemplo, son las funciones que toman los valores de un formulario, consultan la base de datos (a través del modelo) y producen valores, que la vista tomará y convertirá en HTML. En resumen, gestiona las entradas del usuario. Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). Contiene reglas de gestión de eventos, del tipo “SI Evento Z, entonces Acción W”. Estas acciones pueden suponer peticiones al modelo o a las vistas. De este modo, el código que “hace algo” está perfectamente separado del código dedicado a crear HTML, lo que ayuda a evitar el spaghetti.

Un patrón es un modelo que podemos seguir para realizar algo. Los patrones surgen de la experiencia de seres humanos de tratar de lograr ciertos objetivos. Los patrones capturan la experiencia existente y probada para promover buenas prácticas.

Los Patrones de Diseño (Design Patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Estos se dividen en tres grandes categorías:

• Patrones Creacionales

Solucionan problemas de creación de instancias. Nos ayudan a encapsular y abstraer dicha creación.

• Patrones Estructurales

Solucionan problemas de composición (agregación) de clases y objetos.

• Patrones de Comportamiento

Soluciones respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos que encapsulan

Un patrón de diseño es:

·   una solución estándar para un problema común de programación

·   una técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios

·   un proyecto o estructura de implementación que logra una finalidad determinada

·   un lenguaje de programación de alto nivel

·   una manera más práctica de describir ciertos aspectos de la organización de un programa

·   conexiones entre componentes de programas

·   la forma de un diagrama de objeto o de un modelo de objeto

Los patrones de diseño han contribuido a dar flexibilidad y extensibilidad a nuestros diseños. Pero en adición, han demostrado ser una forma muy útil (exitosa) de reutilizar diseño, ya que ellos no sólo nombran, abstraen e identifican aspectos claves de estructuras comunes de diseño, sino que generalmente son descritos en una forma específica documental, haciendo su comprensión y aplicación fácil para el conjunto de desarrolladores.Podemos decir que los beneficios que un patrón produce pueden ser medidos en varios sentidos:

• Contribuyen a reutilizar diseño, identificando aspectos claves de la estructura de un diseño que puede ser aplicado en una gran cantidad de situaciones. La importancia de la reutilización del diseño no es despreciable, ya que ésta nos provee de numerosas ventajas: reduce los esfuerzos de desarrollo y mantenimiento, mejora la seguridad, eficiencia y consistencia de nuestros diseños, y nos proporciona un considerable ahorro en la inversión.
• Mejoran (aumentan, elevan) la flexibilidad, modularidad y extensibilidad, factores internos e íntimamente relacionados con la calidad percibida por el usuario.
• Incrementan nuestro vocabulario de diseño, ayudándonos a diseñar desde un mayor nivel de abstracción.

La arquitectura Cliente/Servidor es la integración distribuida de un sistema en red, con los recursos, medios y aplicaciones que, definidos modularmente en los servidores, administran, ejecutan y atienden las solicitudes de los clientes; todos interrelacionados física y lógicamente, compartiendo datos, procesos e información. Se establece así un enlace de comunicación transparente entre los elementos que conforman la estructura. Entre las principales características de la arquitectura Cliente/Servidor, se pueden destacar las siguientes:

• El servidor presenta a todos sus clientes una interfaz única y bien definida.
• El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa.
• El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo.
• Los cambios en el servidor implican pocos o ningún cambio en el cliente.

Ventajas de la arquitectura cliente-servidor:

- Se reduce el tráfico de red considerablemente. Idealmente, el cliente se conecta al servidor cuando es estrictamente necesario, obtiene los datos que necesita y cierra la conexión dejando la red libre.

Las arquitecturas de dos capas contienen tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios).

Los tres componentes son:

1. Interfaz de usuario al sistema. Tales como una sesión, entradas de texto, desplegado de menús, etc.

2. Administración de procesamiento. Tales como la ejecución de procesos, el monitoreado de los mismos y servicios de procesamiento de recursos.

3. Administración de bases de datos. Tales como los servicios de acceso a datos y archivos.

La arquitectura de software de tres capas emergió en la década de los noventas para solventar las limitaciones de la arquitectura de dos capas. La tercera capa (capa de servicios) se localiza entre la interfaz de usuarios (cliente) y el administrador de datos (servidor). Esta capa intermedia provee de servicios para la administración de procesos (tal como desarrollo, monitoreo y alimentación de procesos) que son compartidos por múltiples aplicaciones.

El servidor de la capa intermedia (también conocido como servidor de aplicaciones) centraliza la lógica de las aplicaciones, haciendo que la administración de cambios sea más sencilla. En arquitecturas más simples, cualquier cambio en la lógica, implica reescribir todas las aplicaciones que dependan de ésta.

¿Qué es un servicio web?

Un Servicio Web es una colección de protocolos y estándares que sirve para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, soportando así la interoperabilidad máquina - máquina (interoperabilidad sintáctica) y el intercambio de datos entre redes de ordenadores.
Esta interoperabilidad se consigue mediante la adopción de estándares abiertos.

Estándares empleados

• Web Services Protocol Stack: Es el conjunto de servicios y protocolos de los Servicios Web.
• XML: Es el formato estándar usado para los datos que se vayan a ser intercambiados.
• SOAP o XML-RPC: Protocolos sobre los que se establece el intercambio.
• Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos normales como HTTP, FTP, o SMTP.
• WSDL: Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de cómo debe establecerse la comunicación de los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.
• UDDI: Protocolo para publicar la información de los servicios Web. Permite a las aplicaciones comprobar qué servicios web están disponibles.
• WS-Security: Protocolo de seguridad aceptado como estándar por OASIS. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

Pero, ¿qué es NuSOAP?

NuSOAP es una reescritura de SOAPx4, provista por NuSphere y Dietrich Ayala. Es un conjunto de clases (no se requiere ninguna extensión de PHP) que permiten a los desarrolladores crear y consumir servicios web basados en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1.
La instalación es bastante sencilla, sólo basta con ir a la página en sourceforge de NuSOAP http://sourceforge.net/projects/nusoap/ y bajar el archivo comprimido. Lo descomprimimos en un directorio de nuestro servidor web (como puede ser “nusoap”), y listo, ya podemos hacer uso de NuSOAP.

¿Cómo lo usamos?

Para responder a esto, lo ideal sería realizar un ejemplo donde utilicemos NuSOAP, lo cual nos permitirá terminar de entender bien los conceptos relaciones con los Servicios Web. Primeramente partiremos de la idea de crear un servicio web, y posteriormente consumir el mismo.
El ejemplo que mostraremos es una aplicación simple, que me permita emitir un saludo a una persona indicada. Para crear este Servicio Web (server.php) con PHP usando NuSOAP es de la siguiente manera:

Con este código hemos creado un Servicio Web, que al ser invocado saluda a una persona indicada, ahora debemos crear una aplicación que consuma este Servicio Web (client.php).

Y de esta forma, hemos creado una aplicación sencilla de creación y consumo de un Servicio Web en PHP, para mostrar ver su funcionamiento pueden hacerlo en http://dev.deepinphp.com/ejemplos/webservices/client.php

Conclusiones

Los Servicios Web pueden ser muy útiles en ciertos casos concretos de programación. Los expertos de marketing de empresas de software como Microsoft anuncian a bombo y platillo una revolución debido a la aparición de SOAP, WSDL, UDDI, etc. Sin embargo, no conviene creerse todo lo que cuentan. Hay que tener en cuenta que les interesa que sus clientes actualicen sus herramientas de desarrollo a la versión .NET
La única revolución que podemos vivir en relación a los Servicios Web es la de ver como los servidores de Internet hablan entre ellos, y cada día son más independientes del programador. Y eso es algo que va a pasar completamente desapercibido para el resto de los usuarios de Internet.
Si logramos que existan Servicios Web de utilidad, gratuitos y sencillos, este nuevo esquema de comunicación y programación tendrá futuro. Si por el contrario, montamos campañas comerciales y vendemos fantasías en torno a palabras bonitas e incomprensibles como UDDI, WSDL, SOAP, XML, etc, habremos perdido nuestro valioso tiempo.

Archivos de ejemplo

Puede descargar los archivos del ejemplo anterior en http://dev.deepinphp.com/ejemplos/webservices/ejemplo.zip (Incluye la clase NuSoap)

Actualizado: 3 de noviembre del 2008

Beneficios de la compresión
La compresión nos posibilita almacenar mayor cantidad de ficheros dentro de nuestros discos duros, muy útil a la hora de realizar los resguardos de la información. Reduce nuestro tiempo de descarga de ficheros en la red y disminuye el tráfico en las mismas.

¿Qué es Bzip2?
Bzip2 es un gran algoritmo de alta calidad de compresión de datos.
Generalmente hace que los ficheros comprimidos sean entre un 10 y 15 por ciento más pequeños que las mejores técnicas disponibles de compresión. Su patente es libre por lo cual bzip2 esta disponible gratuitamente al igual que su código fuente para el uso de todo el mundo. El sitio oficial se encuentra en http://www.bzip.org y su código puede ser descargado desde la siguiente dirección http://www.bzip.org/downloads.html.
Las funciones bzip2 son usadas en PHP para leer y escribir de forma transparente, ficheros comprimidos bzip2 (.bz2), en nuestro caso solo trataremos con ellas para comprimir y descomprimir ficheros bzip2.

Configurando el php.ini
El soporte para bzip2 en PHP no está habilitado por defecto por lo tanto tendremos que habilitar la opción en el fichero de configuración del php (php.ini). Este se hace eliminando el punto y coma que se encuentra delante de la línea extension=php_bz2.so.

Comprimiendo el fichero
Supongamos que en la variable $archivo_name tenemos guardado el nombre de nuestro fichero a compactar. El siguiente código es el encargado de comprimir el fichero.

Descomprimiendo el fichero
Ahora bien, en este caso supongamos que tenemos en la variable $archivo_fuente el nombre de nuestro fichero comprimido y que en la variable $archivo_destino esta el nombre que deseamos tenga el fichero cuando se descomprima. El siguiente código es el encargado de descomprimir nuestro fichero.bz2

Si experimentas problemas a la hora de leer y escribir a ficheros y estas usando la versión de PHP como módulo para el servidor, recuerda que debes asegurar que los ficheros y directorios que estas usando son accesibles al proceso servidor.