Por: Tomas Restrepo
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.
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:
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 : *********
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.
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.
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.
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:
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.
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.