Saltar al contenido principal
En este escenario, crearemos una aplicación web para una empresa ficticia llamada ExampleCo. La aplicación está pensada para que la usen los empleados y contratistas de ExampleCo. Los empleados usarán su directorio corporativo existente (Active Directory), mientras que los contratistas se gestionarán en un almacén de usuarios independiente.

​
En resumen

  • Auth0 admite estándares abiertos como OAuth 2.0 y para autenticación y autorización (consulte Qué protocolo usar)
  • OIDC admite varios flujos de autorización; el más adecuado para aplicaciones web es el Flujo de código de autorización (consulte Flujo de autenticación)
  • Su aplicación se configurará en Auth0 como una aplicación (consulte Aplicación)
  • Los Proveedores de identidad se configurarán en Auth0 como una Conexión (consulte Conexiones)
  • Auth0 proporciona el widget Lock, que permite a los usuarios iniciar sesión en la aplicación (consulte Inicio de sesión del usuario)
  • La aplicación web debe gestionar el estado de la sesión para mantener el seguimiento de que el usuario ha iniciado sesión. Además, Auth0 y el Proveedor de identidad también gestionan la información de la sesión. (consulte Administración de sesiones)
  • Del mismo modo, cerrar la sesión de un usuario también implica tres capas de administración de sesiones (consulte Cierre de sesión del usuario)
  • El control de acceso se puede gestionar con Authorization Extension de Auth0 (consulte Control de acceso)
Por Aplicación web regular, nos referimos a una aplicación que usa principalmente el lado del servidor, solicitudes de página GET y POST, y cookies para mantener el estado. Esto contrasta con una Web SPA (aplicación de una sola página), que depende en gran medida de código JavaScript del lado del cliente que llama a una API.

​
La premisa

ExampleCo es una startup de consultoría. Actualmente tiene aproximadamente 100 empleados y además subcontrata varias actividades a contratistas externos. La mayoría de los empleados trabajan desde la oficina principal de la empresa, pero algunos equipos trabajan en remoto. Además, algunos empleados viajan con frecuencia a las instalaciones de los clientes y trabajan desde dispositivos móviles. Todos los empleados y contratistas externos deben completar sus registros de horas cada semana mediante hojas de cálculo. El sistema actual es ineficiente y la empresa decidió que necesita adoptar una solución mejor y más automatizada. La empresa evaluó varias de las aplicaciones de registro de horas disponibles y concluyó que sería más rentable desarrollar su propia solución interna, ya que por el momento busca una aplicación muy simple. La aplicación se desarrollará con ASP.NET Core, ya que sus desarrolladores ya utilizan esta tecnología y pueden tenerla lista en aproximadamente una semana.

​
Objetivos y requisitos

ExampleCo quiere lanzar la nueva solución rápidamente, por lo que eligió empezar de forma sencilla e ir ampliándola a medida que recopila comentarios de sus empleados. La aplicación debería estar disponible solo para usuarios autenticados. Cada usuario tendrá un rol y, en función de este, debería poder realizar determinadas acciones y ver datos específicos.

​
Autenticación vs. autorización

ExampleCo quiere autenticar y autorizar a cada usuario. La autenticación tiene que ver con la identidad: verificar que el usuario es realmente quien dice ser. La autorización consiste en decidir a qué recursos debería tener acceso un usuario y qué debería poder hacer con esos recursos.
La aplicación de registro de horas de ExampleCo debe admitir dos roles: Usuario y Admin:
  • Una persona con el rol de Usuario puede agregar entradas de registro de horas especificando la fecha, la aplicación y las horas trabajadas. El rol de Admin también tiene este mismo derecho.
  • Quienes tengan el rol de Usuario deberían tener acceso solo a sus propias entradas de registro de horas.
  • Una persona con el rol de Admin puede, además:
    • Aprobar o rechazar entradas de registro de horas de otros usuarios.
    • Editar la lista desplegable de aplicaciones (agregar, editar, eliminar).
Cada usuario deberá completar sus registros de horas antes de que termine la semana. Puede optar por registrar sus horas a diario o agregar de una sola vez las entradas de toda la semana. Los registros de horas deberán ser revisados y aprobados por un Admin. Las entradas rechazadas deberán ser actualizadas por cada empleado y volver a enviarse para su aprobación. La empresa usa Active Directory para todos los empleados, y estos iniciarán sesión en la aplicación Timesheet con sus credenciales de Active Directory. Los contratistas externos pueden iniciar sesión con un username y una contraseña. Los contratistas no están en el directorio corporativo de ExampleCo. ExampleCo quiere minimizar la fricción del inicio de sesión para el usuario, pero quiere mantener un nivel de seguridad acorde con la operación: enviar entradas de registro de horas implica menos riesgo que aprobarlas. Sin embargo, los registros de horas aprobados se usan para la facturación a clientes, por lo que la seguridad es claramente un requisito. La estrategia de autenticación debería ser flexible para poder adaptarse a medida que la empresa crezca. Por ejemplo, deberían poder agregar fácilmente requisitos de autenticación adicionales, como , para los Admins. La solución debería estar disponible tanto para los empleados con presencia física en la oficina de la empresa como para quienes trabajan de forma remota, sin la sobrecarga de una conexión VPN; por lo tanto, la aplicación debería desplegarse en un proveedor de nube como Heroku o Microsoft Azure.
Diagrama de la solución

​
Más información