archivo

Archivos diarios: mayo 4, 2011

Hace poco tiempo asistí a un curso en el que nos expusieron el funcionamiento del sistema de gestión de identidades de mi organización. Aún le queda un amplio camino por recorrer para llegar a todos los rincones que quiere llegar, ya que como suele pasar en la mayoría de los proyectos de desarrollo de software, su éxito o fracaso vendrá dado por aspectos que poco tienen que ver con lo tecnológico.

Un sistema de gestión de identidades es aquel que pretende unificar en un solo repositorio (centralizado o distribuido) todas las identidades de los usuarios de una organización. Está compuesto por una parte procedimental y otra parte tecnológica, por lo que no hay que caer en el error de pensar que sistema de gestión de identidades es lo mismo que el almacén de datos donde se encuentran las mismas (generalmente un servicio de directorio basado en el protocolo LDAP).

Esto tiene sus ventajas tanto desde el punto de vista de la seguridad como de la consistencia:

– Le gestión de identidad asegura que el estado de la identidad de la persona en la organización está permanente actualizado y es correcto. De esta forma se consigue que el usuario siempre esté asociado al departamento al que pertenece, pese a que se mueva dentro de la organización o que el usuario se dé de baja en el sistema de gestión de identidad cuando deja de pertenecer a la organización, de esta forma se soluciona un importante problema de seguridad que no es otro que el no dar de baja los usuarios en los sistemas de información ya que generalmente quien gestiona los mismos no se entera de las mismas (sobre todo en organizaciones con varias sedes).

Esto se consigue integrando la gestión de la identidad como un proceso más del que una serie de departamentos y personas que se designen son responsables de ello. Es decir, la gestión de la identidad es un fin en sí mismo y no una actividad complementaria que se realiza si se puede y hay tiempo.

– Todo usuario utilizado en un sistema de información debe proceder del sistema de gestión de identidades, ya que garantizará que la identidad es válida dentro de la organización que hace uso de la aplicación. Otra cosa bien distinta es que se le conceda acceso a un sistema a una identidad que no debe acceder a él.

– La existencia de diferentes repositorios de nombres de usuario (ya que una gestión de usuarios no es una gestión de la identidad) o incluso de gestión de identidades provocarás posibles incoherencias en los nombres (en un lado puede aparece con tilde, en otro sin ella, en otro con un apellido incorrecto, etc…).

– Si los repositorios contienen diferentes atributos de la identidad, al unificarlo se asegura que se haga referencia a los mismos atributos de la misma forma y además tendrán los mismos datos.

– Se elimina la existencia de cuentas de usuarios genéricas ya que las mismas no se corresponden a una identidad concreta.

– Aunque no tiene por qué ser obligatorio en un sistema de gestión de identidades, otra de las ventajas consiste en evitar que existan más de una cuenta de identificación por usuario.

El repositorio se tiene que aprovisionar de datos, que generalmente proceden del sistema de gestión de recursos humanos de la organización (al que se le da en ocasiones el nombre de autoridad de identidad). En ocasiones, puede ser necesario la utilización de una aplicación intermedia si la gestión del ciclo de vida de la identidad no se puede realizar de forma adecuada con el sistema de gestión de recursos humanos, por ejemplo si:

– Se pretende integrar la gestión del ciclo de vida de la identidad cuando la misma es proporcionada por diferentes sistema de gestión de recursos humanos (algo que es posible en el caso de la Administración Pública, grupos de empresas, empresas con diferentes departamentos de recursos humanos, etc…).

– Se quieren proporcionar funcionalidades específicas para la gestión del ciclo de vida de la entidad que no las da el sistema o sistemas de gestión de recursos humanos. También en el caso de que se realice la asociación de usuarios a unidades funcionales que no tendrán por qué coincidir con las unidades organizativas utilizadas en dichos sistemas.

