Configurer Azure Active Directory B2C avec Akamai Enterprise Application Access pour l’authentification unique et un accès hybride sécurisé

Cette fonctionnalité est disponible uniquement pour les stratégies personnalisées. Pour accéder aux étapes de configuration, sélectionnez Stratégie personnalisée dans le sélecteur précédent.

Prérequis

Avant de commencer, vérifiez que vous disposez des éléments suivants :

• Un contrat Akamai Enterprise Access. Si vous n’en avez pas, inscrivez-vous pour un essai gratuit.

• Un abonnement Azure. Si vous ne disposez d’aucun abonnement, vous pouvez obtenir un compte gratuit.

• Un locataire Azure AD B2C lié à votre abonnement Azure.

• Une appliance virtuelle déployée derrière le pare-feu dans votre centre de données ou dans des environnements cloud hybrides pour déployer le connecteur Akamai Enterprise Application Access.

• Une application qui utilise des en-têtes pour l’authentification. Dans cet exemple, nous allons utiliser une application docker qui affiche des en-têtes : header-demo-app.

• OU une application OIDC (OpenID Connect). Dans cet exemple, vous allez utiliser une application web ASP.NET MVC qui connecte les utilisateurs à l’aide du middleware (intergiciel) OWIN (Open Web Interface for .NET) et de la plateforme d’identités Microsoft.

Description du scénario

Dans ce scénario, vous allez activer l’authentification Azure AD B2C pour les utilisateurs finaux quand ils essaient d’accéder à des applications privées sécurisées par Akamai Enterprise Application Access.

Les composants impliqués dans cette intégration sont les suivants :

• Azure AD B2C : Fournisseur d’identité SAML chargé de l’authentification des utilisateurs finaux.

• Akamai Enterprise Application Access : Service cloud ZTNA chargé de sécuriser l’accès aux applications privées avec l’application continue de la stratégie ZTNA.

• Connecteur Akamai Enterprise Application Access : Appliance virtuelle déployée dans le centre de données privé. Il permet une connectivité sécurisée aux applications privées sans qu’il soit nécessaire d’ouvrir des ports de pare-feu entrants du centre de données.

• Application : Service ou application déployé dans votre centre de données privé auquel les utilisateurs finaux doivent accéder.

L’utilisateur s’authentifie auprès d’Azure AD B2C (fournisseur d’identité SAML) qui répondra à Akamai Enterprise Application Access (fournisseur de services) avec une assertion SAML. Akamai Enterprise Application Access mappe les informations de l’assertion SAML et construit des revendications OpenID ou injecte des en-têtes HTTP contenant des informations sur l’utilisateur. Akamai Enterprise Application Access les transfère ensuite à l’application accessible par le biais du connecteur Akamai Enterprise Application Access. Dans notre exemple, l’application affiche le contenu de ces en-têtes. Dans le cas d’usage d’une application OIDC, elle affichera les revendications de l’utilisateur.

Le diagramme suivant montre comment Akamai EAA (Enterprise Application Access) s’intègre à Azure AD B2C.

1. Un utilisateur final tente d’accéder à une application hébergée dans le centre de données privé à l’aide de l’URL externe de l’application inscrite auprès d’Akamai Enterprise Application Access.

2. Akamai Enterprise Application Access redirige l’utilisateur final non authentifié vers Azure AD B2C pour l’authentification.

3. Une fois l’authentification réussie, Azure AD B2C redirige l’utilisateur vers Akamai Enterprise Application Access avec une assertion SAML.

4. Akamai Enterprise Application Access utilise les informations d’identité de l’assertion SAML pour identifier l’utilisateur et déterminer si l’utilisateur est autorisé à accéder à l’application demandée.

5. Akamai Enterprise Application Access construit des revendications OIDC ou injecte des en-têtes HTTP, qui sont envoyés à l’application.

6. L’application utilise ces informations pour identifier l’utilisateur authentifié et crée une session d’application pour l’utilisateur final.

Commencer avec Akamai Enterprise Application Access

Pour commencer avec Akamai Enterprise Application Access, consultez le guide de prise en main d’Akamai Enterprise Application Access.

Étape 1 : Ajouter Azure AD B2C comme fournisseur d’identité SAML dans Akamai Enterprise Application Access

Akamai Enterprise Application Access prend en charge la fédération SAML avec des fournisseurs d’identité cloud comme Azure AD B2C. Ajoutez Azure AD B2C comme fournisseur d’identité SAML tiers dans Akamai Enterprise Application Access.

