Soluciones de SSO para operadores móviles

“Soluciones de Single Sign-On para los operadores móviles”
Miguel Ángel Monjas Llorente, Manuel Lorenzo Hernández
Systems Management – Core Unit Service Network and Applications, Ericsson España, S.A.
Vía de los Poblados, 13, 28033 Madrid
Telf: +34 91 339 {3605, 3037}, Fax: +34 91 339 2538
E-mail: {miguel-angel.monjas, manuel.lorenzo}@ericsson.com
Resumen
Esta ponencia aborda globalmente la problemática de la construcción y despliegue de
soluciones de Single Sign-On (SSO) para operadores móviles. En primer lugar, se introduce el
contexto tecnológico y económico en el que surge la necesidad para el operador móvil de
desplegar una infraestructura que habilite el SSO. Seguidamente, se revisan los principales
factores condicionantes a tener en cuenta a la hora de especificar y seleccionar una solución de
SSO concreta que se ajuste a las necesidades y estrategia del operador. Hecho este análisis, se
presenta un marco (o framework) arquitectural que contempla todos los principios y elementos
que, independientemente de los condicionantes propios de cada operador, constituirán la
esencia de su solución de SSO. Finalmente se muestran las consideraciones a tener en cuenta en
el proceso de despliegue de las soluciones, proceso por el que los sistemas que configuran la
solución de SSO se integran efectivamente en la red del operador y se planifican y ponen en
producción.
1. Introducción
Las perspectivas de negocio de los operadores móviles,
especialmente en Europa, han cambiado radicalmente en
los últimos años. Partiendo de unas previsiones que
hablaban de beneficios casi ilimitados, derivados de la
introducción de tecnologías consideradas como
revolucionarias, se ha pasado a la constatación de la
testadura realidad. Por un lado, tecnologías que se
presentaban como un hito, tales como WAP, no han sido
precisamente un éxito (o al menos un éxito como tales
tecnologías). Mientras, los servicios basados en
mensajes cortos (descarga de tonos y logos,
comunicaciones con programas de televisión, votaciones
en línea... por citar algunos) han experimentado contra
pronóstico un gran auge. Finalmente, la mensajería
multimedia (MMS), que trata de beneficiarse del tirón
de los mensajes cortos y de su atractivo visual para el
usuario, o los juegos que se descargan en el terminal, se
encuentran en un estado de desarrollo muy temprano y
tienen por demostrar su éxito.
Fruto de estas experiencias, el operador móvil parece
haber sacado varias conclusiones. La primera y más
importante, que el usuario no está dispuesto a comprar
tecnología sino servicios, y sólo si son confiables, útiles,
sencillos de usar y de fácil acceso1. La segunda, que la
clave consiste en explotar y estrechar la relación que ya
tienen con sus abonados. Y finalmente, que para poder
ofrecer un catálogo de servicios a los usuarios finales
amplio y atractivo será preciso reducir al mínimo el
coste del ciclo de vida de los servicios, incorporando
para ello una serie de funciones comunes en sus redes de
servicios y desplegando un abanico de modelos de
negocio que haga que todos los actores de la cadena de
1
Véase, por ejemplo, el caso de Vodafone Life!, en el
que en énfasis se ha puesto en los servicios ofrecidos y
no en las tecnologías que los sustentan.
valor (no sólo el propio operador) obtengan una justa
retribución.
El concepto de Single Sign-On (SSO) se integra
perfectamente dentro de estas conclusiones. Aunque
existen múltiples definiciones del término (casi tantas
como actores implicados en el negocio o
estandarización de SSO), se utilizará una definición
bastante simple: Single Sign-On (SSO) es una
funcionalidad que permite a los usuarios
autenticarse una única vez y acceder, sin tener que
reautenticarse, a todos los servicios que aceptan tal
tipo de autenticación2.
Se trata, como puede observarse, de una definición
totalmente centrada en la experiencia de usuario. Una
primera interpretación, desde la perspectiva del
operador móvil, puede ser que SSO es “una
funcionalidad común de una red de servicios que, al
hacer más sencilla la experiencia de usuario, potenciará
el uso de las aplicaciones móviles y el anhelado
despegue de Internet móvil”. No obstante, esta
interpretación se queda en la superficie del problema
que se pretende resolver. En efecto, para desplegar esta
funcionalidad común, será preciso que el operador
móvil gestione de forma coordinada la autenticación de
usuarios (independientemente de la red desde la que
acceda y del método de autenticación empleado) y la
transferencia de pruebas de tal autenticación a
servicios o proveedores de servicios (PPSS), la
autorización de servicios (no sólo aquellos basados en
HTTP) y la gestión de identificadores de usuario
2
Es preciso tener en cuenta que no siempre es posible
distinguir al usuario del terminal que usa y que, en
ciertas circunstancias, lo que realmente se autentica es el
terminal. De hecho, el usuario puede no tener
autenticarse explícitamente ninguna vez.
(proporcionando a cada servicio o PS el identificador
que precisen).
2. Variables de análisis
A la hora de diseñar una solución de SSO para un
operador móvil, es preciso no limitarse a las variables de
análisis pertinentes relacionadas con SSO de forma
genérica, abordando especialmente aquellas que resultan
específicas del operador móvil.
2.1.
Modelo de negocio
La experiencia de SSO se define siempre con respecto a
unos servicios que son consumidos por el usuario.
Cuando se habla de modelo de negocio en el ámbito de
SSO, se está refiriendo, por una parte, a saber cuál es la
entidad que de hecho presta los servicios al usuario, por
otro, a identificar la entidad en nombre de la que se
prestan dichos servicios y, finalmente, a describir qué
relación existe entre el proveedor del servicio (PS) y el
operador (en el caso de que la entidad proveedora de
servicios no sea el propio operador).
El conjunto de parámetros que caracteriza la relación
entre operador y PS es tremendamente extenso3. Se
pueden distinguir, de modo ilustrativo, los siguientes:





