Entre los candidatos que más están gustando se encuentra la consigna de la universidad de Sevilla, filesender y owncloud.

Owncloud [...]]]> En la federación de identidades de las universidades públicas andaluzas, Confía se están empezando a evaluar servicios de transferencia y alojamiento de ficheros en la nube.

Entre los candidatos que más están gustando se encuentra la consigna de la universidad de Sevilla, filesender y owncloud.

Owncloud es básicamente una herramienta para alojar ficheros pero tiene muchas mas funcionalidades:

• Seguridad: encriptación de los ficheros, notificaciones ante cambios
• Usabilidad: Versionado, drag & drop, notificaciones ante cambios, visores de documentos y galerias de imagenes.
• Interoperabilidad: Ofrece API para aplicaciones con terceros. Soporte WebDav.
• Funcionalidades de gestión de tareas
• Funcionalidades de agenda de contactos.
• Funcionalidades de calendario.

Otra de las cosas a tener en cuenta es la gran comunidad que tiene detrás, la cual está colaborando muy ágilmente fruto de lo cual el software está evolucionando muy rapidamente.

Por todo ello y puesto que no disponía de soporte para SAML desde Confía se ha hecho esta aportación al proyecto y desde la semana pasada se dispone de acceso federado a la aplicación.

Pantalla de login de owncloud con soporte SAML

Se ha desplegado el servicio owncloud en el entorno de laboratorio de Confía y se tiene acceso a el desde los Proveedores de Identidad de Pre-Producción de las Universidades.

Desde el primer momento este desarrollo ha tenido buena aceptación por los responsables del proyecto, prueba de lo cual su principal desarrollador, Frank Karlitschek, me ha dado permisos de commiter en el repositorio de owncloud para que yo mismo subiera el plugin y lo mantuviese a partir de ahora.

La aplicación para dar soporte SAML a owncloud por tanto se encuentra en el repositorio oficial de owncloud, alojado de gitorious.

Instalación de la aplicación user_saml

Suponiendo que ya tenemos instalada y configurada una instancia SP de simplesamlphp

lo primero que debemos hacer es obtener el código de la aplicación user_saml del repositorio oficial de owncloud. En owncloud lo que normalmente se conoce como “plugin” aquí recibe el nombre de “app”:

    # git clone git@github.com:pitbulk/apps.git

Y copiamos la aplicación concreta en nuestra instancia de owncloud

    # cp -R apps/saml_user/apps/

A continuación accedemos a la interfaz web de administración de owncloud, habilitamos la aplicación de SAML en el panel de aplicaciones.

Configuración

Accedemos al panel de administración y nos vamos a la sección de la Aplicación de SAML donde debemos configurar una serie de parámentros.

En la pestaña “Básica” podemos configurar:

• Parámetros relacionados con simpleSAMLphp como su ruta y la fuente SP habilitada en el authsources con la que queremos autenticar.
• La posibilidad de habilitar la provisión automática y si queremos que los datos se actualicen tras cada login vía SAML.
• La posibilidad de definir una serie de grupos internos de owncloud que no serán modicados por la aplicación SAML.
• La posibilidad de indicar un grupo por defecto al que será asociado el usuario en caso de que no se encuentren datos sobre el grupo al que pertenece en la aserción SAML.

Panel de configuración básica del plugin SAML de ownCloud

En la pestaña de “Mapeo” se debe configurar en que atributos de la aserción SAML se espera encontrar el nombre de usuario, su email y la información de su grupo.

Panel de configuración de los mapeos para el plugin SAML de ownCloud

Funcionamiento y Uso.

Cuando habilitamos la aplicación SAML nos aparecerá un enlace debajo del formulario del login. Al pulsar en el nos reenviará al Proveedor de Identidad que venga configurado en el SP.

Si está habilitado la “autocreación del usuario” se creará el usuario en caso de que no existiera. Si no está habilitado y no existe previamente no se permitirá el acceso al usuario.

Si habilitas la actualización de los datos del usuario en cada acceso vía SAML, la información de su email y de su grupo será actualizado automáticamente. De este modo, la aplicación desregistrará los grupos que tuviera relacionado el usuario que no estén en los nuevos datos que se tuvieran del usuario y que no estuvieran definidos en la lista de grupos internos protegidos que se definieran previamente en el panel de administración donde se configura la aplicación SAML.

¿Como se ha desarrollado la aplicación SAML de owncloud?

