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� 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�n 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� 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 defini� 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� 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� 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.