Implementación de la aplicación (aplicaciones web + SSO)

Implementación de aplicaciones en el escenario de aplicaciones web tradicionales

Veamos la implementación de nuestra aplicación web tradicional. Usamos ASP .NET Core para la implementación; puedes encontrar el código en este repositorio de GitHub.

El ejemplo contiene una aplicación que usa una integración con Active Directory para autenticar a los empleados de la empresa y una conexión de base de datos de Auth0 para los contratistas externos. La autorización se implementa mediante Rules y claims, como veremos en detalle en esta sección.

​

Inicio de sesión de usuario

Auth0 proporciona un widget Lock que actúa como componente de inicio de sesión para su aplicación, por lo que no tiene que implementar su propia pantalla de inicio de sesión. El widget Lock se integra perfectamente con todas las conexiones que configure en su Auth0 Dashboard, ya sean conexiones de base de datos, sociales o empresariales.

Hay varias formas de implementar una pantalla de Login con una aplicación web y Auth0:

• Hosted Lock: Use una instancia del widget Lock alojada en la infraestructura de Auth0.
• Embedded Lock: Incruste el widget Lock en una página web de su aplicación. Tiene algunas opciones de personalización para el propio widget Lock y control total sobre el resto del HTML de la página.
• Custom UI: Desarrolle una página web completamente personalizada para la pantalla de inicio de sesión. El formulario HTML personalizado enviará los datos a su servidor, que a su vez autenticará al usuario mediante la Authentication API. Para obtener más información sobre cuándo usar una Custom UI, consulte Personalice las páginas de Classic Login con Lock o SDK.

​

Automatizar Home Realm Discovery (HRD)

De forma predeterminada, Lock muestra todas las conexiones disponibles para iniciar sesión. La selección de los Proveedores de identidad adecuados entre varias opciones se denomina Home Realm Discovery (HRD). En nuestro caso, las opciones son autenticarse con Active Directory (para los empleados de la empresa) o usar correo electrónico y contraseña para nuestra conexión de base de datos (contratistas externos).

Sin embargo, es posible que quieras evitar ese primer paso, en el que el usuario debe elegir el Proveedor de identidad (IdP), y dejar que el sistema lo determine en lugar de preguntarlo cada vez. Lock te ofrece las siguientes opciones:

• Identificar el IdP mediante programación: Cuando inicias una transacción de autenticación con Auth0, puedes enviar opcionalmente un parámetro connection. Este valor se asigna directamente a cualquier conexión definida en tu Dashboard. Al usar la versión Hosted de Lock mediante una llamada al endpoint /authorize, puedes incluir un parámetro connection en la cadena de consulta que contenga el nombre de la conexión. Como alternativa, si estás usando Lock integrado, esto es tan sencillo como escribir auth0.show({connections: ['{yourConnection}']});.

  • Hay varias formas prácticas de obtener el valor de connection. Una de ellas es usar URL personalizadas: por ejemplo, los empleados de la empresa usarán https://internal.yoursite.com, mientras que los contratistas externos usarán https://external.yoursite.com.

• Usar dominios de correo electrónico: Lock puede usar dominios de correo electrónico como una forma de encaminar solicitudes de autenticación. Las conexiones empresariales en Auth0 se pueden asignar a domains. Si una conexión tiene esta configuración, el cuadro de texto de la contraseña se desactiva automáticamente al escribir un correo electrónico con un dominio asignado. Ten en cuenta que puedes asociar varios dominios a una sola conexión.

Para obtener información adicional sobre este tema, consulta Seleccionar entre varias opciones de conexión.

​

Gestión de sesiones

Cuando hablamos de gestionar sesiones, normalmente hay tres capas de sesiones que debemos tener en cuenta:

• Sesión de la aplicación: La primera es la sesión dentro de la aplicación. Aunque su aplicación use Auth0 para autenticar usuarios, igualmente tendrá que llevar un registro de que el usuario ha iniciado sesión en su aplicación. En una aplicación web normal, esto se logra almacenando información en una cookie.
• Sesión de Auth0: A continuación, Auth0 también mantendrá una sesión y almacenará la información del usuario en una cookie. La próxima vez que se redirija al usuario a la pantalla de Auth0 Lock, se recordará su información.
• Sesión del Proveedor de identidad: La última capa es el Proveedor de identidad, por ejemplo, Facebook o Google. Cuando permite que los usuarios inicien sesión con cualquiera de estos proveedores y ya han iniciado sesión en el proveedor, no se les pedirá que vuelvan a hacerlo. Puede que simplemente se les pida conceder permisos para compartir su información con Auth0 y, a su vez, con su aplicación.