1. Connectez-vous à Enterprise Center https://control.akamai.com/

2. Dans le menu de navigation d’Enterprise Center, sélectionnez Application Access > Identity & Users > Identity Providers.

3. Sélectionnez Add Identity provider (+).

4. Entrez un nom, une description, puis sélectionnez le type de fournisseur Third Party SAML (SAML tiers).

5. Sélectionnez Continuer. La page de configuration du fournisseur d’identité s’affiche.

6. Dans Settings>General, entrez une URL pour le serveur d’identité. Vous pouvez sélectionner Use Akamai domain ou Use your domain. Si vous utilisez votre propre domaine, utilisez un certificat auto-signé ou utilisez le certificat personnalisé chargé.

7. Sous Authentication, entrez la même URL que celle définie à l’étape précédente dans General et sélectionnez Save.

   

Étape 2 : Inscrire une application SAML dans Azure AD B2C

1. Récupérez les packs de démarrage de stratégie personnalisés à partir de GitHub, puis mettez à jour les fichiers XML dans le pack de démarrage LocalAccounts avec votre nom de locataire Azure AD B2C :

   • Téléchargez le fichier .zip ou clonez le référentiel :

     git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
     

   • Dans tous les fichiers du répertoire LocalAccounts, remplacez la chaîne yourtenant par le nom de votre locataire Azure AD B2C. Par exemple, si le nom de votre locataire B2C est fabrikam, toutes les instances de yourtenant.onmicrosoft.com deviennent fabrikam.onmicrosoft.com.

2. Créez un certificat de signature pour Azure AD B2C pour signer la réponse SAML envoyée à Akamai Enterprise Application Access :

   a. Obtenez un certificat. Si vous n’avez pas encore de certificat, vous pouvez utiliser un certificat auto-signé.

   b. Chargez le certificat sur votre locataire Azure AD B2C. Notez le nom, car il sera nécessaire dans le TechnicalProfile mentionné dans les étapes suivantes.

3. Activez votre stratégie pour la connexion à une application SAML.

   a. Ouvrez LocalAccounts\TrustFrameworkExtensions.xml dans le pack de démarrage de stratégie personnalisée. Recherchez l’élément ClaimsProviders. S’il n’existe pas, ajoutez-le sous l’élément racine TrustFrameworkPolicy, puis ajoutez l’extrait de code XML suivant pour implémenter votre générateur de réponse SAML :

    <ClaimsProvider>
      <DisplayName>Akamai</DisplayName>
      <TechnicalProfiles>
        <!-- SAML Token Issuer technical profile -->
        <TechnicalProfile Id="AkamaiSaml2AssertionIssuer">
          <DisplayName>Token Issuer</DisplayName>
          <Protocol Name="SAML2" />
          <OutputTokenFormat>SAML2</OutputTokenFormat>
          <Metadata>
            <Item Key="IssuerUri">https://<REPLACE>.login.go.akamai-access.com/saml/sp/response</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_AkamaiSAMLSigningCert" />
            <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_AkamaiSAMLSigningCert" />
          </CryptographicKeys>
          <InputClaims />
          <OutputClaims />
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuerAkamai" />
        </TechnicalProfile>
        <!-- Session management technical profile for SAML-based tokens -->
        <TechnicalProfile Id="SM-Saml-issuerAkamai">
          <DisplayName>Session Management Provider</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
            <Item Key="IncludeSessionIndex">false</Item>
            <Item Key="RegisterServiceProviders">false</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
   

   b. Remplacez issuerUri par l’URL Akamai définie dans Akamai Enterprise Application Access sous Setting > General à l’Étape 1.

   • Par exemple, <Item Key="IssuerUri">https://fabrikam.login.go.akamai-access.com/saml/sp/response</Item>

   • Remplacez B2C_1A_AkamaiSAMLSigningCert par le nom de la clé de stratégie chargée.

Étape 3 : Créer une stratégie d’inscription ou de connexion configurée pour SAML

1. Créez une copie du fichier SignUpOrSignin.xml dans le répertoire de travail de votre pack de démarrage, puis enregistrez celui-ci sous un nouveau nom. Cet article utilise SignUpOrSigninSAML.xml comme exemple. Il s’agit de votre fichier de stratégie pour la partie de confiance. Il est configuré pour émettre une réponse JWT par défaut.