Owncloud presentaba alguno de los típicos problemas de “domesticación para soporte SAML” con los que nos encontramos en el software de hoy en día y es básicamente que la arquitectura de la autenticación se basa en la premisa de que las credenciales del usuario se entienden como usuario/contraseña: Acoplamiento al formulario de login, obligación a registrar una contraseña en la base de datos.

Veamos rápidamente la declaración de algunas de las funciones de la clase base de la autenticación de la que extienden los backends de autenticación y son llamados en la función de login.

public static function login( $uid, $password ){
    …
    $uid = self::checkPassword( $uid, $password );
    if ($uid) {
        session_generate_id();
        self::setUserId($uid);
        return true;
    }
    return false;
}

public static function createUser( $uid, $password )

Como vemos la función de login que se encuentra en el core de owncloud hace una llamada a la función checkPassword que espera un usuario y un password, que es el que suministraríamos desde el formulario de login. Y que para la creación de un nuevo usuario se necesitan obligatoriamente también estos datos.

Lo que hemos tenido que hacer es una vista independiente a la que dirigimos al usuario cuando pulsa sobre el “enlace SAML” con el siguiente aspecto:

// Cargamos la librería de simplesamlphp
include_once($sspPath.”/lib/_autoload.php”);

// Inicializamos la instancia de la autenticación SAML
$auth = new SimpleSAML_Auth_Simple($spSource);

// Obligamos al usuario a autenticarse
$auth->requireAuth();

// Una vez autenticado y que tenemos una sesión valida en el SP, tenemos que hacer una llamada a la función de login en la que ni le pasamos username ni password.

OC_User::login(‘ ‘, ‘ ‘)

Esta función de login lo que hace es lanzar en cascada todos los plugins de autenticación activos en owncloud. Ninguno autenticará al usuario hasta que lleguemos al backend SAML. En el que volvemos a comprobar que el usuario tiene una sesión válida en el SP, obtenemos los datos del usuario y ya se autentica al usuario en la aplicación final.

