Gestión de Identidad y acceso. Conceptos.

¡Hola OAuth2, OIDC, WebAuthN, ABAC, Azure B2C, FIDO2, RBAC y otros! ¿Qué tal estáis? ¿Bien, o hechos un lío? No me extraña, el único que me va a agradecer este primer párrafo, ¡va a ser el robot de google!

Todos los días tenemos diálogos como el siguiente…

Usuario: Hola, quisiera acceder a mi servicio, ¿puedo entrar?
Servicio: bip, bip… ¡tendrás de decirme quien eres! Toma, apúntame aquí tu usuario y tu contraseña
Usuario: Ok, no hay problema soy David y mi contraseña es *^16
Servicio: Bip, bip, ¿Estás en China? ¡Pero si tú no viajas nunca! Ummmmm, no sé, no sé… Anda te voy a mandar a tu móvil un código, ¡dime cual es!
Usuario: ¡Que desconfiado! Con lo bonita que es China… Sip, lo acabo de recibir, toma es 123456.
Servicio: ¡Bien, bien! Así que es verdad, has salido de tu cuarto… Bueno, tomo nota, te apunto en la lista y déjame que te pase con autorizaciones. Un momento, ram, ram, byte, byte… 10101001 10110011 …
Usuario: ¡Gracias!

Servicio: ¡Aqui el que manda digame!
Usuario: Hola, buenos días, me acabo de autenticar hace un segundo y ahora me gustaría poder acceder a mi información.
Servicio: Un segundo, y… ¿me dice que usted es? ya veo, si es correcto, no hay duda. Déjame que consulte… Ummm, si usted es cliente VIP, tome nota, le voy a dar un recibico para que lo presente cuando le pregunten los compañeros, su token de acceso es TWlyYSBxdWUgZXJlcyBjdXJpb3NvISA6KQ==
Usuario: ¡Gracias!

Empezar diciendo que no soy ningún experto, pero que me voy a atrever a contarlo de la forma que me hubiera gustado que me lo hubieran contado a mi. Así que, pido perdón por anticipado a los expertos por las licencias que me voy a tomar y encantado de que me repliquen y discutan cualquier matiz. ¡Es la mejor forma que existe de aprender! ?

Tengo que hacer las definiciones básicas, lo siento. Señalar que en este mundo del IAM, a veces todo es muy ambiguo y discutible, que cada tecnología se toma sus libertades. Voy a intentar ser lo mas agnostico posible, para que encajen a nuestro fin. Voy ha empezar con obviedades, pero no os preocupeis… ¡lo complicamos! este es el primer post de una serie.

Autenticación no es Autorización

Autenticación.

Definimos la autenticación como el proceso donde demostramos nuestra identidad a través de unas credenciales o algún otro mecanismo que garantice nuestra presencia. Por ejemplo, cuando iniciamos sesión en un servicio, empleando usuario y contraseña, o mediante la huella o la cara o con un certificado y contraseña, en todos ellos, nosotros somos los que conocemos, poseemos, somos algo que nos identifica .

Quizás, para mas seguridad en este momento, te pidan otra prueba adicional de tu identidad. Por ejemplo, introducir un SMS enviado a tu móvil o algún dato biométrico… A esto se le llama doble factor de autenticación (2FA) o multiple factor de autenticación (MFA) o autenticación fuerte, o autenticación fuerte de cliente (SCA) o … pero se resume en que dependiendo de los cómo, qué, quién, dónde, cuando te estén autenticando te pidan más demostraciones o menos.

Realmente, desde el punto de vista de seguridad, es bastante efectivo, ya que las contraseñas están rotas, además, es muy potente cruzarlo con los atributos asociados a tu sesión y junto a machine learning se puede verificar la localización, horario y tus costumbres anteriores para puntuar el riesgo de estar siendo suplantado por un malo. Pero, todavía siguen siendo necesarios los mecanismo para la protección de ataques de fuerza bruta, alguien o algo probando una y otra vez tus posibles contraseñas.

