共用方式為

Integración de Azure B2C en una aplicación de Xamarin Forms utilizando MSAL

  • 發行項

En este artículo veremos cómo crear una sencilla aplicación Xamarin Forms, que muestra cómo usar MSAL para autenticar usuarios a través de Azure Active Directory B2C y acceder a una API Web ASP.NET con el token resultante. Para obtener más información sobre Azure B2C, consulta la documentación de Azure AD B2C.

Cómo ejecutar un ejemplo simple

Para ejecutar este ejemplo necesitarás: - Visual Studio 2017 - Una conexión a Internet - Un tenant Azure AD B2C.
Si no tienes un tenant Azure AD B2C, puedes seguir las instrucciones para crear uno. Si sólo quieres ver este ejemplo, no necesitas crear tu propio tenant, ya que el proyecto viene con algunos ajustes asociados a un tenant de prueba y una aplicación; Sin embargo, es altamente recomendable que registres tu propia aplicación y pruebes los pasos de configuración a continuación.

Paso 1: clona o descarga el repositorio

Desde la línea de comandos:

 

 git clone https://github.com/Azure-Samples/active-directory-b2c-xamarin-native.git

[OPCIONAL] Paso 2: consigue tu propio tenant Azure B2C

También puedes modificar el ejemplo para usar tu propio tenant Azure AD B2C. Primero, necesitará crear un tenant Azure AD B2C siguiendo estas instrucciones.
IMPORTANTE: si eliges realizar uno de los pasos opcionales, tienes que hacer TODOS ellos para que el ejemplo funcione como se esperaba.

[OPCIONAL] Paso 3: crea tus propias políticas

Este ejemplo utiliza tres tipos de políticas: una política de registro / inicio de sesión unificado y una directiva de edición de perfil. Crea una política de cada tipo siguiendo estas instrucciones. Puede elegir incluir tantos o tan pocos proveedores de identidad como deses.
Si ya tienes políticas existentes en tu tenant Azure AD B2C, no dudes en volver a utilizarlas. No hay necesidad de crear nuevas sólo para este ejemplo.

[OPCIONAL] Paso 4: Crea tu propia Web API

Este ejemplo llama a una API en https://fabrikamb2chello.azurewebsites.net que tiene el mismo código que el ejemplo Node.js Web API con Azure AD B2C. Necesitará su propia API o, como mínimo, tendrás que registrar una API Web con Azure AD B2C para que puedas definir los ámbitos para los que su aplicación de una única página solicitará tokens de acceso.
El registro de tu API web debe incluir la siguiente información:

  • Habilitar la configuración de la aplicación web / Web API para la aplicación.
  • Establecer la URL de respuesta en el valor apropiado indicado en el ejemplo o proporcionar cualquier URL si sólo está realizando el registro de api web, por ejemplo https: // myapi.
  • Asegúrate de proporcionar también una URI de AppID, por ejemplo demoapi, que se utiliza para construir los scopes que están configurados en el código de la aplicación de una sola página.
  • (Opcional) Una vez que se haya creado la aplicación, abre Scopes públicos de la aplicación y agrega los scopes adicionales que desees.
  • Copia los valores de URI de AppID y Scopes públicos, para poder ingresarlos en el código de tu aplicación.

[OPCIONAL] Paso 5: Crea tu propia app nativa

Ahora debes registrar tu aplicación nativa en su tenant B2C, para que tenga su propio ID de aplicación. No olvides proporcionar una API de Acceso a tu API web registrada en el paso anterior.
El registro nativo de tu aplicación debe incluir la siguiente información:

  • Activa la configuración Native Client para tu aplicación.
  • Una vez que se haya creado la aplicación, abre la pestaña de Propiedades de la aplicación y configura la URI de redirección para tu aplicación en msal <Id de aplicación>: // auth.
  • Una vez que se haya creado la aplicación, abre la pestaña de acceso a la API y agrega la API que creaste en el paso anterior.
  • Copia el ID de aplicación generado para su aplicación, de modo que puedas utilizarlo en el paso siguiente.

[OPCIONAL] Paso 6: Configura el proyecto de Visual Studio con los datos de tu aplicación

  1. Abre la solución en Visual Studio.
  2. Abre el archivo UserDetailsClient \ App.cs.
  3. Busca la asignación para public static string Tenant y reemplaza el valor por su nombre de tenant.
  4. Busca la asignación de ClientID de cadena estática pública y reemplaza el valor por el ID de aplicación del paso 2.
  5. Busca la asignación para cada una de las políticas public static string PolicyX y reemplaza los nombres de las políticas que creaste en el paso 3.
  6. Busca la asignación para los ámbitos public static string [] Scopes y reemplázalos con los que creaste en el Paso 4.

[OPCIONAL] Paso 6a: Configura el proyecto en iOS con la URI de retorno de la API

  1. Abre el archivo UserDetailsClient.iOS \ info.plist en un editor de texto (abrirlo en Visual Studio no funcionará para este paso, ya que necesitas editar el texto)
  2. En los tipos de URL, sección, agrega una entrada para el esquema de autorización utilizado en su redirectUri. Xml <key> CFBundleURLSchemes </ key> <array> <string> msal [APPLICATIONID] </ string> </ array> donde [APPLICATIONID] es el identificador que copiaste en el paso 2. Guarda el archivo.