public function checkPassword($uid, $password){
    if(!$this->auth->isAuthenticated()) {
        return false;
    }
    $attributes = $this->auth->getAttributes();
    if (array_key_exists($this->usernameMapping, $attributes)) {
        $uid = $attributes[$this->usernameMapping][0];
        OC_Log::write(‘saml’,'Authenticated user ‘.$uid,OC_Log::DEBUG);
    }
    else {
        OC_Log::write(‘saml’,'Not found attribute used to get the username (“‘.$this->usernameMapping.’”) at the requested saml attribute
assertion’,OC_Log::DEBUG);
    }
    return $uid;
}

Posteriormente en los hooks de post-login de los que dispone owncloud es donde realizaríamos la auto-creación del usuario en caso de que no existiera o su actualización.

Como vimos puesto que para la creación de usuario se requiere de usuario/contraseña, cada vez que creamos un nuevo usuario generamos aleatoriamente una contraseña.

Otro problema que suele encontrarse a la hora de “domesticar” aplicaciones es un problema relacionado con el Single Log Out, y que este cuando se realiza desde otra aplicación federada se propague sólo hasta el SP pero no a la aplicación final.

Esto se arregla invalidando el acceso al usuario no sólo cuando la sesión de la aplicación local es válida sino comprobar también la sesión del SP.

En owncloud la función que compruba si el usuario se ha autenticado es la siguiente:

public static function isLoggedIn() {
    static $is_login_checked = null;
    if (!is_null($is_login_checked)) {
        return $is_login_checked;
    }
    if( isset($_SESSION['user_id']) AND $_SESSION['user_id']) {
        OC_App::loadApps(array(‘authentication’));
        if (self::userExists($_SESSION['user_id']) ){
            return $is_login_checked = true;
       }
    }
    return $is_login_checked = false;
}

Por tanto si la función userExists devuelve false se denegaría el acceso.

Lo primero que hicimos fue pensar en implementar la función userExists en nuestro backend de la siguiente forma:

public function userExists($uid){
    if ($this->auth->isAuthenticated()) {
        $attributes = $this->auth->getAttributes();
        if (array_key_exists($this->usernameMapping, $attributes)) {
            $saml_uid = $attributes[$this->usernameMapping][0];
            if($saml_uid && $saml_uid == $uid) {
                OC_Log::write(‘saml’,'SAML session found for user ‘.$uid,OC_Log::DEBUG);
                return true;
            }
        }
    }
    OC_Log::write(‘saml’,'Deleting local session for user ‘.$uid,OC_Log::DEBUG);
    unset($_SESSION['user_id']);
    return false;
}

El problema es que la función global userExists va llamando recurrrentemente a los backends de autenticación activados y en cuanto un backend devuelve true, el acceso va a estar permitido y deja de llamarse al resto de funciones userExists de los backends. Con lo cual la anterior función nunca se ejecutaría.

public static function userExists($uid){
    foreach(self::$_usedBackends as $backend){
        $result=$backend->userExists($uid);
        if ($result===true){
            return true;
        }
    }
    return false;
}

Por tanto no hay una manera fácil de resolver esto sin tener que tocar el core de owncloud.

Related Posts:

• Research project about async user provisioning based on SAML2.0Proyecto de investigación sobre Provisión asíncrona de usuarios basado en SAML2.0
• Presentado el proyecto CONFIA en la IV Convocatoria de Premios @asLAN a Administraciones y Organismos Públicos
• Como hacer que nuestras aplicaciones de Google Apps autentiquen contra nuestra fuente de usuarios local (base de datos, ldap, etc) usando Uniquid (protocolo SAML 2.0).

La Jornada comenzó con la intervención de un representante de un importante banco que nos contó que los tiempos están cambiando, las empresas están optando por reducir [...]]]> El pasado 14 de Junio tuvo lugar en Madrid el WBSDay, evento que organiza la empresa WhiteBearSolution.

La Jornada comenzó con la intervención de un representante de un importante banco que nos contó que los tiempos están cambiando, las empresas están optando por reducir costes sin perder calidad ni funcionalidades útiles. Simplemente optimizando los recursos y utilizando software libre.

A continuación tuvo lugar la presentación de las nuevas versiones de sus productos:

WBSVision

Este es el nombre que recibe el nuevo producto de gestión de identidades y de federación de identidades, que anteriormente era conocido como WBSAgnitio.

La demo del producto se me hizo corta, eché de menos en la demo que entraran a describir a nivel técnico como habían añadido esa nueva funcionalidad de federación de identidades, ya que el resto de funcionalidades ya la conocía de las versiones anteriores del producto. Afortunadamente tras las charlas pude indagar más sobre lo que ya tienen implementado y el roadmap que tienen a futuro. A corto plazo su prioridad es cubrir la funcionalidad que se le pide a un IdP Lite pero me indicaron que están muy interesados en como evoluciona esta tecnología y no descartan implementar nuevas funcionalidades que faciliten la integración con servicios federados, módulos de gestión de metadatos o incluso dar soporte al estandar que aún se está cocinando en la IETF, para la gestión de identidad en la nube, el estandar SCIM.

Desde Yaco nos hemos comprometido a instalar y probar su software y ayudarles en lo que podamos en este nuevo reto que emprende su producto en el mundo de la federación de identidades. Sobretodo en el tema de los plugins de los SP y en como realizar la provisión de usuarios desde WBSVision en las aplicaciones finales de manera más segura y robusta a través del estadar SAML.

Cabe destacar en el turno de casos de éxito la intervención que tuvo un responsable de la empresa Indra, que nos contó el interesante proyecto que tienen en marcha con la empresa Unipapel, en la que han consolidado haciendo uso de WBSVision 3 diferentes Active Directorys pertenecientes a empresas que fueron adquiridas por Unipapel. Sobretodo me gustó escuchar que están dando soporte SAML a las aplicaciones SAP de los que esta empresa disponía que eran numerosos. Esperémos que esto sea un germen y que poco a poco nos encontremos con que gran parte del catalogo de aplicaciones de SAP soporte SAML, de momento ya tienen un SP basado en su tecnología.

WBSAirback

Lo que comenzo como un producto para la gestión de backups se ha convertido en un producto bastante completo que incluye también la gestión de almacenamiento.

Entre las muchas funcionalidades que se ofrecen están las de almacenamiento flexible, gestión de copias de seguridad en NetApp, entornos virtuales y en entornos remotos.

No cabe duda de que se trata de un producto muy sólido como constataron varios de los clientes que en la sala se encontraban, que dieron fé del rendimiento y robusted del producto. No es de extrañar que como parte del producto se encuentre el sistema Bacula, del que tanto se está hablando últimamente como alternativa a las pesadas y mastodonticas aplicaciones para hacer backup. Aristide Caraccio (VP Sales & Marketing, Worldwide at Bacula Systems) nos habló de la sinergia que existe entre Bacula System y WhiteBearSolution, fruto de la cual, para esta nueva version de WBSAirback se han desarrollado nuevas funcionalidades y mejorado el rendimiento, fruto del trabajo de I+D+i de ambas compañias.

Y eso es todo lo que puedo contar por ahora, espero poder disponer pronto de la última versión de WBSVision, poder aportar mi granito de arena y poder decir pronto que hemos integrado WBSVision con nuestro producto de federación de identidades Uniquid.

Related Posts:

• No Related Posts

La TNC es la Terena Networking Conference y es el evento anual más importante en Europa sobre temas de redes de comunicaciones y middleware. Va gente [...]]]> Esta semana he estado en la TNC2012 en representación de Yaco y he de decir que ha sido una experiencia fantástica y muy productiva en todos los sentidos.

