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� 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�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.
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:
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.
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.