Al desarrollar una aplicación web, por lo tanto, tendrá que llevar un registro de que el usuario ha iniciado sesión en su aplicación web. Puede hacerlo mediante una sesión basada en cookies para mantener ese estado y también almacenar cualquier información o token relacionado con el usuario.

​

¿Cómo controlo la duración de la sesión local de la aplicación del usuario? ¿Puedo hacerlo desde Auth0?

La aplicación web tiene control total sobre la sesión local del usuario en la aplicación. La forma de hacerlo normalmente depende de la pila web que se esté usando (por ejemplo, ASP.NET). En cualquier caso, todos los enfoques usan en última instancia una o más cookies para controlar la sesión. El desarrollador puede optar por usar la expiración del JWT ID Token devuelto por Auth0 para controlar la duración de su sesión o ignorarla por completo. Algunos desarrolladores almacenan el propio ID Token en el estado de la sesión y finalizan la sesión del usuario cuando este expira.

La razón por la que usaría la expiración del token para determinar la expiración de la sesión local es que le proporciona un control centralizado sobre la duración de la sesión de un usuario desde el Auth0 Dashboard.

El flujo de inicio de sesión es el siguiente:

1. Iniciar el flujo de autenticación de OIDC: El navegador del usuario enviará una solicitud a Auth0 para iniciar el flujo de OIDC.
2. Establecer la cookie de SSO: Auth0 establecerá una cookie para almacenar la información del usuario.
3. Intercambio de código y devolución del ID Token: Auth0 hará una solicitud de vuelta al servidor web y devolverá el code. El servidor web intercambiará el code por un ID Token.
4. Establecer la cookie de autenticación y enviar la respuesta: El servidor web enviará una respuesta de vuelta al navegador y establecerá la cookie de autenticación de la aplicación para almacenar la información de la sesión del usuario.
5. La cookie de autenticación se envía con cada solicitud posterior: La cookie de autenticación de la aplicación se enviará en cada solicitud posterior como prueba de que el usuario está autenticado.

​

¿Cómo afecta la sesión de SSO de Auth0 a la sesión de la aplicación?

Auth0 administra su propia sesión de inicio de sesión único. Las aplicaciones pueden optar por respetar o ignorar esa sesión de SSO a la hora de mantener su propia sesión local. El widget Lock incluso tiene una función especial que puede detectar si existe una sesión de SSO de Auth0 y preguntar al usuario si desea volver a iniciar sesión como ese mismo usuario.

Si lo hace, iniciará sesión sin tener que volver a introducir sus credenciales con el IdP real. Aunque el usuario no se haya autenticado de nuevo, la aplicación sigue realizando un flujo de autenticación con Auth0 y obtiene un nuevo ID Token, que luego puede usarse para administrar la nueva sesión local de la aplicación.

Consulte la implementación en ASP.NET Core.

​

Cierre de sesión del usuario

Al cerrar la sesión del usuario, deberá volver a tener en cuenta las tres capas de sesiones de las que hablamos antes:

• Sesión de la aplicación: Debe cerrar la sesión del usuario en su aplicación web borrando su sesión.
• Sesión de Auth0: Debe cerrar la sesión del usuario en Auth0. Para ello, redirija al usuario a https://{yourDomain}/v2/logout. Redirigir al usuario a esta URL borra todas las cookies de inicio de sesión único que Auth0 haya establecido para el usuario.
• Sesión del Proveedor de identidad: Aunque no es una práctica habitual, puede forzar al usuario a cerrar sesión en el Proveedor de identidad utilizado, por ejemplo, Facebook o Google. Para ello, agregue un parámetro de cadena de consulta federated a la URL de cierre de sesión: https://{yourDomain}/v2/logout?federated.

Para redirigir a un usuario después de cerrar la sesión, agregue un parámetro de cadena de consulta returnTo con la URL de destino como valor: https://{yourDomain}/v2/logout?returnTo=http://www.example.com. Tenga en cuenta que deberá agregar la URL de returnTo a Allowed Logout URLs. Para obtener más información sobre cómo implementarlo, consulte: Logout.

El flujo de cierre de sesión (sin incluir el cierre de sesión federado) es el siguiente:

1. Iniciar el flujo de cierre de sesión: El flujo de cierre de sesión se iniciará desde el navegador, por ejemplo, cuando el usuario haga clic en un enlace de Logout. Se realizará una solicitud al servidor web.
2. Borrar la sesión local del usuario: Se borrará la sesión de la aplicación o la cookie del usuario.
3. Redirigir el navegador al Logout de Auth0: El navegador del usuario será redirigido a la URL de cierre de sesión de Auth0.
4. Borrar la cookie de SSO: Auth0 borrará la cookie de SSO del usuario.
5. Redirigir a la URL posterior al cierre de sesión: Auth0 devolverá una respuesta de redirección y redirigirá el navegador del usuario al parámetro de cadena de consulta returnTo.