La TNC es la Terena Networking Conference y es el evento anual más importante en Europa sobre temas de redes de comunicaciones y middleware. Va gente de todo el mundo y he conocido a personas de Nueva Zelanda, Japón, Canada, Chile y, por supuesto, la mayoría de países europeos.

Este año se ha celebrado en Reykjavik, Islandia y hemos tenido la enorme suerte de que prácticamente todos los días ha hecho un tiempo envidiable con mucho sol y poca lluvía. Eso no quiere decir que no hiciera falta un buen chaquetón pero bueno, esas latitudes es lo que tienen.

Todo empezó el pasado domingo 20 con el encuentro de REFEDS. Allí tuve la oportunidad de hablar sobre el proyecto PEER y su historia. Aunque sigue habiendo dudas en cuánto a su utilidad y principales casos de uso, lo cierto es que cada vez hay más gente interesada en desplegar su propia instancia y utilizarla de herramienta de apoyo para una federación de identidades. El objetivo siempre ha sido simplificar todo lo posible la incorporación de un servicio a una federación existente. PEER lo simplifica desde el punto de vista técnico pero no intenta definir ningún tipo de política de comportamiento sobre el uso que cada uno dé a los metadatos que aloja. Me gusta mucho la comparación con el sistema DNS en el sentido que DNS hace principalmente una sóla cosa (traducir nombres a direcciones IP) y no se mete en el uso que la gente haga de esas direcciones IPs. PEER intenta conseguir lo mismo en cuanto a metadatos de entidades de una federación de identidades.

El propio domingo por la noche hubo una gala de recepción para los ponentes y estuvimos en el ayuntamiento de Reykjavik. Allí encontré a viejos conocidos como Leif Johansson y Johan Berggrende Nordu.net, los cuáles me presentaron a Jørgen Qvist  con quién estuvimos hablando sobre posibles formas de colaboración entre Nordu.net y Yaco.

La mañana del lunes la pase en compañia de Victoriano Giralt y Diego López haciendo un poco de turismo y viendo algunas maravillas de la naturaleza de Islandia como fallas, geyseres o cascadas de extraordinarias dimensiones. Muy bonito y divertido pero había que estar pronto de vuelta en la TNC porque a las 16:00 tenía que dar mi Lighting Talk junto a otros 15 compañeros. Brook Schofield era el maestro de ceremonias y se encargó de que ninguno de nosotros excedieramos los 5 minutos de que disponíamos. Fue bastante divertido a pesar de la rigurosidad de Brook y su fatídico Ipad. Podéis ver la charla que dí sobre el trabajo que Sixto Martín ha realizado sobre Provisionamiento Asíncrono usando AttributeQuery de SAML2.

Otras lighting talks que me parecieron interesantes fueron la de Mujina, por Joost van Dijk, una herramienta que facilita el testing de IdPs y SPs mediante un sistema que se puede modificar via una API REST. Chris Philips, de Canada, estuvo hablando de SCIM y fue interesante aunque muy poco tiempo para la amplitud del tema. Los chicos de Powefolder hablaron de su producto y de como es una más que viable opción para tener un clon de Dropbox en tus propia infraestructura. Ahora están trabajando junto con el proyecto Moonshot para añadir capacidades SAML2 de forma nativa. Maria Isabel Gandia, a quién conocí el día anterior también dió una lighting talk sobre redes de comunicación y un sistema para poder encontrar a las personas pertenecientes a estas organizaciones de forma simple y eficaz.

Recepción de ponentes

