1. Pasos para la instalación de Soffid IAM. 2. Preparación de la BBDD

Transcripción

1 Índice de contenido 1.Pasos para la instalación de Soffid IAM Preparación de la BBDD Preparativos para MySQL Preparativos para Oracle Preparativos para Microsoft SQLServer Instalación de la consola en RedHat Linux Prerequisitos Instalación de la consola Autoarranque Provisión de los flujos de trabajo Instalación del servidor de sincronización Instalación del servidor de sincronización en Red Hat Instalación del servidor de sincronización en Windows Configuración del servidor de sincronización...6 a)configuración del primer servidor de sincronización...6 b)configuración de los siguientes servidores de sincronización...8 c)configuración de los servidores como proxy Configuración de los agentes Instalar los conectores Configurar los agentes Provisión Dominios y tipos de usuarios Grupos Aplicaciones...14 a)roles Usuarios Recursos...16 a)redes...17 b)máquinas Definición de Flujos de trabajo...17 Página 1

2 1. Pasos para la instalación de Soffid IAM 1. Preparación de BBDD a) mysql b) Oracle c) SQL Server 2. Instalación de la consola 3. Instalación del servidor de sincronización a) Servidor principal b) Servidor de Backup 4. Instalación de Agentes a) instalación de proxys b) Instalación de agentes 2. Preparación de la BBDD 2.1. Preparativos para MySQL Se debe disponer de un usuario administrador y su contraseña en la máquina que albergue la base de datos. En ocasiones, sólo se permite el acceso desde root sin contraseña. Si es así, debe ejecutarse: root@host:~> mysql mysql> grant all privileges on *.* to USUARIO_ADMIN@localhost identified by 'PASSWORD_ADMIN' with grant option; Donde USUARIO_ADMIN será el usuario que elijamos como administrador de la BBDD y PASSWORD_ADMIN será el password que le asignemos. Adicionalmente, para permitir la subida de archivos grandes, debe asegurarse que el tamaño de paquetes es de al menos 32 M. Este parámetros se configura en el archivo /etc/mysql/my.cnf [mysqld] max_allowed_packet=128m Página 2

3 2.2. Preparativos para Oracle Guía de instalación Debe crearse una instancia de base de datos. Opcionalmente, pueden crearse dos tablespaces SOFFID_DATA y SOFFID_INDEX para albergar respectivamente las tablas y los índices de la aplicación. Debe configurarse también el listener TCP/IP Preparativos para Microsoft SQLServer Debe disponerse de un usuario administrador de la máquina y de su contraseña. Las conexiones TCP/IP deben estar habilitadas y el servicio SQL Server Browser debe estar iniciado. La autenticación del SQL Server debe ser SQL Server and Windows Authentication mode. Para realizar la conexión al servidor y crear la base de datos se debe disponer de un usuario y login que tenga otorgado el rol sysadmin. Se debe instalar también en el servidor el JDK y crear en las variables de entorno del servidor la variable SOFFID_JAVA_HOME. 3. Instalación de la consola en RedHat Linux 3.1. Prerequisitos Disponer de un usuario root y su contraseña. Léase también las notas referidas al motor de base de datos específico En ocasiones, sólo se permite el acceso desde usuarios no root, y deben ejecutar el comando sudo para ejecutar como root Si es así, debe ejecutarse: sudo bash En plataformas 64 bits de RedHat enterprise 6.3 debe instalarse el paquete glibc.i686 rpm -i glibc el6.i686.rpm nss-softokn-freebl el6.i686.rpm Debe configurar las iptables para que se permite el acceso al puerto 8080 y 760. En redhat el archivo se encuentra en /etc/sysconfig/iptables 3.2. Instalación de la consola Página 3

