Identidad como servicio (IDaaS) — Okta & ASP Net Core
En el artículo anterior hablamos de dos proveedores de identidad como servicio — Identity-As-A-Service — AWS Cognito y Okta. Ahora veamos como podemos usar uno de ellos, Okta con una web app ASP Net Core.
Para este ejemplo solo necesitamos una cuenta de email y Visual Studio. La versión Community es más que suficiente.
Todo el código de este ejemplo está disponible en GitHub.
Web App
Primero creamos una Web Application en ASP Net Core desde Visual Studio 2017. Para este caso, la app que crea por defecto es suficiente. Configurar Authentication en ASP Net Core 2.0 es muy simple, la mayor parte de los cambios en startup.cs. Pero antes de empezar a configurar la app, tenemos que tener nuestro servicio de Identidad como Servicio. Comencemos con la configuración en Okta.
Okta — Nueva cuenta
En el sitio de Okta Developer se puede crear una nueva cuenta. Después de completar los datos del formulario, nos muestra el mensaje de bienvenida. También recibimos un email de Okta para confirmar nuestra cuenta y la clave temporaria para acceder a nuestra nueva cuenta.
Luego de confirmar, cambiar la clave de acceso y otras preguntas de seguridad de rigor, tenemos acceso a la consola, que incluye los links a las muy buenas quick start guides de Okta para distintas tecnologías front-end y back-end.
Lo primero que tenemos que hacer a continuación es crear la entrada de nuestra app, para permitir que esta contacte a Okta para identificar a los usuarios. Esto se logra desde el menú Applications, luego en esa pagina, presionando el botón Add Application. La selección del tipo de aplicación impacta directo en los flujos de OAuth que se van a usar en la app. Por ejemplo, SPA — Single Page App — solo permite implicit ya que el JavaScript es vulnerable para otros tipos. Para este ejemplo vamos a elegir el tipo Web y utilizar el flujo Authorization Code, que es la opción por defecto.
En el formulario para crear la app tenemos que configurar dos valores: Base URIs y Login redirect URIs. Aunque la guía menciona otro valor, Logout redirect URI, este no lo podemos modificar hasta luego de creada la app y entrar a editarla. Estos tres valores dependen de la configuración de nuestra web app, principalmente el puerto donde va a correr en localhost.
Algo que en el pasado era necesario hacer y que ahora Okta hace automáticamente en el momento de la creación es el asignar el dominio a la lista de Trusted Origins. Pero si por alguna razón tenemos que cambiar los dominios de nuestra app, hay que realizar el cambio manualmente no solo en la app en Okta sino también en la opción del menú API > Trusted Origins
Datos para la configuración
Terminada la creación de la app en Okta, podemos volver a Visual Studio.
Los datos necesarios para poder configurar son: el Client IDy Client Secret que podemos acceder cuando entramos a la configuración de la app en Okta. Aunque desde esta sección no podemos cambiar el Client ID, podemos generar un nuevo Client Secret de ser necesario. Otro valor necesario para terminar la configuración es el dominio del Authority. Es decir, dominio que nos provee Okta. Aunque la guía lo menciona, a mi paso lo siguiente más de una vez.
No incluir el
-admimen el dominio.El dominio correcto es
dev-639799.oktapreview.comy no
dev-639799-admin.oktapreview.com
Este dominio es muy importante ya que es de donde obtiene todas las configuraciones de OAuth y OIDC de nuestra cuenta de Okta, incluyendo el link de donde se obtienen las JSON Web Key Set (JWKS) para validar los tokens. Para ver como esta información, puede llamar a la siguiente URL desde Postman por ejemplo.
https://dev-639799.oktapreview.com/oauth2/default/.well-known/openid-configurationCambios en Startup.cs
Los primeros cambios necesario son los using
La mayoría de los cambios son en el método ConfigureServices. Algunos comentarios antes de ver el código, en particular cuando es diferente de la guía de Okta.
Primero, en vez de harcodear las propiedades de la conexión OIDC en el codigo, usamos el appsettings.jsonpara mayor flexibilidad.
Luego, al estar usando Razon Pages, la forma de indicar cuales son los recursos a proteger es distinta, usando el método AuthorizePage, en este caso solo la pagina Index.
La tercera sección tiene dos partes, AddAuthentication para indicar los esquemas de Authentication y AddOpenIdConnect para indicar los parámetros de la conexión OIDC, por lejos la sección más importante del código.
Y finalmente, modificar el método Configure para usar el modelo de Authentication que configuramos en el paso anterior.
Al ejecutar la app nos lleva automáticamente al Sign In de Okta ya que para acceder a Index necesita que el usuario este autenticado. A diferencia de Cognito, no tenemos la opción de registrarnos. Aunque Okta provee una API para poder construir nuestro propio registro.
En este caso, podemos usar el mismo usuario con el que creamos la cuenta y la app en Okta.
Luego de completar el usuario y la clave correctos, Okta nos envía de vuelta a la nuestra app. Si nos interesa hacer algo en particular luego de recibir la autorización desde Okta como por ejemplo mostrar las notificaciones desde la última vez que el usuario accedió al app, se puede utilizar el evento OnAuthorizationCodeReceived.
Algunos comentarios finales
La configuración del servicio en ASP Net Core 2.0 es muy simple y en poco tiempo podemos estar desarrollando nuestra app sin preocuparnos de la seguridad o gestionar los usuarios nosotros mismos. Este caso muestra la configuración básica para Okta pero la verdad es que cualquier otro servicio OIDC requiere un esfuerzo similar.
Es recomendable usar ASP Net Core Secrets para guardar los valores ClientId y ClientSecret en vez de usar appsettings.json.
Gracias Totales por leer!!!
Todas las opiniones expresadas son mías y no representan opiniones de ninguna entidad con la que he estado, estoy o estaré afiliado.
All views expressed are my own and do not represent opinions of any entity whatsoever with which I have been, am now, or will be affiliated