Esa misma noche nos llevaron a un sitio muy turístico llamado Viking Village donde pasamos un rato agradable comiendo cosas típicas (taquitos de tiburón) y viendo a los nativos disfrazados de antiguos vikingos. Allí mismo tuve la oportunidad de charlar con Niels van Dijk sobre futuras ideas de las federaciones de identidades y como construir routers y cortafuegos de identidad para conseguir que las federaciones desaparezcan o, lo que es lo mismo, que haya una federación global. Victoriano Giralt o Ken Klingenstein también comparten estas ideas.

El día siguiente pude hablar con mucha gente interesante y más que charlas estuve haciendo mucho networking. Conocí a la gente de la federación Australiana con los que estuve charlando acerca de la integración entre PEER y su Federation Registry, un software genial destinado a los operadores de una federación que permite gestionar metadatos, realizar estadísticas, monitorizar los sistemas y muchas más cosas. Ahora han publicado la versión 2.0 y estaban dándola a conocer en la TNC. También estuve hablando con Marco Fargetta sobre el modelo Hub & Spoke en las federaciones de identidad y las ventajas que supone frente al model tradicional de Mesh. Más tarde hablé con Rok Papež, de la federación Eslovena. Rok se mostró interesado en nuestro trabajo en PEER y me preguntó por tecnologías como djangosaml2 ya que ellos están empezando a usar Django para crear herramientas para su federación. Por supuesto que intercambiamos tarjetas de información para seguir en contacto y quién sabe si poder hacer proyectos juntos. Finalmente tuve un rato de descanso para hablar con mi amigo Roland Hedberg. Me preguntó si habíamos pensado sobre el problema del consentimiento informado en nuestro trabajo de Provisionamiento Asíncrono y aunque no lo habíamos tenido en cuenta, juntos estuvimos pensando en posibles soluciones. También comentamos que pysaml2 es un poco complicada de usar para desarrolladores que quieren añadir soporte SAML2 a sus aplicaciones escritas en Python y juntos esbozamos un plan para simplificar las APIs públicas de pysaml2 y hacerlas más sencillas. También me comentó su intención de migrar el proyecto a Github y la verdad es que creo que es una buena decisión porque vamos a conseguir más visibilidad y, sobre todo, va a ser más sencillo de gestionar que con Launchpad.

El miércoles dediqué parte del día a refactorizar el código de pysaml2 para conseguir el objetivo que nos habíamos marcado Roland y yo el día anterior y la verdad es que avancé bastante. También estuve en una reunión con Licia Florio, Nicole Harris, Andreas Soldberg, Miroslav Milinovic, Brook Schofield y Milan Sova haciendo un análisis de requisitos sobre la herramienta Metadata Explorer que Terena quiere desarrollar. La verdad es que aún hay bastantes dudas sobre qué tiene que hacer exactamente la herramienta pero también hay bastantes cosas claras como que debe sustituir al actual wiki de REFEDS sobre Federaciones y que tendrá más datos que los que se encuentran en los metadatos de las entidades que pertenecen a las federaciones. Andreas sugirió un modelo pull donde cada federación proporcione una URL con la información que se decida en formato JSON y a los demás les pareció bastante bien la idea.

Más tarde pude hablar con Leif Johansson en el camino de vuelta al hotel y estuvimos charlando sobre el futuro de PEER y las distintas funcionalidades que deben añadirse para poder convertirse en un agregador y publicador de metadatos. De ahí tuve el tiempo justo para ir a dejar las cosas al hotel y luego ir a la cena de gala donde nos sirvieron deliciosidades islandesas y pude charlar un rato con Johan Berggren, Andreas Soldberg y un chico de la federación Suiza cuyo nombre no recuerdo. Luego Victoriano me presentó a Jacob Appelbaum, del proyecto Tor y también a María José López Purailly de la Red CLARA, en Latinoamerica.

Con eso concluía mi visita a Islandia ya que el jueves a primera hora salía mi avión de vuelta a casa. Ha sido una experiencia muy positiva donde he conocido a multitud de personas de esta comunidad. Espero poder estar el año que viene en Maastricht en la TNC2013 y también espero que la participación de Yaco en esta comunidad no haga más que aumentar.

Related Posts:

• No Related Posts

Los Premios @asLAN son una iniciativa que, año tras año, se refuerza como marco en el que presentar, conocer y premiar experiencias de éxito en [...]]]> Se ha presentado el proyecto CONFIA para optar por el premio @asLAN a Administraciones y Organismos Públicos en la categoría de Educación.