Por lo tanto, este proceso debe contener un almacén de credenciales de usuarios y los mecanismos para fortalecer la seguridad, ¿estamos de acuerdo que es uno de los puntos más crítico en la seguridad de un servicio?. Estos almacenes, normalmente llamados IdP (Proveedores de Identidad) pueden contener credenciales de muchas naturalezas diferentes

Es muy importante que tengamos este servicio centralizado, que nos permita hablar con varios proveedores de identidad, que disponga de políticas de seguridad, con una auditoría consistente y con mecanismos que simplifiquen la experiencia de usuario, normalmente con SingleSignOn (Te auténticas una vez en un servicio y te recuerdo en todos, salvo que me despiertes dudas… no te vuelvo a pedir que te identifiques)

Autorización

¡Ya estás dentro del servicio!, y solo has tenido que recordar la contraseña, ir a por el móvil cuando te ha pedido que introduzcas el código enviado por SMS y refrescar dos veces el navegador por que se ha quedado la pantalla en blanco entre redirección y redirección! menos que esta vez no has tenido que tirar de conocimiento en Egiptología para sacar el Captcha

Ahora es el momento de mostrar los contenidos a los que tienes acceso, tus menus, tu informacion, aquí es donde se van a emplear los procesos de autorización para perfilarte y entregarte el contenido al que tienes acceso.

Autorizar podemos decir que es el proceso por el cual, a una identidad autenticada, se le permite o se le deniega el acceso a un recurso. Mi experiencia me dice, que es muy importante definir que es para nosotros un recurso y sobre todo que esté estrechamente relacionado con la información a proteger. Por ejemplo, un recurso puede ser mi perfil de usuario, mi nombre, mi email, etc. solo yo debería tener acceso, ¡al menos para modificar estos datos!

Existen muchos módelos de autorización, nos centramos en dos:

• RBAC (Role Based Access Control): El sistema te ha asignado un Rol dentro del servicio y tus accesos estarán limitados a si perteneces o no a este Rol. Es un sistema de grano gordo, ya que el propio Rol suele utilizarse como recurso, es decir, está incluido en el propio código. Si necesitas un nuevo rol, tendrás que incluirlo en la lógica de la aplicación y desplegar de nuevo. Normalmente, una vez que obtienes el rol o roles los utilizas durante toda la sesión.

• ABAC (Attribute Based Access Control): Todo son atributos, la aplicación desde la que vienes, tu dirección IP, si llueve o no, incluso tus roles, el sistema te conocerá acceso si cumples con las exigencias del recurso respecto a esos atributos. Normalmente, con este modelo, siempre debemos preguntar al sistema de autorización en cada acceso. Es de grano fino, y cumple con unos requisitos de seguridad más fuertes. Esta es la implementación ‘más deseable’.

Nunca es buena idea autorizar únicamente en el frontend, siempre se debe hacer en backend, en frontend debe utilizarse para facilitar la presentación, como eres VIP, puedes ver este menú, ya que si está en el lado del usuario, también está en el lado de los malos. ?

Al final del cuento, de lo que trata es de permitir o denegar el acceso a la información en base a

• ¿Quién puede acceder?
• ¿A qué puede acceder?
• ¿Cuándo puede acceder?
• ¿Dónde, cómo y por qué puede acceder?

Proximas páradas

Reforzar estos conceptos con elementos visuales, para posteriormente comenzar con OAuth2, por ser el más popular del parque, seguiré por OIDC (OpenID Connect) y terminaremos con FIDO2, dejaremos atrás a los clásicos, como SAML, Certificados, Kerberos, LDAP, etc.

Posteriormente hablaré de productos y librerías para hacer estas cosas.

Y finalmente, haré una extra ball con los proveedores de Cloud, por la relevancia que tienen… Azure AD, B2C, B2B, AWS, Google, Apple, etc.

¡A darle caña!