2. Ouvrez le fichier SignUpOrSigninSAML.xml dans l’éditeur de votre choix.

3. Remplacez tenant-name par le nom de votre locataire Azure AD B2C et remplacez les valeurs PolicyId et PublicPolicyUri de la stratégie par B2C_1A_signup_signin_saml et http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml.

   <TrustFrameworkPolicy
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
   PolicySchemaVersion="0.3.0.0"
   TenantId="tenant-name.onmicrosoft.com"
   PolicyId="B2C_1A_signup_signin_saml"
   PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">
   

4. À la fin du parcours utilisateur, Azure AD B2C contient une étape SendClaims. Cette étape fait référence au profil technique d’émetteur de jeton. Pour émettre une réponse SAML au lieu de la réponse JWT par défaut, modifiez l’étape SendClaims pour référencer le nouveau profil technique d’émetteur de jeton SAML, Saml2AssertionIssuer.

   Ajoutez l’extrait de code XML suivant juste devant l’élément <RelyingParty>. Ce code XML remplace l’étape d’orchestration 4 du parcours utilisateur SignUpOrSignIn en supposant que vous utilisez les packs de démarrage de stratégie personnalisée LocalAccount.

   Si vous avez commencé à partir d’un au dossier pack de démarrage ou si vous avez personnalisé le parcours utilisateur en ajoutant ou en supprimant des étapes d’orchestration, assurez-vous que le numéro de l’élément order correspond au numéro spécifié dans le parcours utilisateur pour l’étape de l’émetteur de jeton. Par exemple, dans les autres dossiers du pack de démarrage, le numéro d’étape correspondant est 7 pour SocialAndLocalAccounts, 6 pour SocialAccounts et 9 pour SocialAndLocalAccountsWithMfa.

   <UserJourneys>
   <UserJourney Id="SignUpOrSignIn">
     <OrchestrationSteps>
       <OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="AkamaiSaml2AssertionIssuer"/>
     </OrchestrationSteps>
   </UserJourney>
   </UserJourneys>
   

   L’élément de partie de confiance détermine le protocole que votre application utilise. Par défaut, il s’agit de OpenId. La valeur de l’élément Protocol doit être modifiée en SAML. Les revendications de sortie créent le mappage de revendications à l’assertion SAML.

   Remplacez la totalité de l’élément <TechnicalProfile> dans l’élément <RelyingParty> par le fichier XML de profil technique suivant.

    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>
   

   Votre fichier de stratégie final pour la partie de confiance final doit ressembler au code XML suivant :

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <TrustFrameworkPolicy
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
    PolicySchemaVersion="0.3.0.0"
    TenantId="fabrikam.onmicrosoft.com"
    PolicyId="B2C_1A_signup_signin_saml"
    PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml">
    <BasePolicy>
      <TenantId>fabrikam.onmicrosoft.com</TenantId>
      <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
    </BasePolicy>
   
    <UserJourneys>
      <UserJourney Id="SignUpOrSignIn">
        <OrchestrationSteps>
          <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="AkamaiSaml2AssertionIssuer"/>
        </OrchestrationSteps>
      </UserJourney>
    </UserJourneys>
    <RelyingParty>
      <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
      <TechnicalProfile Id="PolicyProfile">
        <DisplayName>PolicyProfile</DisplayName>
        <Protocol Name="SAML2"/>
        <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="displayName" />
          <OutputClaim ClaimTypeReferenceId="givenName" />
          <OutputClaim ClaimTypeReferenceId="surname" />
          <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
          <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
          <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
        </OutputClaims>
        <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
      </TechnicalProfile>
    </RelyingParty>
    </TrustFrameworkPolicy>
   

Étape 4 : Charger votre stratégie

Enregistrez vos modifications et chargez les fichiers de stratégie TrustFrameworkBase.xml, TrustFrameworkExtensions.xml (le nouveau) et SignUpOrSigninSAML.xml sur le portail Azure.

1. Connectez-vous au portail Azure.

2. Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Répertoires + abonnements.

3. Dans le portail Azure, recherchez et sélectionnez Azure AD B2C.

4. Sous Stratégies, sélectionnez Identity Experience Framework. Sélectionnez Charger une stratégie personnalisée, puis chargez les deux fichiers de stratégie que vous avez modifiés dans l’ordre suivant :

   • Le fichier de base, par exemple TrustFrameworkBase.xml
   • La stratégie d’extension, par exemple TrustFrameworkExtensions.xml
   • Puis, la stratégie de la partie de confiance comme SignUpOrSigninSAML.xml.