Los Premios @asLAN son una iniciativa que, año tras año, se refuerza como marco en el que presentar, conocer y premiar experiencias de éxito en la Administración Pública Española en la aplicación y uso de Tecnologías de la Información y Comunicaciones.

Desde Yaco Sistemas pedimos tu colaboración. Si el proyecto te parece interesante puedes apoyarlo depositando tu voto en el portal del SITI en la categoría de Educación.

Nota: Para poder realizar tu voto debes tener una cuenta en @asLAN, sino tienes la tuya puedes registrarte rápidamente aquí, tras darte de alta únicamente tienes que introducir tu correo en el formulario de login de @asLAN y se te enviará la clave a ese correo. Será cuando entonces tengas tus credenciales (correo/clave) para poder ingresar en el formulario de login que te aparece en el portal del SITI para poder votar.

Related Posts:

• Implemented SAML plugin for ownCloudImplementado plugin SAML para ownCloud
• “El viaje al e-learning no ha hecho más que comenzar”
• Se habla del proyecto CONFIA en la lista de correo de la Iniciativa Kantara

A continuación se citan aspectos a tener en cuenta para medir la política de gestión de identidad de nuestra organización:

Numero [...]]]> En este artículo pretendemos ofrecer una guía rápida para detectar posibles deficiencias en cuestiones de control de acceso y gestión de identidad que se pudieran estar produciendo en sus organizaciones.

A continuación se citan aspectos a tener en cuenta para medir la política de gestión de identidad de nuestra organización:

Numero de restablecimientos e incidencias con las contraseñas al mes

Este es un dato clásico a tener en cuenta en la gestión de la identidad, y es clave para ayudar a las organizaciones a medir la eficacia de sus programas de IAM. Las empresas generalmente observan el numero de llamadas relacionadas con incidencias con las contraseñas a los centros de atención (help desk), bloqueos de cuentas y el número de restablecimientos automáticos de las contraseñas que se producen al mes como buenos indicadores de la eficacia de su política de contraseñas. Esta métrica generalmente debería de tender a la baja, si no lo hace, la política de contraseñas y las herramientas de gestión de la organización requieren una revisión.

Número medio de credenciales distintas que hacen falta por usuario

¿Cuantas claves usas?

Este es otro dato clásico, y durante años, un argumento de peso para justificar la necesidad de sistemas de inicio de sesión único (SSO). Generalmente las grandes organizaciones hacen manejar a sus empleados del orden de 10-12 cuentas por usuario.  Es necesario reducir ese numero para facilitar la experiencia del usuario final y disminuir el sobre coste de gestión que esto conlleva a los administradores de sistemas.

Numero de cuentas duplicadas/que no tienen dueño

En ocasiones se puede dar el caso en que en una misma aplicación tengamos dadas de alta varias cuentas para una misma persona, ya sea por error en el alta de la cuenta o poque no se tenga clara la identidad de cada usuario, o porque el usuario posea mas de un rol en esa aplicación y se creara una cuenta por cada rol. Si detectamos un gran numero de este tipo de cuentas duplicadas querrá decir nuestra política FIAM falla. Deberémos de tener mecanismos para detectar rápidamente este tipo de anomalías y políticaspara que no se produzcan.

Lo mismo ocurre con cuentas que no tienen dueño, bien sea porque el usuario ya no pertenece a la organización, porque han quedado obsoletas, etc.

Número de cuentas provisionadas

Es interesante conocer el numero de cuentas que se provisionan al més y el numero total de cuentas que maneja la organización. Un buena infraestructura IAM debe siempre permitir el alta de nuevos usuarios que necesitan poder acceder a los diferentes sistemas y aplicaciones. Cuanto mayor sea el volumen de las cuentas más preciso tendrá que ser nuestro sistemas de alta/actualización/baja de usuarios.

Tiempo medio que se tarda en provisionar/dar de baja a un usuario

Hay que medir el tiempo medio que debe esperar un usuario en poder acceder a los recursos que necesita. Este parámetro se suele emplear para medir productividad y ROI. También es necesario medir el tiempo en dar de alta a un usuario y que este tiempo cumpla con los requisitos de una buena política de bajas de empleados.

Nivel de automatización del proceso de provisionamiento/actualización/baja de un usuario.