[OPCIONAL] Paso 6b: Configura el proyecto Android con la URI de retorno de la API

  1. Abre el UserDetailsClient.Droid \ Properties \ AndroidManifest.xml
  2. Agrega o modifica el elemento <application> como en el siguiente xml <application> <activity android: name = "microsoft.identity.client.BrowserTabActivity"> <action android: name = "android.intent.action. VIEW "/> <categoría android: name =" android.intent.category.DEFAULT "/> <android: name =" android.intent.category.BROWSABLE "/> <data android: scheme =" msal [APPLICATIONID] Android: host = "auth" /> </ intent-filter> </ activity> </ application> donde [APPLICATIONID] es el identificador que copiaste en el paso 2. Guarda el archivo.

Paso 7: Ejecutar el ejemplo

  1. Elige la plataforma en la que deseas trabajar estableciendo el proyecto de inicio en el Explorador de soluciones. Asegúrate de que la plataforma elegida esté marcada para la creación y la implementación en el Configuration Manager.
  2. Limpia la solución, hazle un rebuild y ejecútala.
  3. Haz clic en el botón de inicio de sesión en la parte inferior de la pantalla de la aplicación. El ejemplo funciona exactamente de la misma manera, independientemente del tipo de cuenta que elijas, y contará con algunas diferencias visuales en la experiencia de autenticación y consentimiento. Al acceder con éxito, la pantalla de la aplicación mostrará una información de perfil básica para el usuario autenticado y podrás ver botones que te permitirán editar tu perfil, llamar a una API y cerrar sesión.
  4. Cierra la aplicación y vuelve a abrirla. Verás que la aplicación conserva el acceso a la API y recupera la información de usuario de inmediato, sin necesidad de volver a iniciar sesión.
  5. Para salir, haz clic en el botón Cerrar sesión y confirma que pierde el acceso a la API hasta que se cierre la sesión.

Corriendo la app en el emulador

MSAL en Android requiere soporte para las pestañas personalizadas de Chrome, que muestran las indicaciones de autenticación. No todas las imágenes de los emuladores vienen con Chrome a bordo: consulta este documento para obtener instrucciones sobre cómo garantizar que tu emulador admita las funciones requeridas por MSAL.

Acerca del código

La estructura de la solución es sencilla. Toda la lógica de la aplicación y UX residen en UserDetailsClient (portable). Primitiva principal de MSAL para clientes nativos, PublicClientApplication, se inicializa como una variable estática en App.cs. En el inicio de la aplicación, la página principal intenta obtener un token sin mostrar ningún UX - sólo en caso de que un token adecuado ya esté presente en la caché de las sesiones anteriores. Este es el código que implementa esa lógica:

 

 protected override async void OnAppearing()
{
    UpdateSignInState(false);

    // Check to see if we have a User in the cache already.
    try
    {
        AuthenticationResult ar = await App.PCA.AcquireTokenSilentAsync(App.Scopes, GetUserByPolicy(App.PCA.Users, App.PolicySignUpSignIn), App.Authority, false);
        UpdateUserInfo(ar);
        UpdateSignInState(true);
    }
    catch (Exception)
    {
        // Doesn't matter, we go in interactive mode
        UpdateSignInState(false);
    }
}

Si el intento de obtener un token falla, no hacemos nada y visualizamos la pantalla con el botón de inicio de sesión. Cuando se pulsa el botón de inicio de sesión, ejecutamos la misma lógica, pero empleando un método que muestra UX interactivo:

 

 AuthenticationResult ar = await App.PCA.AcquireTokenAsync(App.Scopes, GetUserByPolicy(App.PCA.Users, App.PolicySignUpSignIn), App.UiParent);

El parámetro Scopes indica los permisos que la aplicación necesita para obtener acceso a los datos solicitados a través de la siguiente llamada de la API web (en este ejemplo, encapsulado en OnCallApi). El UiParent se utiliza en Android para vincular el flujo de autenticación a la actividad actual y se ignora en todas las demás plataformas.

La lógica de salida es muy simple. En este ejemplo tenemos sólo un usuario, sin embargo estamos mostrando una lógica de salida más genérica, que puede aplicar si tienes varios usuarios simultáneos y deseas borrar toda la memoria caché.

Csharp foreach (usuario var en App.PCA.Users) {App.PCA.Remove (usuario); }

 

Consideraciones especiales para Android

Los proyectos específicos de la plataforma requieren sólo un par de líneas adicionales para adaptarse a las diferencias de plataforma individuales.
UserDetailsClient.Droid requiere dos líneas adicionales en el archivo MainActivity.cs. En OnActivityResult, necesitamos agregar:

 

 AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs(requestCode, resultCode, data);

Esa línea garantiza que el control vuelva a MSAL una vez que la parte interactiva del flujo de autenticación terminó.
En OnCreate, necesitamos agregar la siguiente asignación: csharp App.UiParent = new UIParent (Xamarin.Forms.Forms.Context as Activity); Ese código asegura que los flujos de autenticación ocurran en el contexto de la actividad actual.

Consideraciones específicas para iOS

UserDetailsClient.iOS sólo requiere una línea adicional, en AppDelegate.cs. Debe asegurarse de que el handler OpenUrl tiene un aspecto similar al siguiente: csharp public override bool OpenUrl (aplicación UIApplication, URL NSUrl, opciones NSDictionary) {AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs (url, ""); Devuelve verdadero; } Una vez más, esta lógica está destinada a asegurar que una vez que la parte interactiva del flujo de autenticación se concluye, el flujo vuelve a MSAL.

Más información

Para más información sobre Azure B2C, consulta la documentación oficial.

Más ejemplos de Jean-Marc Prieur

Extending the Azure AD directory schema with custom properties Calling the Azure AD Graph API in a web application Integrating a Windows Universal application with Azure AD Integrating Azure AD into a Windows desktop application Calling web APIs in a daemon or long-running process

 

Daniel Ortiz López

Technical Evangelist Intern

@ortizlopez91