Étape 5 : Télécharger les métadonnées SAML du fournisseur d’identité Azure AD B2C

Une fois les fichiers de stratégie chargés, Azure AD B2C utilise les informations de configuration pour générer le document de métadonnées SAML du fournisseur d’identité que l’application va utiliser. Le document de métadonnées SAML contient les emplacements de services tels que les méthodes de connexion et déconnexion, les certificats, etc.

• Les métadonnées de stratégie Azure AD B2C sont disponibles à l’URL suivante : https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

• Remplacez <tenant-name> par le nom de votre locataire Azure AD B2C. Remplacez <policy-name> par le nom (ID) de la stratégie. Voici un exemple : https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata.

Téléchargez les métadonnées SAML et enregistrez-les localement sur votre appareil. Cette procédure est nécessaire en vue de l’étape suivante pour terminer la configuration dans Akamai Enterprise Application Access.

Étape 6 : Inscrire l’application Akamai Enterprise Application Access auprès d’Azure AD B2C

Pour qu’Azure AD B2C approuve Akamai Enterprise Application Access, créez une inscription d’application Azure AD B2C. L’inscription contient des informations de configuration telles que le point de terminaison des métadonnées de l’application.

1. Connectez-vous au portail Azure.

2. Si vous avez accès à plusieurs locataires, sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre locataire Azure AD B2C à partir du menu Répertoires + abonnements.

3. Dans le menu de gauche, sélectionnez Azure AD B2C. Ou sélectionnez Tous les services, puis recherchez et sélectionnez Azure AD B2C.

4. Sélectionnez Inscriptions d’applications, puis Nouvelle inscription.

5. Entrez un Nom pour l’application. Par exemple, entrez Akamai B2C Enterprise Application Access.

6. Sous Types de comptes pris en charge, sélectionnez Comptes de cet annuaire organisationnel uniquement (B2C uniquement – Locataire unique).

7. Sous URI de redirection, sélectionnez Web, puis entrez l’URL Akamai définie dans Akamai Enterprise Application Access sous Setting\General à l’étape 1. Par exemple : https://fabrikam.login.go.akamai-access.com/saml/sp/response.

8. Sélectionnez Inscription.

Étape 7 : Configurer l’application Akamai Enterprise Application Access dans Azure AD B2C

Pour SAML, vous devez configurer plusieurs propriétés dans le manifeste de l’inscription d’application.

1. Dans le portail Azure, accédez à l’inscription d’application que vous avez créée à l’étape 3.

2. Sous Gérer, sélectionnez Manifeste pour ouvrir l’éditeur de manifeste. Modifiez ensuite les propriétés décrites dans les sections suivantes.

Ajouter l’identificateur

Quand l’application SAML Akamai Enterprise Application Access envoie une requête à Azure AD B2C, la demande d’authentification SAML inclut un attribut Issuer. La valeur de cet attribut est généralement identique à la valeur entityID des métadonnées de l’application. Azure AD B2C utilise cette valeur pour rechercher l’inscription d’application dans le répertoire et lire la configuration. Pour que cette recherche aboutisse, l’identifierUri dans le manifeste de l’inscription d’application doit contenir une valeur correspondant à l’attribut Issuer.

Dans le manifeste de l’inscription, recherchez le paramètre identifierURIs et ajoutez la valeur IssuerURI définie à l’étape 2, Azure AD B2C ClaimsProvider.

Exemple :

"identifierUris": [
		"https://fabrikam.login.go.akamai-access.com/saml/sp/response"
	],

Cette valeur sera la même que celle configurée dans les demandes d’authentification SAML pour EntityId au niveau de l’application, et la valeur entityID dans les métadonnées de l’application. Vous devez également rechercher le paramètre accessTokenAcceptedVersion et lui attribuer la valeur 2.

Étape 8 : Configurer les paramètres d’authentification pour le fournisseur d’identité Azure AD B2C dans Akamai Enterprise Application Access

Mettez à jour votre fournisseur d’identité Azure AD B2C Akamai Enterprise Application Access avec des informations d’authentification telles que les URL de la partie de confiance.

1. Connectez-vous à Enterprise Center https://control.akamai.com/