Este parámetro influirá enormemente en la métrica anterior. Cuanto más automatizado y definido esté el proceso de negocio de las altas/actualizaciones/bajas de cuentas, más eficiente y veloz será y menos recursos humanos consumirá. No es lo mismo que el administrador registre los datos de un usuario, le asigne sus roles en las aplicaciones, haga un click y las cuentas se creen automáticamente que tener ir dando de alta manualmente de alta cuentas al usuario en las diferentes aplicaciones.

Tiempo medio en autorizar un acceso

Esta medida puede dar una idea de la eficiencia de los procesos de aprobación de su organización. Por ejemplo, si hay 4 personas involucradas en conceder el acceso a salesforge a un comercial y se tarda 2 semanas en conceder el acceso, el empleado verá limitada su capacidad de ventas en ese periodo hasta que limitado esas 2 semanas semanas el usuario verá reducida su capacidad de venta apor no disponer de los recursos que necesita. Analizar cuanto se tarda en conceder el acceso puede ayudar a identificar donde se produce el cuello de botella del proceso.

Numero de cuentas privilegiadas que no tienen dueño/responsable y privilegios mal distribuidos

Este tipo de cuentas surgen cuando la gente que tenía las credenciales para conceder el acceso a importantes recursos no estaban bien formados.
Puede darse el caso en que se utilizaran cuentas con privilegios de uso compartido entre varios usuarios. También  puede darse el caso de que los propios responsables de dar cuentas se dieran así mismos o a sus conocidos más privilegios de la cuenta. Es evidente el riesgo que  conlleva que se den este tipo de situaciones. De igual forma que pueden producirse errores a la hora de asignar los roles y privilegios, pueden existir fallos a la hora de definir los permisos que tendrá un determinado rol dentro de cada aplicación. Las organizaciones deben implantar mecanismos de monitorización sobre los recursos para detectar los accesos indebidos.

Artículo basado en “10 identity management metrics that matter” de Frank Villavicencio.

Related Posts:

• La importancia del conjunto común de atributos en las federaciones de identidades
• Yaco Sistemas asiste al RS3G Mobility Project Meeting (Bologna)

Lo primero que tenemos que hacer es instalar y configurar un En esta entrada mostraremos lo sencillo que resulta configurar Uniquid y nuestra cuenta de Google Apps para que los usuarios de nuestra aplicación autentiquen contra nuestra fuente de usuarios local. Concretamente en este ejemplo veremos como hacerlo para ldap.

Lo primero que tenemos que hacer es instalar y configurar un IdP de Uniquid.

Supongamos que ya tenemos la instancia de Uniquid accesible en https://idp.example.org y con su configuración básica y certificados a utilizar establecidos.

Accedemos al asistente: “Asistente para Conectar Google Apps con tu IdP ”

Comenzamos el Paso 1, Configuración de la fuente de autenticación con la que queremos conectar a las aplicaciones de Google Apps.

El proceso para utilizar una base de datos sería parecido, en lugar de configurar la fuente de autenticación ldap configuraríamos los datos de conexión de la base de datos. Están soportados muchos formatos de bases de datos: mysql, oracle, posgresql, etc

Una vez hecho esto accederíamos al paso 2 “Configurar conexión con Google”, donde se nos pedirá que añadamos nuestro dominio de Google apps y seleccionemos el atributo que queremos usar como identificador de las cuentas de usuario.

A continuación accedemos al paso 3, “Configurar la nueva autenticación de Google” donde se nos muestran los datos de conexión de nuestro IdP que deberemos introducir en el panel de administración de Google.


Accedemos a nuestra cuenta de administrador de Google, entramos en la vista de administración del dominio de nuestras apliacciones de Google Apps, accedemos a las “Opciones Avanzadas” y seleccionamos la configuración del single sign-on (SSO)

1. Habilitamos el Single-Sign-On activando la casilla.
2. Copiamos y pegamos las urls de SSO, SLO y cambio de claves
3. Subimos el archivo con nuestro certificado público.
4. Opcionalmente configuramos la mascara de red
5. Guardamos

Y ya podríamos acceder a través de nuestro proveedor de identidad.

Related Posts:

• Éxito del entorno federado del Sistema Nacional de Educación a Distancia de México
• Research project about async user provisioning based on SAML2.0Proyecto de investigación sobre Provisión asíncrona de usuarios basado en SAML2.0
• “El viaje al e-learning no ha hecho más que comenzar”