4 Ejecutar installer.sh -c Guía de instalación El sistema instalará la consola en el directorio indicado. Para crear los objetos de base de datos, el instalador solicitará el usuario y contraseña de administrador. Se recomienda utilizar el nombre de base de datos soffid. En el caso de Oracle, el sistema dará la posibilidad de crear dos tablespaces separados para datos e índices. Si los tablespaces ya existen, no se modificará su configuración. Como propietarios del esquema, el sistema propondrá el usuario soffid y una contraseña aleatoria, la cual se puede cambiar en este momento. Una vez introducidos el instalador creará el usuario con la contraseña introducida y ejecutará las sentencias SQL necesarias para crear los objetos de la base de datos Autoarranque Para habilitar el auto arranque, ejecutar (como root): ln -fs /opt/soffid/iam-console/jboss/bin/soffid-iamconsole /etc/init.d/soffidiamconsole ln -fs /etc/init.d/soffid-iamconsole /etc/rc3.d/s98soffid-iamconsole ln -fs /etc/init.d/soffid-iamconsole /etc/rc3.d/k10soffid-iamconsole Una vez configurado, debe arrancar la consola ejecutando: service soffid-iamconsole start 3.4. Provisión de los flujos de trabajo Si bien la mayoría de flujos de trabajo son específicos de cada organización, hay una serie de flujos de trabajo que son imprescindibles para el correcto funcionamiento del sistema: add-agent-wf: Necesario para la correcta configuración de los servidores proxy purge-process: Necesario para limpiar la información de los procesos finalizados read-logs: Necesaro para recuperar el archivo de registro de la consola. Estos flujos de trabajo pueden descargarlos de nuestra web Para cargar estos flujos de trabajo abriremos la consola usando un navegador web y accediendo a la dirección: Página 4

5 La primera vez que accedemos usaremos el usuario y contraseña por defecto: Usuario: admin Password: changeit Clickar en: Inicio - Configuración Soffid Administrar definición de procesos Pulsar en el botón desplegar y aparecerá una nueva ventana. Seleccionar el archivo del proceso (archivo.par) y pulsar el botón Cargar Archivo (upload). 4. Instalación del servidor de sincronización Página 5

6 4.1. Instalación del servidor de sincronización en Red Hat Ejecutar rpm -i synserver rpm 4.2. Instalación del servidor de sincronización en Windows Antes de instalar comprobar que está habilitado el acceso por SSL al LDAP del AD. Si no estuviera activado, seguir el HOWTO. Ejecutar syncserver exe El sistema ofrecerá la posibilidad de instalar los siguientes módulos opcionales: Conector SAP Sincronización de contraseñas de Active Directory. El conector SAP deberá ser instalado en la máquina encargada de sincronizar las cuentas y contraseñas a un sistema SAP. No es precisa su instalación en los servidores de sincronización cuando la sincronización a SAP se realiza mediante un servidor proxy. La sincronización de contraseñas de Active Directory deberá instalarse en todos los controladores de dominio sin excepción. Este módulo permite que los cambios de contraseñas que se producen en el directorio activo sean propagados al sistema Soffid IAM de forma inmediata. Para la configuración de la sincronización de contraseñas es necesario especificar durante el proceso de instalación la URL del servidor de sincronización, así como el código que le daremos al agente de sincronización cuando lo configuremos (ver punto 5.2). Al instalar o desinstalar el servidor de sincronización es conveniente reiniciar el servidor Configuración del servidor de sincronización a) Configuración del primer servidor de sincronización Es recomendable que el primer servidor esté ubicado en el mismo servidor que la BBDD de repositorio. Para configurar el servidor debe ejecutarse el siguiente comando: Página 6

7 /opt/soffid/iam-sync/bin/configure -server -hostname hostname -dbuser soffid -dbpass pass -dburl jdbc:mysql://localhost:3306/soffid En equipos windows: %ProgramFiles%\soffid\iam-sync\bin\configure -server -hostname hostname -dbuser soffid -dbpass pass -dburl jdbc:mysql://localhost:3306/soffid El nombre de usuario y la contraseña introducidas deben coincidir con el usuario y contraseña creados en la base de datos durante el proceso de instalación. El hostname introducido deberá estar incluido entre la lista de servidores seycon. Por defecto la instalación de soffid habrá configurado como servidor de sincronización al mismo servidor donde se instaló Soffid, La lista de servidores de sincronización puede ser modificada a través del menú de Configuración-Parámetros. Modificar el parámetro seycon.server.list añadiendo el el campo Valor, los servidores de sincronización que instalaremos (separados por comas). Página 7

