¿Necesita revisión el single sign-on?

4 de Febrero de 2008 — Manuel Delgado

El  artículo "Single Sign-on - is it really desirable?" publicado ayer en la SAP Community Network por Peter Adams, vicepresidente de soluciones SAP en SECUDE, me ha hecho recapacitar acerca no sólo de lo que en él se dice sino, además sobre el concepto mismo de single sign-on. El artículo es más bien ligerito: parece comenzar como una crítica que va a hacer tambalearse al single sign-on y dejarlo herido de muerte pero no es más que la exposición de unos pocos escenarios en los que el single sign-on debe ser matizado o complementado… para cumplir con determinados requisitos legales. El objetivo último del artículo es llevar al lector a un whitepaper, ubicado en el sitio de SECUDE, dirigido a profesionales de la industria farmacéutica que quieran estar al tanto de cómo SECUDE y SAP pueden ayudarles a cumplir con las exigencias de la FDA estadounidense.

¿De verdad cabe preguntarse, como hace Adams en el título de su artículo, si es deseable el single sign-on? Adams parece forzar el término single sign-on para asimilarlo a otro, relacionado pero en desuso, que es el one-time sign-on y así poder señalar mejor sus carencias. El concepto de single sign-on no está tan relacionado con el número de veces que el usuario se autentifica como con la existencia de un componente único del sistema contra el que el usuario se autentifica y que se encarga, desde ese momento, de hacer de intermediario entre otros componentes y el usuario, ahorrándole así la necesidad de autentificarse contra cada uno de ellos, posiblemente con distintos nombres de usuario y contraseñas. De este modo, además, se centraliza la gestión de los perfiles de usuario, reduciendo costes de administración y riesgos de operación. El usuario deja de tener un amplio abanico de nombres y contraseñas que recordar (y que, además, pueden regirse por modelos distintos de caducidad, fortaleza, etc., para complicarlo aún más) y, es cierto, se reduce el número de ocasiones en que ha de autentificarse. Sin embargo, aunque un número reducido (que tiende a uno, de hecho) de autentificaciones es lo habitual para la mayoría de los usuarios, creo que nunca he oído o leído a nadie serio que el concepto de single sign-on sea incompatible con la posibilidad de exigir al usuario una reautentificación para hacer determinadas tareas o pasado un determinado tiempo. El concepto admite y contempla estos escenarios, por lo que no tiene sentido ponerlo en duda basándose en ellos.

Es curioso que en su exposición de situaciones en las que un usuario debe verse forzado a reautentificarse, Adams olvide mencionar una de especial relevancia: cuando es esencial comprobar que el usuario es verdaderamente quien dice ser y no un tercero con acceso a su información de seguridad. Esta situación se da, principalmente, en dos escenarios:

1. al intentar acceder a información o funcionalidad de un nivel de riesgo tan elevado que sea necesario asegurarse de que nadie está intentando suplantar al usuario (al fin y al cabo, averiguar -o deducir- la contraseña de alguien y robar su token no es tan complicado);
2. en los casos en los que la non-repudiability es necesaria, es decir, cuando hay que asegurarse de que la persona que va a hacer la operación no podrá en el futuro afirmar que no lo hizo, puesto que la autentificación se hizo de una forma tal que no caben dudas sobre la identidad real del usuario.

Me pregunto por qué olvida el autor estos dos escenarios. ¿Será que su producto no es fuerte en lo referente a biometría y por eso prefiere obviarlos? La cuestión es que ninguna explicación completa de la autentificación robusta puede limitarse a esquemas de dos factores basándose en "what you know" y "what you have" y no mencionar el tercer elemento posible, "what you are". Repito, no obstante, que el hecho de que el artículo de Adams sea "ligerito" y tenga como objetivo servir de envoltorio a otro artículo de carácter más comercial son la explicación de estas imprecisiones.

No voy a darle más vueltas al asunto: me he sentido animado a contar aquí mis reflexiones al respecto, pero no es un tema que merezca más extensión, puesto que el concepto de single sign-on está muy bien explicado en muchos otros lugares y, además, goza de muy buena salud en la actualidad, por lo que no necesita defensores aficionados como yo.

Imagen cortesía de kk+ a través de una licencia by de Creative Commons.