2. Dans le menu de navigation d’Enterprise Center, sélectionnez Application Access > Identity & Users > Identity Providers.

3. Sélectionnez le nom du fournisseur d’identité créé à l’étape 1.

4. Chargez le fichier de métadonnées SAML Azure AD B2C que vous avez téléchargé à l’étape 5.

5. Pour charger le fichier metadata.xml, sélectionnez Choose file.

   

6. Sélectionnez Save and Deploy.

Étape 9 : Déployer des connecteurs Akamai Enterprise Application Access dans votre centre de données privé

Pour autoriser l’accès à une application privée, déployez un ou plusieurs connecteurs Akamai Enterprise Application Access dans le centre de données privé où réside votre application. Veillez à ce que les connecteurs puissent atteindre votre application privée et disposent d’un accès sortant au cloud Akamai.

Étape 10 : Définir une application d’accès dans Akamai Enterprise Application Access pour l’application privée

1. Définissez et déployez une application d’accès dans Akamai Enterprise Application Access.

2. Quand vous définissez l’application d’accès

   • Associez-la à la définition de fournisseur d’identité Azure AD B2C Enterprise Application Access que vous avez créée dans le cadre des étapes précédentes.

   • Configurez l’authentification côté application pour activer l’authentification unique dans l’application privée :

     • Option 1 : Configurer des en-têtes HTTP personnalisés pour une application d’accès
     • Option 2 : Configurer OpenID Connect pour une application d’accès

Option 1 : En-têtes HTTP

Dans cet exemple, nous allons utiliser une application docker qui affiche des en-têtes : header-demo-app. Quand l’application a été déployée dans un environnement privé et qu’un connecteur est capable d’y accéder, créez une application de type HTTP personnalisée en suivant la documentation Akamai sur la configuration d’en-têtes HTTP personnalisés pour une application d’accès.

1. Sous Authentication, sélectionnez le fournisseur d’identité SAML Azure AD B2C créé dans le cadre des étapes précédentes.

2. Dans la section Advanced de l’application, mappez l’en-tête HTTP aux attributs SAML émis par Azure AD B2C dans la réponse SAML en cas d’authentification réussie.

Exemple :

Testez l’application en sélectionnant l’URL Akamai pour l’application web de type HTTP personnalisée que vous avez créée.

Option 2 : OpenID Connect

Dans cet exemple, vous allez utiliser une application web ASP.NET MVC qui connecte les utilisateurs à l’aide du middleware OWIN (Open Web Interface for .NET) et de la plateforme d’identités Microsoft.

1. Configurez le pontage OIDC vers SAML dans l’IdP SAML Azure AD B2C créé avec les étapes précédentes.

   

2. Créez une application de type HTTP personnalisée en suivant la page sur la configuration d’OpenID Connect pour une application d’accès.

3. Sous Authentication, sélectionnez le fournisseur d’identité SAML Azure AD B2C créé dans le cadre des étapes précédentes pour l’application d’en-tête HTTP.

   

4. Dans Advanced, sélectionnez OpenID Connect 1.0 comme mécanisme d’authentification, puis sélectionnez Save.

   

5. Un nouvel onglet OpenID s’affiche. Copiez l’URL de découverte qui sera utilisée plus tard pour les étapes de configuration du composant OWIN pour tester l’application.

   

6. Dans la section Claims, définissez les revendications qu’Akamai émettra pour l’application OIDC, en mappant leurs valeurs aux attributs SAML fournis par Azure AD B2C dans la réponse SAML en cas d’authentification réussie. Ces revendications doivent correspondre ce que vous avez défini à l’étape précédente pour la configuration du pontage OIDC vers SAML dans le fournisseur d’identité SAML Azure AD B2C.

   