8 La url de conexión depende del servidor de base de datos en el que hayamos creado la base de datos: Para Oracle: Para mysql: jdbc:mysql://localhost:3306/nombbdd Para SQLServer: jdbc:sqlserver://localhost:1433;databasename=nombbdd b) Configuración de los siguientes servidores de sincronización Para configurar el servidor como servidor de backup debe estar incluido dentro del parámetro seycon.server.list. Una vez incluido debe ejecutarse el siguiente comando: /opt/soffid/iam-sync/bin/configure -server -hostname hostname -dbuser usuario -dbpass pass -dburl jdbc:mysql://localhost:3306/soffid En plataformas windows: %ProgramFiles%\soffid\iam-sync\bin\configure -server -hostname hostname -dbuser soffid -dbpass pass -dburl jdbc:mysql://localhost:3306/soffid Al ejecutar el comando, se generará una salida similar a la siguiente: Connecting to Your certificate is pending for administrator aproval. En este momento se creará una tarea en la consola que el administrador deberá resolver, aceptando o denegando la solicitud de acceso. Si la petición es aceptada, deberá volverse a ejecutar el comando anterior. En este caso, el resultado que aparecerá en pantalla será algo así como: Connecting to Página 8

9 Your certificate has been successfully generated A continuación el servicio ya puede ser iniciado. c) Configuración de los servidores como proxy Para configurar el servidor como servidor proxy de sincronización debe ejecutarse el mismo comando que en el caso del primer servidor: /opt/soffid/iam-sync/bin/configure -agent -hostname hostname -user usuario -pass pass -server En plataformas windows: %ProgramFiles%\soffid\iam-sync\bin\configure agent -hostname hostname -user usuario -pass pass -server En este caso también solicitará la aprobación de certificado. Página 9

10 5. Configuración de los agentes 5.1. Instalar los conectores Una vez configurados los servidores es necesario definir y configurar los agentes. El primer paso es acceder a la opción de Gestión de componentes y subir los archivos con extensión.jar que implementan los conectores. Una vez subidos veremos como aparecen en la lista implementando uno o varios tipos de agente Configurar los agentes El segundo paso consiste en configurar los agentes. En el menú Inicio iremos a Configuración Soffid/Agentes. En esta pantalla podremos configurar nuestros agentes. Cada agente se identifica mediante un código único que deberemos darle. Si bien la codificación a utilizar es definible por el administrador, se recomienda utilizar una codificación sistemática. Los atributos más relevante desde el punto de vista de configuración son la URL y el tipo de agente. El tipo de agente especifica cual de los conectores anteriormente instalados debe utilizarse. La URL indica donde se debe ejecutar el agente. Esta URL debe corresponder con la URL de alguno de los servidores proxy definidos. Si la URL introducida es la local, los agentes se ejecutaran desde los propios servidores de sincronización. Si la URL queda en blanco, el agente quedará desactivado. A continuación debe indicarse si se trata de un agente bidireccional o no. Los agentes bidireccionales se diferencian de los no bidireccionales en que: Las contraseñas temporales generados desde la consola solamente se propagan a los agentes bidireccionales. Los no bidireccionales solamente recibirán las contraseñas definitivas. Cuando una contraseña haya llegado a su fecha de expiración, será automáticamente desactivada en los agentes no bidireccionales, de tal forma que el usuario ya no podrá acceder al mismo. Cuando el sistema gestionado detecte un cambio en la contraseña a petición del usuario, este propagará la contraseña a Soffid si y solo si el agente asociado es bidireccional. En tercer lugar debe indicarse los grupos y tipos de usuario que deben propagarse al sistema gestionado. Cualquier usuario que no pertenezca a los grupos o tipos de usuarios indicados será automáticamente eliminado del sistema gestionado. Como excepción, si no se indica ningún grupo se considerará que todos los grupos deben ser propagados. Respecto a los códigos de usuarios a utilizar en el sistema gestionado, se debe indicar Página 10