Consulte la implementación en ASP.NET Core.

​

Control de acceso

La autorización se refiere al proceso de determinar qué acciones puede realizar un usuario dentro de su aplicación.

Puede implementar la autorización directamente en su aplicación, de forma independiente de Auth0, o usar una de las opciones disponibles para recuperar los niveles de autorización del usuario, incluirlos como claims de autorización en el ID Token y validar esos claims dentro de su aplicación, una vez que recupere el token, para controlar el acceso.

Hay varias maneras de recuperar y establecer los claims de autorización del usuario cuando usa Auth0:

• Configurando y usando la Auth0 Authorization Extension.
• Usando grupos de Active Directory. Estos pueden usarse en combinación con Authorization Extension mediante la asignación de grupos de Active Directory a los Groups que defina con Authorization Extension.
• Agregando metadatos al perfil del usuario mediante Rules.
• Llamando a servicios externos desde una Rule.

Dado que, en nuestro caso, la empresa ya tiene Active Directory configurado, aplicaremos el control de acceso usando Authorization Extension en combinación con grupos de Active Directory.

Authorization extension

En este momento, Authorization Extension está diseñada principalmente para aplicar una autorización de grano grueso, por ejemplo, para controlar el acceso a una aplicación en función de la pertenencia de un usuario a un grupo. No está diseñada necesariamente para controlar el acceso de grano fino (como determinar si un usuario puede realizar una acción específica dentro de la aplicación), aunque en este caso la utilizamos de esa manera.

Todos los usuarios serán implícitamente usuarios regulares, pero a los administradores de registros de horas se les asignará el grupo Admin, lo que les permitirá aprobar registros de horas. Authorization Extension permite asignar grupos a pertenencias de grupo existentes.

A todos los administradores de registros de horas se les asignará el grupo Timesheet Administrators en Active Directory, que se asignará automáticamente al grupo Admin dentro de la aplicación Timesheet.

Cuando instala Authorization Extension, esta crea una Rule en segundo plano que hace lo siguiente:

1. Determina la pertenencia del usuario a grupos.
2. Almacena la información de pertenencia del usuario a grupos como parte de app_metadata.
3. Agrega la pertenencia del usuario a grupos al token emitido.
4. Verifica que al usuario se le haya concedido acceso a la aplicación actual.

​

Instala la Authorization Extension

Para instalar la Authorization Extension, ve a la vista Extensions de tu Auth0 Dashboard, selecciona Auth0 Authorization Extension e instálala.

Una vez instalada, verás la aplicación en la lista de Installed Extensions.

Cuando hagas clic en el enlace para abrir la extensión por primera vez, se te pedirá que concedas permiso para que la extensión acceda a tu cuenta de Auth0. Si lo haces, se te redirigirá al Authorization Dashboard.

Una vez en el Authorization Dashboard, ve a Groups en el menú de navegación y crea un grupo nuevo llamado Admin.

Después de agregar el grupo, puedes hacer clic en él para ir a la sección de administración del grupo. Ve a la pestaña Group Mappings y agrega una nueva asignación de grupo para asignar todos los usuarios de Active Directory de los grupos Timesheet Admins al grupo Admin que acabas de crear.

Una vez que hagas clic en Save, podrás ver la nueva asignación en la lista.

Con la asignación configurada, solo tienes que mantener la pertenencia al grupo Timesheet Admins en Active Directory, y esos usuarios se asignarán automáticamente al grupo Admin dentro de nuestra aplicación.

Para obtener más información, consulta la documentación de Authorization Extension.

​

Aplique permisos en su aplicación

Cuando instaló la Authorization Extension, también se creó una Rule de Auth0 que agrega un claim de authorization con toda la configuración relacionada con la autorización para un usuario determinado. Los grupos de un usuario se agregarán como un subclaim del claim de authorization llamado groups, y todos los grupos a los que pertenece ese usuario se agregarán como un array en este claim. Este es un ejemplo de cómo podría verse la carga útil JSON de un ID Token con los grupos incluidos:

{
  "sub": "1234567890",
  "name": "John Doe",
  "authorization": {
    "groups": ["Admin"]
  }
}

Por lo tanto, en tu aplicación deberás decodificar el ID Token que se devuelve cuando se autentica un usuario y extraer los grupos a los que pertenece a partir del claim authorization. Después, puedes almacenar estos grupos junto con otra información del usuario en la sesión del usuario y, posteriormente, consultarlos para determinar si un usuario tiene permisos para realizar una determinada acción en función de su pertenencia a grupos.

Consulta la implementación en ASP.NET Core.