BizTalk Server 2004: Administración del Enterprise Single Sign-On

Por: Tomas Restrepo

 

Introducción

En el artículo anterior se introdujo conceptualmente el Enterprise Single Sign-on, uno de los componentes que viene con BizTalk Server 2004. Este artículo continua con este proceso de inducción, presentando como hacer operaciones de administración básicas sobre el servicio de SSO.

 

 

Procesos de Backup

Una vez se ha realizado la instalación del servicio de Enterprise Single Sign-on, bien sea con BizTalk Server, o como una instalación aparte debe ponerse sobre la mesa el tema de los procesos de resguardo de la información allí contenida.

 

El proceso de backup de un grupo de SSO consiste en dos partes críticas:

 

 

Resguardo del Master Secret

Una vez se ha realizado la instalación del Master Secret Server del grupo de SSO; se debe proceder al resguardo inmediato de la clave maestra de encripción generada durante este proceso.

 

Así mismo, el proceso de resguardo debe realizarse cada vez que se cambia la clave maestra mediante los procesos administrativos.

 

El resguardo del Master Secret es vital porque es la clave maestra con que están encriptados los datos en el Credentials Store. Si se pierde el master secret, así se posea un resguardo completo de la base de datos de credenciales, será imposible retornar la infraestructura de SSO a un punto funcional, pues será imposible acceder la información allí almacenada.

 

Para realizar el resguardo del master secret debe usarse la herramienta de línea de comando ssoconfig.exe:

 

tomasr@RADIANT>ssoconfig.exe -backupsecret e:\temp\SSOSecret20041120.dat

Password : *********      

Confirm Password : *********

Password reminder : Donde Trabaja?

The operation completed successfully.

 

Al realizar el backup de la clave, debe especificarse la ruta completa del archivo donde se desea almacenar la clave. Es crítico que dicho backup sea inmediatamente pasado a un medio de almacenamiento removible y almacenado bajo seguridad física donde no se tenga acceso a ella (ejemplo: una caja fuerte off-site).

 

Si se comprometiera la seguridad física del resguardo de la clave maestra, se verían comprometidos inmediatamente los contenidos de la base de datos de credenciales. En caso tal que esto sucediera, se debería cambiar inmediatamente la clave maestra, usando el comando ssoconfig.exe /generatesecret.

Como puede observarse de la figura anterior, al sacar el backup de la clave maestra, debe especificarse una contraseña con la que queda encriptado el archivo. Esta contraseña será necesaria para restaurar la clave maestra, por lo que debe tenerse cuidado igualmente de no perderla.

 

Para restaurar la clave maestra, puede usar el comando ssoconfig.exe -restoresecret:

 

tomasr@RADIANT>ssoconfig.exe -restoresecret e:\temp\SSOSecret20041120.dat

Password reminder : Donde Trabaja?  

Password : *********

 

 

Resguardo de la base de datos de credenciales

Para resguardar la base de datos de credenciales pueden usarse las facilidades de backup de SQL Server directamente (ej: Enterprise Manager o herramienta de terceros)

 

Sin embargo, puede ser preferible agregar la base de datos del SSO al JOB de SQL Server que hace el backup de un grupo de BizTalk Server en forma coordinada, para asegurar que la información contenida en el Credentials Store está así mismo coordinada con las demás bases de datos. Como realizar esta operación está descrito en la documentación de BizTalk Server en la sección titulada "Backing up the SSO Credential Database".

 

Es importante notar que cuando decida cambiar la clave maestra del SSO, debe proceder inmediatamente a resguardar la base de datos de credenciales para asegurar que ambos juegos de backups queden coordinados.

 

 

 

Creación de Aplicaciones y Usuarios

Una vez se tiene una infraestructura básica de SSO desplegada, interesaría poder hacer uso de ella en las soluciones que se desarrollen sobre BizTalk Server.

 

 

El primer paso en esta dirección será definir que aplicaciones afiliadas se pueden requerir en la infraestructura de SSO para el mapeo de credenciales de la solución. Así mismo, se deben definir que usuarios tendrán acceso a esta solución, definiendo los mapeos correspondientes para la aplicación afiliada definida.

 

 

Creación de una Aplicación Afiliada