Como comentaba al principio del artículo, lo realmente importante de un sistema de gestión de identidades no es la tecnología, ya que ese aspecto podrá ser más o menos complejo pero ya existen soluciones en el mercado que cubren esta funcionalidad (de hecho y si nos vamos a un extremo, podría valer cualquier tipo de almacén de datos, siempre y cuando soporte la carga de trabajo que se estime que se va a tener y proporcione un rendimiento adecuado, sobre todo en consultas, ya que las lecturas en el mismo serán muy superiores a las operaciones de escritura), sino la gestión del ciclo de vida de la identidad y eso es un tema meramente procedimental.

La gestión del ciclo de vida requiere que personas ajenas al Departamento de Informática (salvo que desde la dirección de la organización se determine que dicha competencia es de Informática, algo que podría tener sentido a efectos prácticos, pero que no tiene sentido en cuanto a las competencias reales que debe tener un Departamento TIC), las cuales tendrán la responsabilidad de mantener en el sistema permanente actualizada la identidad del usuario y su pertenencia a las unidades organizativas o funcionales a las que esté adscrito en cada momento, teniendo en cuenta que algunas de las personas que participan en la gestión del ciclo de vida, tendrán otro tipo de tareas, en muchos casos totalmente diferentes a estas y con otro tipo de prioridades.

No hay más que pensar lo que cuesta que se designe personal de las áreas usuarias para validar el alta y baja de los usuarios en los sistemas (incluyendo la asignación de perfiles). En el caso del sistema de gestión de identidades todas las áreas implicadas deben funcionar bien porque de lo contrario se rompe con la finalidad de este tipo de sistemas que no es otra que suministrar identidades actualizadas.

¿Qué tareas realiza un analista funcional?, ¿cuáles un analista orgánico?. Depende de la entidad en la que trabajen y del proyecto en sí, la limitación de las funciones de cada uno.

Por regla general, se considera analista funcional a quien se encarga de la recopilación del catálogo de requisitos y de la definición de los casos de uso (o historias de usuario). Su objetivo es describir las funcionalidades del sistema y su comportamiento mediante el estudio de las necesidades del usuario. Su trabajo es muy importante y sin embargo no se le da el valor que se merece, ya he comentado en más de una ocasión que lo técnico suele resultar más glamuroso.

Los sistemas se desarrollan para el usuario y para que sean de utilidad hay que saber captar qué es lo que quiere el usuario y cómo desea interactuar con el sistema.

La técnica es muy importante, pero no lo es menos que la vertiente funcional, todos suman y todos restan si no hacen adecuadamente su trabajo.

El analista orgánico se encarga del diseño que no es otra cosa que la particularización de las necesidades del usuario a una implementación concreta. Para un proyecto concreto vendría a ser el arquitecto de la solución, ya que entraría incluso a definir el framework con el que se va a trabajar.

Lo habitual en los proyectos de desarrollo de software es encontrarnos con analistas que realizan las dos funciones, aunando en un solo perfil lo funcional y lo técnico. Tiene como principal ventaja que no es necesario transferir el conocimiento entre diferentes fases o procesos del desarrollo y que cada tarea es realizada por un experto en la misma. El principal inconveniente es que no existe una especialización, no obstante, hay que ser bastante bueno en uno de los dos perfiles para marcar de manera clara la diferencia respecto a analistas que realicen ambos trabajos (ahora, quien las marca es que es muy bueno y por tanto, vale mucho dinero).

En desarrollos iterativos e incrementales con una orientación ágil lo deseable es que la evolución del desarrollo sea rápida (realizándose los incrementos con cierta frecuencia) y resulta fundamental la participación del usuario, a ser posible como una pieza más del equipo de proyecto, lo normal es que no exista distinción entre analista funcional y orgánico, si bien, tendrá una vertiente más técnica, por las características particulares de este tipo de desarrollos. Existirán excepciones, en proyectos que por su naturaleza requiera de desarrolladores que den apoyo funcional, por la experiencia que tengan en un tipo de negocio concreto.