7. Remplacez la classe de démarrage par le code suivant dans l’application web ASP.NET MVC.

   Ces quelques modifications permettent de configurer l’octroi du flux de code d’autorisation. Le code d’autorisation sera utilisé pour l’obtention de jetons au point de terminaison de jeton pour l’application. La classe introduit également l’adresse des métadonnées afin de définir le point de terminaison de découverte pour l’obtention de métadonnées auprès d’Akamai.

   public class Startup
   {
        // The Client ID is used by the application to uniquely identify itself to Azure AD.
        string clientId = System.Configuration.ConfigurationManager.AppSettings["ClientId"];
   
        //App Client Secret to redeem the code for an access token
        string ClientSecret = System.Configuration.ConfigurationManager.AppSettings["ClientSecret"];
   
        // RedirectUri is the URL where the user will be redirected to after they sign in.
        string redirectUri = System.Configuration.ConfigurationManager.AppSettings["RedirectUri"];
   
        // PostLogoutRedirectUri is the URL where the user will be redirected to after they sign out
        string PostLogoutRedirectUri = System.Configuration.ConfigurationManager.AppSettings["PostLogoutRedirectUri"];
   
        //Authority is the URL for authority
        string authority = System.Configuration.ConfigurationManager.AppSettings["Authority"];
   
        //discovery endpoint for obtaining metadata
        string MetadataAddress = System.Configuration.ConfigurationManager.AppSettings["MetadataAddress"];
   
   
        /// <summary>
        /// Configure OWIN to use OpenIdConnect
        /// </summary>
        /// <param name="app"></param>
        public void Configuration(IAppBuilder app)
      {
        app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
   
        app.UseCookieAuthentication(new CookieAuthenticationOptions());
        app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                // Sets the ClientId, authority, RedirectUri as obtained from web.config
                ClientId = clientId,
                Authority = authority,
                RedirectUri = redirectUri,
                MetadataAddress = MetadataAddress,
                // PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page
                PostLogoutRedirectUri = redirectUri,
                RedeemCode = true,
                Scope = OpenIdConnectScope.OpenIdProfile,
                // ResponseType is set to request the code id_token - which contains basic information about the signed-in user
                ResponseType = OpenIdConnectResponseType.Code,
                 // OpenIdConnectAuthenticationNotifications configures OWIN to send notification of failed authentications to OnAuthenticationFailed method
                Notifications = new OpenIdConnectAuthenticationNotifications
                {
                    AuthenticationFailed = OnAuthenticationFailed
                }
            }
        );
    }
   
    /// <summary>
    /// Handle failed authentication requests by redirecting the user to the home page with an error in the query string
    /// </summary>
    /// <param name="context"></param>
    /// <returns></returns>
    private Task OnAuthenticationFailed(AuthenticationFailedNotification<OpenIdConnectMessage, OpenIdConnectAuthenticationOptions> context)
    {
        context.HandleResponse();
        context.Response.Redirect("/?errormessage=" + context.Exception.Message);
        return Task.FromResult(0);
       }
   }
   

8. Dans le fichier web.config, ajoutez l’adresse des métadonnées, remplacez clientId, clientsecret, authority, redirectUri et PostLogoutRedirectUri par les valeurs de l’application Akamai dans appSettings.

   Vous trouverez ces valeurs à l’étape précédente 5 sous l’onglet OpenID de l’application HTTP Akamai, où vous avez créé Discovery URL=MetadataAddress. redirectUri est l’adresse locale utilisée par le connecteur Akamai pour la résolution en application OIDC locale. Authority est le authorization_endpoint que vous pouvez trouver dans votre .well-known/openid-configurationdocument.

   URL de découverte : https://fabrikam.login.go.akamai-access.com/.well-known/openid-configuration

    <appSettings>
      <add key="ClientId" value="xxxxxxxxxxxxxxxxxx" />
      <add key="ClientSecret" value="xxxxxxxxxxxxxxxxxx" />
      <add key="Authority" value="https://fabrikam.login.go.akamai-access.com/oidc/oauth" />
      <add key="redirectUri" value="http://oidcapp.identity.mistermik.com/" />
      <add key="PostLogoutRedirectUri" value="https://oidc-test.go.akamai-access.com/" />
      <add key="MetadataAddress" value="https://fabrikam.login.go.akamai-access.com/.well-known/openid-configuration" />
    </appSettings>
   

   Testez l’application en sélectionnant l’URL Akamai pour l’application web de type HTTP personnalisée créée.

   

Test de la solution

1. Accédez à l’URL de l’application à l’aide de l’URL externe spécifiée dans Akamai Enterprise Application Access.

2. Un utilisateur non authentifié est redirigé vers la page de connexion Azure AD B2C.

3. Sélectionnez le fournisseur d’identité dans la liste affichée sur la page.

4. Connectez-vous en tant qu’utilisateur final à l’aide des informations d’identification liées à Azure AD B2C.

5. Quand l’authentification réussit, l’utilisateur final est redirigé vers l’application et connecté à l’application en tant qu’utilisateur final.