11 también el dominio de códigos de usuario a utilizar. Si, como suele ser habitual, se utiliza el mismo código de usuario en todos los sistemas, el dominio de usuarios a indicar será Default user domain. Respecto al ciclo de vida de la contraseña, se debe indicar el dominio de contraseñas asociado. Este dominio de contraseñas permitirá que el usuario disponga de una contraseña común para distintos sistemas de información. Finalmente, en el apartado de parámetros del agente deberá introducirse la información específica de cada agente específico. Revisar el documento Soffid Syncserver Agents Guide. A la derecha del código del agente encontrará dos iconos que le permitirán propagar con un click todos los usuarios y roles al sistema gestionado. 6. Provisión 6.1. Dominios y tipos de usuarios Para poder adaptar las identidades a las particularidades y requisitos de cada repositorio de usuarios se dispon de las siguientes agrupaciones: Tipo de usuario: Se distinguen por tipos de usuario cuando sea necesario aplicar políticas específicas para determinados usuarios. Por ejemplo se puede distinguir usuarios internos (creado por defecto) y usuarios externos. De esta forma a los usuarios externos, con menor riesgo, se les puede aplicar una politica de contraseñas menos restrictivas. Dominio de usuario: Se crearán tantos dominios de usuario como identificadores distintos se dispongan. Si por ejemplo un usuario utiliza un acrónimo (user1) para entrar en AD pero para acceder al correo debe usar su cuenta de correo electrónico (jsmith@domain.com) se creará un dominio de usuario para AD (default) y otro para correo. Dominio de contraseñas: Para cada política de contraseñas deberá crearse un dominio de contraseñas. Si por ejemplo AD requiere de al menos 8 caracteres y AS400 máximo 7 deberemos crear distintas políticas de contraseñas. Política de contraseñas: Para cada dominio de contraseñas se podrán crear tantas políticas de contraseñas como tipos de usuarios. En la siguiente ilustración se muestra la jerarquía de políticas de contraseñas. Página 11

12 Para la correcta configuración, primero se deben definir los tipos de usuario requeridos. Una vez definidos los tipos de usuario se añadirán tantos dominios de usuarios como identificadores requieran los usuarios. Para cada Dominio de usuario se podrá configurar el tipo: domino principal, asignado por el operador, asignado por el sistema, asignado por un agente. (EXPLICAR) A continuación se podrán definir dominios de contraseñas que contendrán al menos una política de contraseñas y como máximo una para cada tipo de usuario. La política de contraseñas controlará los siguientes campos: Página 12

13 6.2. Grupos Los grupos permiten gestionar los distintos roles de las aplicaciones configuradas. Cada grupo contendrá roles de las distintas aplicaciones a las que debe aplicar. Se deberán crear tantos grupos como tipos de identidades dispongamos. Una vez creados los grupos podrán ser usados en las distintas aplicaciones. Posibles ejemplos de grupos serán: Personal de administración, Dirección, Recursos Humanos, etc.. Hay que tener en cuenta que la gestión de los permisos otorgados a estos grupos se realizará desde las respectivas aplicaciones ya que serán los responsables de las mismas los que puedan decidir que grupos accederán y realizarán el mapeo de roles pertinente. Desde el interfaz de configuración del grupo solo se podrán consultar los roles asignados y los usuarios pertenecientes al grupo. En la siguiente ilustración se muestra la función de los grupos. La correcta aplicación de los mismos permite separar las áreas de responsabilidad. El responsable de RRHH será el encargado de asignar a los usuarios a los grupos que deba pertenecer para desempeñar correctamente sus funciones. Por otro lado el responsable de una aplicación deberá asignar a cada grupo los roles de aplicación correspondientes para que puedan realizar las tareas especificas del puesto (representado por el grupo). Página 13