Para crear una aplicación afiliada de SSO, se utiliza la herramienta administrativa SSOManage.exe con el comando -createapps. Este comando recibe como argumento un archivo XML con la información de la las aplicaciones a crear. Un ejemplo de este documento sería:

 

<sso>

   <applicationname="SAP">

      <description>The SAP application</description>

      <contact>someone@example.com</contact>

      <appuserAccount>DOMAIN\SsoSapUsers</appuserAccount>

      <appAdminAccount>DOMAIN\SsoSapAdmins</appAdminAccount>

      <fieldordinal="0"label="User Id"masked="no" />

      <fieldordinal="1"label="Password"masked="yes" />

      <flagsgroupApp="no"configStoreApp="no"allowTickets="no"

             validateTickets="yes"allowLocalAccounts="no"

             timeoutTickets="no"adminAccountSame="no"enableApp="yes" />

   </ application >

</sso>

 

 

Como puede observarse, el archivo contiene un conjunto de elementos <application>, cada uno de los cuales contiene un conjunto de opciones de la aplicación a crear:

 

Nombre

Tipo

Descripción

name

Atributo

Nombre con que se desea identificar la aplicación en la estructura de SSO

description

Elemento

Descripción de la aplicación

contact

Elemento

Dirección EMail del contacto administrativo para esta aplicación

appuserAccount

Elemento

Nombre del grupo de Windows que contiene a los usuarios que tendrán acceso a esta aplicación

appAdminAccount

Elemento

Nombre de la cuenta de Windows que administrará esta aplicación (Se recomienda que sea un grupo para facilitar la administración)

flags

Elemento

Banderas de la aplicación. Cada una se representa como un atributo.

 

TIP La infraestructura de SSO está mejor planteada para ser usada en una infraestructura de directorio activo (AD) de Windows. Por lo tanto, los grupos y usuarios usados en las definiciones de las aplicaciones deberían pertenecer al directorio corporativo y no a una máquina particular.

 

Debe tenerse en cuenta que para utilizar el SSO en este escenario, tanto la cuenta bajo la que ejecuta el servicio de SSO como los grupos de administración del mismo, deberían estar definidos en el directorio activo, y no como cuentas y grupos locales.

 

Las siguientes son las banderas permitidas en el elemento <flags>:

 

Nombre

Descripción

groupApp

Indica si es aplicación de grupo (mapeos por grupo) o por usuario

configStoreApp

Indica si es solo para almacenar configuración

allowTickets

Indica si permite la emisión de tickets SSO

validateTickets

Indica si debe validar tickets emitidos (irrelevante si no se fijo allowTickets)

allowLocalAccounts

Indica si la aplicación se puede definir con base a cuentas locales de la máquina. Si se especifica groupApp="yes", entonces este valor debe ser "no".

timeoutTickets

Indica si tickets emitidos tienen timeout

adminAccountSame

Si es true, se ignora el valor de appAdminAccount y se usa el grupo "SSO Affiliate Adiministrators" para designar los administradores de la aplicación

enableApp

Indica si habilitar la aplicación tras crearla. Si se pone en falso, se debe usar luego el comando ssomanage.exe -enableapp para habilitarla

 

 

Las secciones <field> representan campos dentro del concepto de autenticación de la aplicación. En el ejemplo presentado se definen dos campos llamados "User Id" y "Password". Más adelante podría observarse como son usados estos campos por las herramientas de administración del SSO durante la definición de mapeos de credenciales.

 

Una vez listo el archivo XML, se puede ejecutar el siguiente comando para crear las aplicaciones:

 

trestrepo@DOMAIN>ssomanage -createapps app.xml

Using SSO server on this computer

----------                                                                      

Created application 'SAP' with the following values:

 

Application Administrators account name : DOMAIN\SsoSapAdmins

Application Users account name          : DOMAIN\SsoSapUsers

Tickets allowed                         : No

Validate tickets                        : Yes

Field [0]                               : User Id               : Not Masked

Field [1]                               : Password              : Masked

 

 

Como en el archive de configuración se especifico enableApp="yes", la aplicación SAP ya estará habilitada, por lo que no será necesario ejecutar el comando ssomanage.exe -enableapp.

 

 

Creación de Mapeos de Usuarios