Branding: dependiendo de que el servicio se
ofrezca bajo la marca del operador o bajo la del PS.
Integración en la oferta de servicios del
operador: los servicios proporcionados por el PS
pueden integrarse en los paquetes de servicios
ofrecidos por el operador a sus usuarios o ser
accesibles y suscribibles sin intervención del
operador.
Gestión de la suscripción al servicio: el PS puede
crear las cuentas de usuario y cualquier soporte
necesario para el funcionamiento del servicio
mediante interacción directa con el usuario, o
usando al operador móvil como intermediario, de
forma que es el propio el operador el que gestiona
las peticiones de suscripción del usuario a los
servicios y se encarga de notificarlo al PS.
Gestión de la autenticación: el PS puede gestionar
directamente la autenticación del usuario o confiar
en la autenticación realizada por el operador (es
superfluo decir que cuando el PS gestiona por su
cuenta la autenticación, no tiene sentido hablar de
SSO, puesto que cada servicio exigirá una
autenticación distinta al usuario, destruyendo la
experiencia de SSO).
Acceso a recursos de usuario proporcionados por
el operador, ya sean datos del usuario (como la
localización) o capabilities que tienen una
dimensión de usuario (como el acceso a servicios de
mensajería, tales como SMS o MMS...). Se trata de
determinar qué recursos del usuario son accesibles

y con qué condiciones. Entre las condiciones
podrían encontrarse el estatus del usuario (online o
no4), que el identificador de usuario que debe
proporcionar el PS sea el correcto o que la entidad
en nombre de la que se efectúa la petición de
recursos (el propio usuario cuyos recursos se
invocan, un tercero...) esté autorizada.
Nivel de confianza entre el operador y el PS: en
dónde entran consideraciones tecnológicas acerca
de la seguridad de las comunicaciones entre ambos
y del grado de validez que se otorgan a las
aseveraciones hechas por cada parte.
Del listado anterior (que no es exhaustivo) se puede
comprender claramente que no es posible categorizar de
modo sencillo las relaciones entre existen entre el
operador móvil y los PPSS con los que alcanza
acuerdos. De tal modo que es difícil describir el modelo
de negocio que implementa el operador. No obstante, y
para poder analizar los escenarios de SSO, es posible
distinguir tres roles diferentes tomados por el operador
móvil, dependiendo de quien presta efectivamente los
servicios y bajo qué marca. En cualquier caso, es
preciso indicar que tales roles dependen de cada
relación concreta entre el operador y el PS y, por tanto,
aquél tomará todos los roles al mismo tiempo. Los roles
que se pueden distinguir son los siguientes:



El operador alberga y opera el servicio. El operador
es un proveedor de servicios propios (este es el
escenario que se denomina habitualmente walledgarden y en el que no tiene relevancia la relación
con ningún PS externo, puesto que no hay tal).
El operador incorpora a su oferta servicios de
proveedores de servicios externos con los que se ha
establecido un acuerdo. El operador gestiona la
suscripción de usuarios y, a menudo, gestiona el
pago (similar a i-mode). El operador es un
proveedor de servicios virtual, puesto que ofrece
servicios ajenos bajo su propia marca.
El operador llega a un acuerdo con PPSS externos
por el que éstos confían en la autenticación
realizada por el operador. Esta sería una traslación
inmediata, por parte del operador móvil, del modelo
de LAP5 (véase Apéndice I. Estándares), en el que
el operador es un IdP (proveedor de identidad)
hacia otros PPSS.
3
Genéricamente, podemos afirmar que estos parámetros
se encuentran regulados por el Acuerdo de Nivel de
Servicio (SLA, Service Level Agreement) firmado entre
el operador y el PS
4
Por ejemplo, es posible que sólo se pueda acceder a
recursos de usuario si este está conectado.
5
Liberty Alliance Project
mediante WAP para personalizarlo (fase User-ToService).
2.2.3.
Granularidad de los servicios
Cuando el operador móvil ofrece servicios bajo su
propia marca, integra servicios individuales dentro de
oferta de servicios. Sin embargo, en entornos federados,
es responsabilidad del PS definir su oferta de servicios,
por lo que el operador sólo es consciente del PS externo
como un todo, no de servicios individuales que éste
ofrece.
Figura 1. Roles de negocio del operador móvil
2.2.
Servicios integrados en el esquema de SSO
2.2.1.
Tecnología de servicios
Aunque los estándares de SSO emergentes imaginan un
mundo en el que se accede a todos los servicios
mediante HTTP (ya sea usando un navegador “clásico”
o un cliente de Web Services), la realidad es que en el
entorno móvil existen otras tecnologías de servicios
que no siguen tales paradigmas (incluso aunque utilicen
HTTP como portadora, como MMS). Por ejemplo, se
puede considerar la mensajería persona a persona (MMS
o SMS), aplicaciones basadas también en mensajería
(como la descarga de tonos y logos o la recepción de
alarmas), juegos Java, portales de voz, aplicaciones de
streaming, etc. Por tanto, el tipo de servicios ya
establece una “divergencia” entre los estándares de SSO
existentes y la realidad de los servicios ofrecidos por los
operadores móviles.
2.2.2.
Paradigma de interacción de servicios
Los servicios siguen habitualmente un esquema UserTo-Service, en el que es el usuario el que accede al
servicio. Por ejemplo, este es el paradigma de los
servicios a los que se accede mediante HTTP.
No obstante, existen otros servicios, que siguen un
paradigma que es posible denominar Service-To-User,
en el que es el servicio el que lleva la iniciativa en la
entrega de algún tipo de contenido o evento al usuario
(como es el caso de alarmas). En este tipo de servicios
es importante tener cuenta el usuario en nombre del cual
se entrega este servicio o contenido (por ejemplo, puede
ser en nombre del propio usuario, o de un tercero).
Finalmente, es preciso tener en cuenta que un mismo
servicio puede seguir ambos paradigmas dependiendo
de la fase de ejecución del servicio. Piénsese en un
servicio que entrega gráficos bursátiles mediante MMS
(fase Service-To-User), al cual el usuario accede
2.2.4.
Autorización de servicios
Una característica importante de los servicios es la
posibilidad de introducir decisiones de autorización del
acceso a los servicios. Los esquemas de control de
acceso web, de los que el concepto de SSO es heredero,
basaban el control de acceso al servicio en la
suscripción al servicio (o, de modo más amplio, en la
pertenencia del servicio al perfil del usuario). La
traslación de este modelo es simple: el operador ofrece
al usuario la suscripción a servicios o paquetes de
servicios, de forma que, posteriormente, el usuario
podrá acceder a dichos servicios sólo si los ha subscrito
anteriormente.
No obstante, la autorización para lanzar un servicio
basada en la pertenencia o no del servicio al perfil de
usuario no es siempre un componente de una solución
de SSO. Por ejemplo, el operador podría (de hecho es lo
que ocurre habitualmente) dar acceso a cualquier
servicio que se encuentre en su catálogo de servicios y
posteriormente efectuar el cargo correspondiente por el
uso del servicio al usuario. Sin embargo, hay situaciones
en las que es deseable proceder a una verificación de
que el servicio al que un usuario desea acceder ha sido
previamente suscrito. De esta forma, cuando un usuario
quiere lanzar un servicio, la solución de SSO verificaría
si el usuario ha suscrito el servicio y, si no es así, lo
redirigiría a una página de auto-registro, para proceder a
un provisionado ordenado del servicio y de los enablers
implicados en la prestación del servicio.
Por otra parte, en escenarios de negocio federados
puros, la autorización de servicios precisa del concurso
no sólo del operador como IdP, el cual simplemente ha
de verificar que realmente hay un enlace (o federación
de cuentas) entre la cuenta del usuario en el PS y el
perfil del abonado móvil y emitir una aseveración de
autenticación hacia el PS que va a prestar el servicio,
sino también del propio PS, el cual se responsabiliza de
la autorización final del acceso a cualquiera de los
servicios que ofrece.
A pesar de todo, es preciso indicar que el operador
móvil puede introducir decisiones de autorización
basadas en la aplicación de algún tipo de política,
usualmente fijada por el propio usuario. Por ejemplo,
antes de permitir el acceso a un servicio (en el caso en el
que el operador presta el servicio) o proceder a la
provisión de aseveraciones de autenticación (en el caso
de los escenarios federados), la solución de SSO podría
proceder a la evaluación de políticas, por ejemplo,
relacionadas con el momento del día o la semana en el
que se quiere acceder.
Todo lo que se ha descrito hasta ahora en este capítulo
se refiere a servicios que siguen el paradigma User-ToService. Sin embargo, es posible considerar también
esquemas de autorización en los servicios denominados
Service-To-User. Si bien también es posible basar estas
decisiones en el perfil de usuario, lo cierto es que la
autorización en este caso estará basada generalmente en
consideraciones de privacidad del propio usuario.
Respecto a este tipo de decisiones, es posible distinguir
diferentes niveles:



El más clásico de listas blancas y listas negras, ya
sean explícitamente configuradas por el usuario o
predeterminadas (configuradas por el operador). Se
define una serie de servicios (o PPSS) que pueden
(listas blancas) o no pueden (listas negras) acceder
a los recursos del usuario (en el entorno que se esté
analizando, se trataría de la entrega de servicios o
contenidos al usuario, no del acceso a datos tales
como la localización). Las listas blancas pueden
estar constituidas por los servicios o PPSS en los
que el usuario mantiene una suscripción.
El mecanismo de listas blancas es idóneo en
escenarios en los que el conjunto de servicios o
PPSS es variable. El de listas negras lo es en
entornos en el que el conjunto de servicios o PPSS
es más o menos estático (caso improbable) o en los
que las listas blancas están constituidas por
entidades con las que se mantiene una suscripción
(esto es, el usuario superpone una lista negra de
entidades a las que no quiere permitir acceso a sus
recursos sobre la lista blanca implícita de entidades
con las que tiene una suscripción).
Un esquema más sofisticado en el que los servicios
o PPSS autorizados para acceder a los recursos del
usuario sólo pueden hacerlo si lo hacen en nombre
de otro usuario al que explícitamente se ha
autorizado (por descontado, entre estos usuarios
autorizados está él mismo).
Más variaciones del esquema de listas en los que
los servicios o PPSS autorizados para acceder a los
recursos del usuario sólo pueden hacerlo si
demuestran, de forma fehaciente, que el usuario ha
requerido previamente sus servicios.6
Finalmente, es preciso tener en cuenta que los servicios
(o PPSS) cuyo acceso gestiona la solución de SSO van a
requerir lo que se denomina contexto de servicio. Este
contexto de servicio (que puede ser diferente
dependiendo del usuario) incluye los datos que
necesitará un servicio (o PS) para que el servicio se
6
En el caso de los servicios premium de mensajería
(SMS), un PS sólo puede enviar un logo o tono (y
cobrar este servicio) si el usuario ha requerido
previamente el servicio, mediante el envío de un
mensaje corto..
ejecute correctamente. Un elemento prácticamente
obligatorio del contexto es un identificador de usuario,
el cual servirá para identificar al usuario y también, para
acceder posteriormente a recursos del usuario en el
dominio del operador. Otros datos pueden ser el tipo e
instante de autenticación, la red de acceso utilizada...
2.3.
Tipo de acceso
Aunque el tipo de acceso sobre el que se ofrecen los
servicios parece obvio (el terminal móvil), existen
matices tecnológicos y de negocio importantes.
Por una parte, es posible considerar lo que
denominamos acceso GSM (en principio no se
abordarán otras tecnologías como TDMA o CDMA).
Aunque hablar de acceso GSM puede resultar equívoco
(puesto que existen accesos de datos a través de GSM),
se ha escogido este término para englobar accesos a
servicios que utilizan las capacidades nativas de GSM,
ya sea voz, como en un portal de voz, o señalización,
como SMS7.
No obstante, el tipo de acceso más común es el que se
puede denominar acceso de datos. Se trata de accesos
GPRS o CSD8 sobre GSM. Es mediante los accesos de
datos sobre los que se están ofreciendo en la actualidad
los servicios basados en WAP, descargas de juegos,
mensajería multimedia (MMS)...
También se puede considerar el denominado acceso IP
Multimedia (IMS). IMS es una arquitectura de red
definida por 3GPP9 para ofrecer servicios IP en UMTS.
Si bien no ha sido aún implantada, cualquier solución de
SSO tendrá que tener en cuenta la existencia futura de
tal acceso.
También es preciso considerar el acceso WLAN. Si
bien es cierto que los accesos mediante WLAN no
requieren la existencia de operadores móviles, éstos ya
están considerando la reutilización de la tarjeta SIM
para la autenticación del terminal de usuario en accesos
WLAN10 y el intercambio de las claves utilizadas para
garantizar la integridad y confidencialidad de la
comunicación posterior. No obstante, por la propia
configuración y despliegue de este tipo de redes, el
acceso WLAN no puede considerarse tan confiable
como los accesos tradicionales (GSM, GPRS...)
Finalmente, es posible distinguir un acceso con
autenticación explícita a nivel de aplicación. Este
acceso es útil en dos escenarios. En general, se
considera este acceso cuando la red de acceso real no
7
Quizá el término clásico usado en telecomunicaciones
CS (Circuit-Switched) podría ser adecuado. Pero dado
que los mensajes cortos, aun siendo tráfico, usan los
canales de señalización, hemos preferido el término
escogido.
8
Circuit-Switched Data
9
3G Partnership Project
10
IETF está estandarizando EAP-SIM y EAP-AKA para
permitir este uso de la tarjeta SIM en accesos WLAN.
pertenece al operador (en general, cuando no está
implicada ni la tarjeta SIM del usuario ni su terminal
móvil). Un caso típico es el de auto-configuración de los
servicios, en los que es más sencillo y cómodo acceder
utilizando un ordenador desde una red que no es
necesariamente la del operador, por ejemplo, la
conexión de banda ancha del usuario. Este modelo
puede extenderse y permitir acceso no sólo a servicios
auxiliares como los de auto-configuración sino también
a servicio finales, que pueden englobarse en un portal
accesible también desde Internet. Otro escenario es
aquel en el que la red de acceso no se considera
confiable y se trata como una red IP cualquiera (una
mera red de transporte). En ambos escenarios, se
requerirá una autenticación explícita, por el método que
se considere oportuno puesto que no puede reusarse la
autenticación nativa del acceso.
2.4.
Método de autenticación
Existe una gran variedad de métodos de autenticación.
Basados en uno o en varios factores, la lista podría ser
interminable: login y password, certificados digitales
(ya sean X.509v3 o WTLS), one-time password, tokens,
biométrica... Y cualquiera de estos métodos puede ser
usado en el que se ha denominado acceso con
autenticación explícita a nivel de aplicación en el
capítulo anterior.
Sin embargo, lo realmente interesante es que los accesos
más importantes gestionados por operadores móviles
(acceso GSM o acceso de datos) usan un método de
autenticación que es posible denominar nativo (mediante
tarjeta SIM11). Es evidente que la aspiración de los
operadores móviles es reusar transparentemente dicha
autenticación.
2.5.
Desconexión (Log-Out)
En general, se prevé que el acceso del usuario a los
servicios se va a llevar a cabo mediante un terminal
móvil. En el caso concreto de un terminal GPRS (en el
que la propia naturaleza de la red permite una estar
siempre conectado, always on), el operador podría
proporcionar varios puntos de acceso (APNs12) para
acceder a diferentes tipos de servicios y funcionalidades.
No obstante, la tendencia actual en los operadores
móviles es utilizar un único APN para todos los
servicios que proporcione (dejando el uso de diferentes
APNs para su función original; esto es, para indicar cual
es la red externa a la que quieren acceder, como en el
caso de redes corporativas). Si ocurre esto, y si además,
se desea reaprovechar la autenticación del acceso, se
puede llegar a una situación en que el usuario tiene que
desactivar su conexión si quiere desconectarse de la red
de servicios. Es preciso, por tanto, encontrar un
equilibrio entre la facilidad de uso y la seguridad en el
uso de los servicios (puesto que un robo del terminal
podría llevar a un uso indiscriminado de servicios,
situación, por otra parte, en nada diferente a la situación
actual respecto a servicios de voz).
En cualquier caso, es posible que los servicios a los que
el usuario accedió durante su sesión deban recibir una
notificación cuando el usuario se desconecta, a fin de
eliminar las sesiones de servicio correspondiente.
Por supuesto que conexiones que no tienen lugar desde
el terminal del usuario no tienen que afrontar este
dilema.
2.6.
Carácter Geográfico y Organizativo del
Operador
En último lugar, es necesario considerar el carácter
geográfico/organizativo del operador. Es preciso tener
en cuenta si el operador sólo está presente en un país o
forma parte de un grupo multinacional (sobre todo, si
este operador global desplegará una infraestructura
común a todas las entidades locales). Además, el
roaming de servicios también es importante.
3. Elementos y principios arquitecturales
Para proporcionar una descripción funcional del proceso
de SSO en los operadores móviles y de los componentes
implicados en una solución de SSO, es necesario
comenzar por una vista dinámica del proceso. Puede ser
esta:
“Cuando el usuario se autentica en la red de servicios,
se crea una sesión maestra con datos relevantes del
proceso de autenticación (red de acceso, tipo y
fortaleza de autenticación...) Cada vez que el usuario
trate de acceder a un servicio o PS, se determina si es
necesario autorizar el acceso a la aplicación y, en su
caso, se toma dicha decisión. En cualquier caso, se
entrega al servicio o PS un contexto de servicio que
incluirá, al menos, un identificador de usuario
apropiado y, opcionalmente, aseveraciones sobre la
autenticación del usuario (tipo, fortaleza, instante...).
Finalmente, una vez que el usuario abandona la red de
servicios, la sesión maestra es eliminada y se envía a
las aplicaciones a las que accedió el usuario una
notificación al respecto.”
Además, aunque es tentador reducir la vista dinámica al
caso de uso de “tráfico”, es preciso considerar qué
ocurre antes de que pueda llevarse a cabo el proceso de
SSO. En general, es necesario que el operador y el
servicio o PS se hayan puesto de acuerdo en qué
identificador de usuario van a compartir, qué contexto
de servicio necesitan estos últimos y todo ello, con el
consentimiento del usuario.
11
Recordemos que usando la terminología de
autenticación, el acceso a una red GSM usa un método
de autenticación de dos factores, porque hay que insertar
la tarjeta SIM en el terminal móvil (algo que se tiene) y
escribir el PIN al encender el móvil (algo que se sabe)
12
Access Point Name
A partir de esta vista dinámica, se distinguen fácilmente
los componentes de una solución de SSO:





Gestión centralizada de la autenticación y la sesión
de usuarios
Gestión centralizada de los identificadores de
usuario
Gestión centralizada de la autorización de servicios
y la provisión del contexto de servicio
Single Log-Out (SLO)
Gestión del perfil de usuario
3.1.
Gestión centralizada de la autenticación y
de la sesión de usuarios
Es preciso gestionar de una forma centralizada el modo
en el que se autentican los usuarios que acceden a la red
de servicios. Esta gestión centralizada no implica
necesariamente la existencia de una entidad que
centralice la autenticación de usuarios, puesto que
existen demasiados y muy diversos métodos de
autenticación (que pueden depender, o no, de la red de
acceso).
Lo que sí se considera necesario es proceder, si la
autenticación es correcta, a crear una sesión maestra
(aquella que recoge la “presencia” del usuario en la red
de servicios) conteniendo datos relacionados con la
autenticación que serán utilizados posteriormente para la
autorización de servicios o la propagación de
aseveraciones de autenticación hacia PPSS externos
(utilizando las especificaciones de LAP Id-FF, por
ejemplo). La sesión maestra se gestionará en una
entidad central y contendrá no sólo datos relativos a la
autenticación o el acceso, sino también relativa a los
servicios que han sido autorizados o a los PPSS hacia
los que se ha propagado la autenticación.
3.2.
Gestión centralizada de los identificadores
de usuario
El entorno de los operadores móviles se ha enfrentado
históricamente a la gestión de diferentes identificadores
de usuario. Desde los números de teléfono (MSISDN) al
IMSI, o a los nombres de usuario utilizados para
acceder a ciertos servicios de personalización o consulta
vía web, pasando por el SIP-URL usado en IMS. En
cualquier caso, la cantidad de identificadores ha sido
hasta ahora pequeña y de relativamente fácil gestión.
La introducción de una solución de SSO, en la que
existen no sólo servicios proporcionados por el propio
operador, sino también por terceras partes, impone la
necesidad de gestionar un número muy grande de
identificadores de usuario (potencialmente un
identificador por servicio o PS al que accede, debido a
consideraciones de privacidad).
El reto que supone la gestión de identificadores
trasciende el ámbito de la solución de SSO y debe ser
consistente con el resto de soluciones existen en el
operador, fundamentalmente en los escenarios B2B
(OSA/Parlay, Web Services, LAP Id-WSF13...) Esto es
así porque, previsiblemente, el servicio al que accede un
13
Identity Web Services Framework, segunda serie de
especificaciones de LAP
usuario con SSO, interactuará posteriormente con el
dominio del operador referenciando al propio usuario
(para pedir recursos tales como la información de
localización, para enviarle un mensaje...), utilizando
para ello el identificador que la solución de SSO le ha
proporcionado.
Se plantea la introducción de una entidad centralizada
para la gestión del ciclo de vida de los identificadotes
de usuario. Esta entidad se encargará de la generación
de identificadotes, determinando qué identificador del
usuario es necesario entregar a un servicio o PS dado
como parte del contexto de servicio (considerando las
restricciones de privacidad implicadas), creando
identificadores temporales si es necesario.
3.3.
Gestión centralizada de la autorización de
servicios y la provisión del contexto de servicio
Como ya se ha citado anteriormente, los servicios (o
PPSS) integrados en una solución de SSO requieren en
general un contexto de servicio para poder funcionar (al
menos aquellos que siguen el paradigma User-ToService). El contexto de servicio mínimo consiste en un
identificador de usuario. En efecto, el servicio necesita
saber quién es el usuario que accede al servicio (para
identificarle) y también para poder referenciarlo
posteriormente en el dominio del operador. Otros
elementos de dicho contexto de servicio pueden ser el
tipo de autenticación, el estado de roaming, la red desde
la que accede, el instante de autenticación...
Adicionalmente, es posible que la entrega del contexto
de servicio se haga como consecuencia de una decisión
de autorización positiva (se consideran de nuevo de
servicios que siguen el paradigma User-To-Service).
Se recomienda la introducción de una entidad que
centralice la toma de decisiones sobre la autorización
del lanzamiento de servicios (de cualquier tecnología)
por el usuario. Ahora bien, se hace preciso seguir un
enfoque por capas, que distinga entre la decisión y la
ejecución (enforcement) de dicha decisión. Si bien la
decisión será centralizada, la ejecución de las decisiones
de autorización podrán tomarse en puntos diversos.
Cabe aquí señalar dos paradigmas en la ejecución de
decisiones de autorización: el de proxy y el de broker.
En el primero, todo el tráfico de usuario pasa por un
punto (o varios) y es ahí dónde se ejecutan las
decisiones de autorización (caso típico de soluciones de
control de acceso basadas en proxies HTTP inversos).
Este esquema es deseable si se desea usar este punto
para otras funciones tales como un control continuado
de la ejecución del servicio. También es aplicable a
otros tipos de paradigmas de servicios, como los
Service-To-User (en los el acceso al dominio del
operador también se hace mediante un proxy). La
desventaja de estos esquemas es que pueden suponer
fácilmente un cuello de botella. El esquema de broker es
el utilizado por Id-FF de LAP (también por el sistema
Passport de Microsoft). Su principal ventaja es que
separa el tráfico del servicio del tráfico de
“señalización”, si bien su utilización se concentra
actualmente en entornos HTTP.
Cuando la decisión sea positiva, se incluirá el contexto
de servicio dentro del resultado, y será responsabilidad
del punto de ejecución adecuar el formato de dicho
contexto a lo que espera el servicio (aseveraciones
SAML, en el caso de Id-FF de LAP, por ejemplo). Si no
hay decisión implicada, los puntos de ejecución se
responsabilizarán simplemente del formateado del
contexto de servicio.
3.4.
Single Log-Out (SLO)
Single Log-Out (SLO) es, de alguna forma, la
funcionalidad “inversa” de SSO, puesto que cuando el
usuario decide abandonar la red de servicios, las
sesiones en todos los servicios o PPSS deben recibir una
notificación de la desconexión.
Una entidad debe encargarse de enviar tales
notificaciones cuando un usuario desconecta. Para ello,
utiliza los datos guardados en la sesión maestra de
usuario, en donde se habrán almacenado los servicios o
PPSS a los que ha accedido el usuario durante la
duración de la sesión.
3.5.
Gestión del Perfil del Usuario
Por lo que respecta a la problemática de SSO, la gestión
del perfil del usuario es un componente fundamental de
cualquier solución en tanto que comprende cuatro
aspectos fundamentales que influyen en todo el proceso:

La información necesaria para la autenticación del
usuario (passwords, credenciales...)
 El perfil de servicios suscritos en el entorno del
operador, cuando los servicios son proporcionados
por este bajo su marca (ya sean propios o de
terceras partes)
 El perfil de usuario de servicios provistos por
terceros (en terminología de LAP, el conjunto de
cuentas en PPSS que han sido federadas)
 El perfil de privacidad del usuario (políticas de
privacidad establecidas por el usuario).
Todos estos elementos de información, junto con
aquellos pertenecientes a la sesión maestra del usuario,
alimentan las decisiones que se dan a lo largo del
proceso de SSO en sus distintas variantes y escenarios.
A esto hay que añadir que hay que consultar en tiempo
real información distinta para cada usuario y que en
entornos móviles las bases de clientes son dos o más
ordenes de magnitud superiores a las de los entornos
corporativos. Por tanto, se puede afirmar, sin temor a
equivocarse, que la infraestructura de gestión y
almacenamiento tanto del perfil como los datos
dinámicos (sesión maestra) del usuario es el componente
que va a condicionar en mayor medida el rendimiento, el
tiempo de respuesta y la escalabilidad de la solución. De
ahí que el adecuado modelado y distribución de los
datos implicados y el correcto dimensionamiento y
elección de la tecnología de los sistemas de
almacenamiento sean estrategias fundamentales a seguir
a la hora de construir una solución de SSO.
Figura 2. Componentes de una solución de SSO
4. Consideraciones de despliegue
Una vez se han definido los requisitos relativos a SSO,
se ha especificado una solución arquitectural objetivo
que satisface tales requisitos, se han seleccionado los
proveedores más adecuados y adquirido –y
eventualmente personalizado– los productos que van a
forman parte de esa solución, más allá del clásico
proceso de integración de esos componentes entre sí, es
imprescindible planificar y ejecutar cuidadosamente el
proceso de despliegue en y hacia la red de servicios de
esta nueva funcionalidad común.
Es importante hacer notar que el despliegue de una
funcionalidad común como ésta, que impone un cambio
conceptual en la concepción de la red de servicios, aún
garantizada la interoperabilidad entre componentes o
asumida la existencia de estándares que agilicen el
proceso, no se va a reducir en ningún caso a
simplemente instalar y configurar una serie de
productos.
Además, este proceso de despliegue de SSO estará
típicamente encuadrado en el marco más general de la
estrategia de horizontalización de la red de servicios del
operador móvil, dónde otras funciones comunes y
estructurales que igualmente se hayan definido
(provisionamiento común, event charging, despliegue
de servicios, interfaces B2B, etc.) serán introducidas
también para dar forma a la nueva red de servicios. En
este contexto, será importante, pues, mantener una
visión global del estado y evolución de esta red para
determinar en qué preciso instante, en relación con qué
otros proyectos y en colaboración con qué otras
organizaciones involucradas dentro del operador se debe
llevar a cabo el despliegue de la funcionalidad de SSO.
Habiendo establecido todo ello, el operador móvil se
encontrará con una serie de condiciones de contorno
específicas por evaluar, entre las que estarán presentes
consideraciones como las distribuciones de tráfico
actual y estimadas, con la finalidad de dimensionar
adecuadamente la infraestructura de SSO, y la influencia
de este nuevo concepto en los elementos con los que ha
de integrar, para tratar de minimizar impactos que
pudieran obstaculizar el proceso de asegurar la vital
implantación efectiva del SSO, en todos los sistemas
implicados de la red y al nivel de ambición requerido
por el operador móvil.
5. Conclusiones
SSO es un término de moda. Tras la publicación de la
primera fase de las especificaciones de LAP, parecía
que los problemas derivados de la fragmentación y la
falta de estándares quedaban resueltos y que un proceso
consistente de implantación de soluciones de SSO podía
comenzar. Sin embargo, desde el punto de vista de los
operadores móviles, la realidad no resulta ser tan
sencilla, puesto que los requisitos y parámetros a
examinar son mucho más complejos que los que puedan
existir en la Internet “fija”, tal como se ha examinado en
la presente ponencia.
los PPSS, de forma que el usuario puede acceder a ellos
transparentemente sin necesidad de reautenticarse.
Recientemente, Microsoft e IBM han presentado una
especificación, WS-Federation [4], que forma parte de
su esfuerzo para construir un marco de seguridad para
Web
Services
(WS-Security).
Aunque
esta
especificación presenta numerosos puntos de solape con
el Id-FF de LAP, no existe aún consenso acerca de si se
abrirá una dañina guerra de estándares o se conseguirá
algún tipo de acuerdo.
Referencias
Como consecuencia, la implantación de una solución de
SSO no puede verse como un hecho aislado dentro de la
estrategia del operador móvil, sino que se encuadra (o,
al menos, debe encuadrarse) dentro de un cambio
conceptual en la concepción de la red de servicios: La
estrategia de horizontalización, dentro de la que se
definirán otra serie de funciones comunes de la red de
servicios, no sólo aquellas relacionadas con SSO.. Solo
dentro de una estrategia consistente de horizontalización
de la red de servicios, se conseguirá un despliegue con
éxito de una solución de SSO.
Finalmente, es preciso advertir que la suma de los
componentes funcionales de SSO es mayor que el todo.
Y esto es así porque la mayor parte de las funciones
horizontales que comprende SSO (por poner un
ejemplo, la gestión de identificadores de usuario) van
más allá de los escenarios de SSO (piénsese, por
ejemplo, en el acceso de un usuario a un servicio que
posteriormente le enviará mensajes multimedia). Por
tanto, es preciso que los componentes funcionales cuya
implantación es necesaria para el despliegue de
soluciones de SSO sean también utilizados por el resto
de soluciones del operador móvil (los casos más
evidentes son aquellas soluciones situadas en la interfaz
B2B que proporcionan acceso a recursos de usuario).
Apéndice I. Estándares
La aparición de estándares de SSO es un acontecimiento
relativamente nuevo. No obstante, no se trata de un
campo tan nuevo, puesto que es heredero directo de los
esquemas de acceso web14. No obstante, no fue hasta el
año 2002 en el que la industria se organizó en el
denominado Liberty Alliance Project (LAP), en un
principio en respuesta al esquema de SSO patrocinado
por Microsoft, y produjo una serie de especificaciones
denominadas LAP phase 1 y posteriormente Identity
Federation Framework (Id-FF) [3], también conocido
como SSO federado. En estas especificaciones, se
define una entidad, denominada Identity Provider (IdP),
que se encarga de autenticar al usuario y proporcionar
aseveraciones de tal autenticación hacia otras entidades,
14
Estos esquemas, tales como Tivoli Access Manager de
IBM o getAccess de Entrust, proporcionaban una
solución de SSO para aplicaciones empresariales,
incluyendo decisiones de autorización a la hora de
permitir el acceso a tales aplicaciones.
[1] M.A. Monjas y M. Lorenzo, “El ‘Single Sign-On’ y
los operadores móviles”, SIC, Seguridad en
Informática y Comunicaciones, Editorial Coda,
Madrid, nº 54, abril de 2003, pp 74-76.
[2] J.L. Mariz, “Autenticación unificada y servicios
basados en identidad para operadores de
telecomunicaciones móviles”, Forum LusoEspanhol Inovaçao em Telecomunicaçoes, Aveiro,
23 y 24 de junio de 2003.
[3] Liberty Alliance Project, “Liberty Alliance Version
1.1
Specification
Suite”,
http://www.projectliberty.org/specs/archive/v1_1/in
dex.html, 15 de enero de 2003
[4] BEA, IBM, Microsoft, RSA Security y VeriSign,
“Web Services Federation Language (WSFederation)”,
http://www106.ibm.com/developerworks/webservices/library/
ws-fed/, 8 de julio de 2003