14 6.3. Aplicaciones Las aplicaciones definen las herramientas a las que los usuarios deberán tener acceso a través de la gestión de identidades. Para cada aplicación se definirán, además de los parámetros descriptivos, sus roles. La correcta gestión de estos roles y su asignación a los grupos permitirá la gestión de los accesos a las aplicaciones (ver apartado 6.2) a) Roles Los roles forman parte de la configuración de aplicaciones ya que para su utilización estas deben incluir mecanismos de control de acceso basados en roles (RBAC). Una vez configurados y conocidos los roles de una aplicación se introducirán en la consola de Soffid para que puedan ser usados y asignados a los distintos grupos. Para cada Rol podremos definir: Nombre: Debe coincidir con el nombre en la BBDD correspondiente (configurado en el agente) Descripción: Descripción del rol Base de datos (Agente): Agente donde se debe sincronizar el rol Roles que lo tienen otorgado: Roles a los que se le asignará este rol. Grupos que lo tienen otorgado: Grupos a los que se le asignará este rol. Defecto (Solo para BBDD Oracle): Si está marcada esta casilla el rol será activado por defecto. Contraseña (Solo para BBDD Oracle): Para aquellos roles de Oracle protegidos por contraseña se utilizará la contraseña configurada en el agente. Dominio: Permite limitar el ámbito del rol en base a dominios. Página 14

15 6.4. Usuarios Una vez definidos los tipos de usuarios, sus dominios de usuarios dominios y políticas de contraseñas y grupos se podrá proceder a la creación de usuarios. Para la gestión de los usuarios se accede al menú Administración de activos/recursos Humanos/Usuarios. Para la creación de un usuario nuevo deberemos introducir la siguiente información: Código: El identificador principal del usuario. Se replicará en el dominio de usuario por defecto. Nombre, primer apellido y segundo apellido Correo electrónico: El utilizado para el correo. Tipo de usuario: Seleccionar de los tipos de usuarios creados. Grupo Primario: Seleccionar de los grupos creados Servidor home, Servidor de correo, Servidor de perfil : Funcionalidad pendiente, rellenar con null Multisesión: Si no se habilita el usuario solo podrá tener habilitada una sesión simultanea. Página 15

16 Una vez creado el usuario su información será propagada a aquellos sistemas a los que afecte (teniendo en cuenta la configuración de los agentes). Para poder utilizar el usuario deberemos generarle una primera contraseña. Para esto pulsaremos sobre el botón Nos pedirá confirmación y una vez aprobado obtendremos un mensaje con la contraseña creada de forma aleatoria y teniendo en cuenta la política de contraseñas Recursos Página 16

17 La gestión de los recursos tecnológicos permite asegurar que los usuarios hacen uso de los recursos desde equipos confiables, evitando de esta forma que se acceda a los recursos gestionados desde equipos no controlados. a) Redes Para el uso de las redes deberemos darlas de alta en el menú Administración de activos/recursos Tecnológicos/Redes. b) Máquinas Las máquinas podrán ser dadas de alta de dos formas. Manualmente accediendo al menú Administración de activos/recursos Tecnológicos/Equipos o a través de la autodetección cuando se instala un agente o se inicia una sesión. 7. Definición de Flujos de trabajo Los flujos de trabajo son la base de la adaptación de Soffid a los procesos de cada empresa. Estos procesos deberán ser definidos y adaptados a las especificaciones de cada empresa. Del mismo modo los procesos desplegados deberán ser mantenidos y adaptados a los cambios en la metodología o estructura de la empresa cuando así se requiera. No es objeto de este manual explicar la creación de los flujos de trabajo, descrita en los manuales para desarrolladores. Para la gestión de los grupos de trabajo, ver Página 17

18 punto 3.4 Provisión de los flujos de trabajo Guía de instalación Página 18