Un mapeo de usuarios especifica como se "convierten" las credenciales de un sistema de autenticación (Windows) a otro (el de la aplicación afiliada). Nuevamente, se usa ssomanage.exe y un archivo XML para definir un conjunto de mapeos de una sola vez.

 

Consideremos este archivo con un solo mapeo:

 

<sso>

   < mapping >

      <windowsDomain>DOMAIN</windowsDomain>

      <windowsUserId>trestrepo</windowsUserId>

      <externalApplication>SAP</externalApplication>

      <externalUserId>tomas.restrepo</externalUserId>

   </ mapping >

</sso>

 

Por cada mapeo especificado aparece un elemento <mapping> que contiene la siguiente

información:

 

Nombre

Descripción

windowsDomain

Nombre del dominio de Windows (o máquina) al que pertenece la cuenta de Windows para la que se desea crear un mapeo hacia la aplicación afiliada

windowsUserId

Nombre de la cuenta de Windows a mapear (o de un grupo si la aplicación afiliada se definirá con groupApp="yes")

externalApplication

Nombre de la aplicación afiliada a la que se va a asociar este mapeo

externalUserId

Nombre de la cuenta en la Aplicación Afiliada a que se mapea la cuenta de Windows definida más arriba.

 

Para poder asociar mapeos de usuarios a una aplicación, se deben cumplir dos requisitos básicos:

 

  1. La aplicación afiliada debe haber sido previamente habilitada en el SSO
  2. El usuario Windows a mapear debe pertenecer al grupo de usuarios configurado en la aplicación afiliada, de lo contrario se generará un error.

 

Una vez se tiene el archivo, se crean los mapeos mediante el comando:

 

trestrepo@DOMAIN>ssomanage -createmappings sapusers.xml

Using SSO server on this computer

Created mapping in application 'SAP' for user DOMAIN\trestrepo to tomas.restrepo.

 

 

Hasta aquí, lo único que hemos hecho es crear el usuario en la aplicación SAP (tomas.restrepo), e indicar al SSO dicho usuario estaría asociado a la cuenta DOMAIN\trestrepo del Directorio Activo, pero no que password o contraseña se tendrá registrado para esta credencial.

 

Para hacer esto, es necesario ejecutar un comando adicional:

 

trestrepo@DOMAIN>ssomanage -setcredentials DOMAIN\trestrepo SAP

Using SSO server on this computer

User Id : tomas.restrepo

Password : *********

Confirm Password : *********

 

Nótese que si el mapeo no existe, el comando -setcredentials pediría el nombre del usuario en la aplicación que se desea y lo creará. También es importante notar que los campos "User Id" y "Password" que aquí aparecen corresponden exactamente a los campos definidos al crear la aplicación SAP mediante el tag <field>.

 

No es necesario que el administrador del SSO cree todos lo mapeos directamente o asigne una por una las credenciales a dichos mapeos. En un escenario más normal, el administrador solo tendría que crear la aplicación, y luego cada usuario podría crear su mapeo por si mismo usando el comando -setcredentials de la utilidad ssoclient.exe.

 

Habilitar el mapeo

Al igual que muchas otras operaciones en la infraestructura de SSO, no basta con definir el mapeo de las cuentas entre el dominio Windows y la aplicación afiliada; es necesario habilitarlo posteriormente.

 

Para esto, puede usarse el siguiente comando:

 

trestrepo@DOMAIN>ssomanage -enablemapping DOMAIN\trestrepo SAP

Using SSO server on this computer

The operation completed successfully.

 

El comando -enablemapping toma como argumentos el nombre de la cuenta Windows para la cual se va a habilitar un mapeo y el nombre de la aplicación afiliada cuyo mapeo se va a habilitar. Al igual que con la creación del mapeo mismo, esta operación puede ser realizada directamente por el usuario mediante la opción -enablemapping de la utilidad ssoclient.exe.

 

 

Conclusión

En este artículo introducimos los primeros detalles necesarios para administrar y sacar provecho de la infraestructura proveída por el Enterprise Single Sign-on. Esta es apenas una pequeña muestra de cómo administrar el SSO y como iniciar en la implantación del uso del SSO para hacer uso del mismo en el desarrollo e implantación de soluciones de integración empresarial entre múltiples aplicaciones.