Condividi tramite

Configurare Azure Active Directory B2C con Akamai Enterprise Application Access per l'accesso SSO e proteggere l'accesso ibrido

  • Articolo

Questa esercitazione di esempio descrive come integrare l'autenticazione di Azure Active Directory B2C (Azure AD B2C) con Akamai Enterprise Application Access. Akamai Enterprise Application Access è una soluzione ZTNA (Zero Trust Network Access) che consente l'accesso remoto sicuro alle applicazioni moderne e legacy che risiedono nei data center privati. Akamai Enterprise Application Access federato con Identity Provider (IdP) Azure AD B2C per autenticare gli utenti e quindi usa i criteri di autorizzazione per eseguire una valutazione continua dell'identità, del dispositivo, dell'applicazione e del contesto di richiesta prima di consentire l'accesso alle applicazioni private.

Questa funzionalità è disponibile solo per i criteri personalizzati. Per i passaggi di installazione, selezionare Criteri personalizzati nel selettore precedente.

Prerequisiti

Per iniziare, è necessario:

  • Contratto Akamai Enterprise Access. Se non ne hai uno, ottieni una versione di valutazione gratuita.

  • Una sottoscrizione di Azure. Se non si possiede una sottoscrizione, è possibile ottenere un account gratuito.

  • Un tenant di Azure AD B2C collegato alla sottoscrizione di Azure.

  • Un'appliance virtuale distribuita dietro il firewall nel data center o in ambienti cloud ibridi per distribuire il connettore Akamai Enterprise Application Access

  • Applicazione che usa le intestazioni per l'autenticazione. In questo esempio si userà un'applicazione che visualizza le intestazioni docker header-demo-app.

  • OPPURE un'applicazione OpenID Connessione (OIDC). In questo esempio si userà un'app Web MVC ASP.NET che consente agli utenti di accedere usando il middleware Open Web Interface for .NET (OWIN) e Microsoft Identity Platform.

Descrizione dello scenario

In questo scenario si abiliterà l'autenticazione di Azure AD B2C per gli utenti finali mentre tentano di accedere ad applicazioni private protette da Akamai Enterprise Application Access.

I componenti coinvolti in questa integrazione sono:

  • Azure AD B2C: provider di identità SAML responsabile dell'autenticazione degli utenti finali.

  • Akamai Enterprise Application Access: servizio cloud ZTNA responsabile della protezione dell'accesso alle applicazioni private con applicazione continua dei criteri ZTNA.

  • Akamai Enterprise Application Access Connessione or: appliance virtuale distribuita nel data center privato. Consente la connettività sicura alle app private senza aprire porte firewall in ingresso del data center.

  • Applicazione: un servizio o un'applicazione distribuita nel data center privato a cui gli utenti finali devono accedere.

L'utente esegue l'autenticazione ad Azure AD B2C (come IDP SAML) che risponderà ad Akamai Enterprise Application Access (il provider di servizi) con un'asserzione SAML. Akamai Enterprise Application Access esegue il mapping delle informazioni dell'asserzione SAML e costruisce attestazioni OpenID o inserisce intestazioni HTTP contenenti informazioni sull'utente. Akamai Enterprise Application Access passerà quindi l'applicazione accessibile tramite il connettore Akamai Enterprise Application Access. Nell'esempio l'applicazione visualizzerà il contenuto di queste intestazioni. Nel caso d'uso dell'applicazione OIDC visualizzerà le attestazioni dell'utente.

Il diagramma seguente illustra come Akamai Enterprise Application Access (EAA) si integra con Azure AD B2C.

Screenshot shows the integration architecture.

  1. Un utente finale tenta di accedere a un'applicazione ospitata nel data center privato usando l'URL esterno dell'applicazione registrato in Akamai Enterprise Application Access.

  2. Akamai Enterprise Application Access reindirizza l'utente finale non autenticato ad Azure AD B2C per l'autenticazione.

  3. Dopo aver eseguito l'autenticazione, Azure AD B2C reindirizza l'utente di nuovo ad Akamai Enterprise Application Access con un'asserzione SAML.

  4. Akamai Enterprise Application Access usa le informazioni sull'identità dell'asserzione SAML per identificare l'utente e determinare se l'utente è autorizzato ad accedere all'applicazione richiesta.

  5. Akamai Enterprise Application Access costruisce attestazioni OIDC o inserisce intestazioni HTTP inviate all'applicazione.

  6. L'applicazione usa queste informazioni per identificare l'utente autenticato e crea una sessione dell'applicazione per l'utente finale.

Eseguire l'onboarding con Akamai Enterprise Application Access

Per iniziare a usare Akamai Enterprise Application Access, vedere la guida introduttiva all'accesso alle applicazioni Enterprise akamai.

Passaggio 1: Aggiungere Azure AD B2C come IDP SAML in Akamai Enterprise Application Access

Akamai Enterprise Application Access supporta la federazione SAML con provider di identità cloud come Azure AD B2C. Aggiungere Azure AD B2C come IDP SAML di terze parti in Akamai Enterprise Application Access.

  1. Accedere a Enterprise Center https://control.akamai.com/

  2. Nel menu di spostamento di Enterprise Center selezionare Application Access Identity Users Identity Providers .In the Enterprise Center navigation menu, select Application Access > Identity Users > Identity & Providers.

  3. Selezionare Aggiungi provider di identità (+).

  4. Immettere un nome, una descrizione e selezionare il tipo di provider come SAML di terze parti.

  5. Seleziona Continua. Verrà visualizzata la pagina di configurazione del provider di identità.

  6. In Impostazioni> Generale immettere un URL per Identity Server. È possibile selezionare Usa dominio Akamai o Usa il dominio. Se si usa un dominio personalizzato, usare un certificato autofirmato o usare il certificato personalizzato caricato.

  7. In Autenticazione immettere lo stesso URL definito nel passaggio precedente in Generale e selezionare Salva.

    Screenshot shows the akamai settings.

Passaggio 2: Registrare un'applicazione SAML in Azure AD B2C

  1. Ottenere i pacchetti di avvio dei criteri personalizzati da GitHub, quindi aggiornare i file XML nello starter pack LocalAccounts con il nome del tenant di Azure AD B2C:

    • È possibile scaricare il file ZIP o clonare il repository:

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

    • In tutti i file nella directory LocalAccounts sostituire la stringa yourtenant con il nome del tenant di Azure AD B2C. Ad esempio, se il nome del tenant B2C è fabrikam, tutte le istanze di yourtenant.onmicrosoft.com diventano fabrikam.onmicrosoft.com.

  2. Creare un certificato di firma per Azure AD B2C per firmare la risposta SAML inviata ad Akamai Enterprise Application Access:

    a. Ottenere un certificato. Se non si ha già un certificato, è possibile usare un certificato autofirmato.

    b. Caricare il certificato nel tenant di Azure AD B2C. Prendere nota del nome perché sarà necessario nei TechnicalProfile passaggi successivi.

  3. Abilitare i criteri per connettersi a un'applicazione SAML.

    a. Aprire LocalAccounts\TrustFrameworkExtensions.xml nel pacchetto Starter di criteri personalizzati. Trovare l'elemento ClaimsProviders. Se non esiste, aggiungerlo sotto l'elemento TrustFrameworkPolicy radice e aggiungere il frammento XML seguente per implementare il generatore di risposte 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. Sostituire con l'URL issuerUri akamai definito in Akamai Enterprise Application Access > Setting General nel passaggio 1

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

    • Sostituire B2C_1A_AkamaiSAMLSigningCert con il nome della chiave del criterio caricata.

Passaggio 3- Creare un criterio di iscrizione o di accesso configurato per SAML

  1. Creare una copia del SignUpOrSignin.xml file nella directory di lavoro del starter pack e salvarla con un nuovo nome. Questo articolo usa SignUpOrSigninSAML.xml come esempio. Questo file è il file dei criteri per la relying party. È configurato per emettere una risposta JWT per impostazione predefinita.

  2. Aprire il file nell'editor SignUpOrSigninSAML.xml preferito.

  3. Aggiornare tenant-name con il nome del tenant di Azure AD B2C, modificare i PolicyId valori e PublicPolicyUri dei criteri in B2C_1A_signup_signin_saml e 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. Al termine del percorso utente, Azure AD B2C contiene un SendClaims passaggio. Questo passaggio fa riferimento al profilo tecnico dell'autorità di certificazione token. Per emettere una risposta SAML anziché la risposta JWT predefinita, modificare il SendClaims passaggio per fare riferimento al nuovo profilo tecnico dell'autorità di certificazione token SAML, Saml2AssertionIssuer.

    Aggiungere il frammento XML seguente subito prima dell'elemento <RelyingParty> . Questo codice XML sovrascrive il SignUpOrSignIn passaggio di orchestrazione 4 nel percorso utente presupponendo che si usino i LocalAccount Pacchetti di avvio dei criteri personalizzati.

    Se si è iniziato da una cartella diversa nel pacchetto starter o è stato personalizzato il percorso utente aggiungendo o rimuovendo i passaggi di orchestrazione, assicurarsi che il numero nell'elemento order corrisponda al numero specificato nel percorso utente per il passaggio dell'autorità di certificazione del token. Ad esempio, nelle altre cartelle starter pack, il numero di passaggio corrispondente è 7 per SocialAndLocalAccounts, 6 per SocialAccountse 9 per SocialAndLocalAccountsWithMfa.

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

    L'elemento relying party determina il protocollo usato dall'applicazione. Il valore predefinito è OpenId. L'elemento Protocol deve essere modificato in SAML. Le attestazioni di output creeranno il mapping delle attestazioni all'asserzione SAML.

    Sostituire l'intero elemento <TechnicalProfile> nell'elemento <RelyingParty> con il seguente codice XML del profilo tecnico.

     <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>

    Il file di criteri finale per la relying party dovrebbe essere simile al codice XML seguente:

    <?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>

Nota

È possibile seguire questo stesso processo per implementare altri tipi di flussi, ad esempio, accesso, reimpostazione della password o flussi di modifica del profilo.

Passaggio 4- Caricare i criteri

Salvare le modifiche e caricare i TrustFrameworkBase.xmlfile di , i nuovi TrustFrameworkExtensions.xml file di criteri e SignUpOrSigninSAML.xml nel portale di Azure.

  1. Accedi al portale di Azure.

  2. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.

  3. Nella portale di Azure cercare e selezionare Azure AD B2C.

  4. In Criteri selezionare Framework dell'esperienza di gestione delle identità. Selezionare Carica criteri personalizzati e quindi caricare i due file di criteri modificati nell'ordine seguente:

    • File di base, ad esempio TrustFrameworkBase.xml
    • Criteri di estensione, ad esempio TrustFrameworkExtensions.xml
    • Quindi i criteri della relying party, ad esempio SignUpOrSigninSAML.xml.

Passaggio 5: Scaricare i metadati SAML idP di Azure AD B2C

Dopo aver caricato i file dei criteri, Azure AD B2C usa le informazioni di configurazione per generare il documento di metadati SAML del provider di identità che verrà usato dall'applicazione. Il documento di metadati SAML contiene i percorsi dei servizi, ad esempio i metodi di accesso, i metodi di disconnessione e i certificati.

  • I metadati dei criteri di Azure AD B2C sono disponibili nell'URL seguente: https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

  • Sostituire <tenant-name> con il nome del tenant di Azure AD B2C. Sostituire <policy-name> con il nome (ID) del criterio. Di seguito è riportato un esempio: https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Scaricare i metadati SAML e salvarli in locale nel dispositivo. Questa operazione è necessaria con il passaggio seguente per completare la configurazione in Akamai Enterprise Application Access.

Passaggio 6- Registrare l'applicazione Akamai Enterprise Application Access in Azure AD B2C

Affinché Azure AD B2C consideri attendibile Akamai Enterprise Application Access, creare una registrazione dell'applicazione Azure AD B2C. La registrazione contiene informazioni di configurazione, ad esempio l'endpoint dei metadati dell'applicazione.

  1. Accedi al portale di Azure.

  2. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.

  3. Nel menu a sinistra selezionare Azure AD B2C. In alternativa, selezionare Tutti i servizi e quindi cercare e selezionare Azure AD B2C.

  4. Selezionare Registrazioni app e quindi Nuova registrazione.

  5. Immettere un nome per l'applicazione. Ad esempio, immettere Akamai B2C Enterprise Application Access.

  6. In Tipi di account supportati selezionare Account solo in questa directory organizzativa (solo B2C - Tenant singolo).

  7. In URI di reindirizzamento selezionare Web e quindi immettere l'URL Akamai definito in Akamai Enterprise Application Access Setting\General nel passaggio 1. Ad esempio, https://fabrikam.login.go.akamai-access.com/saml/sp/response.

  8. Selezionare Registra.

Passaggio 7: Configurare l'applicazione Akamai Enterprise Application Access in Azure AD B2C

Per SAML, è necessario configurare diverse proprietà nel manifesto della registrazione dell'applicazione.

  1. Nella portale di Azure passare alla registrazione dell'applicazione creata nel passaggio 3.

  2. In Gestisci selezionare Manifesto per aprire l'editor manifesto. Modificare quindi le proprietà descritte nella sezione seguente.

Aggiungere l'identificatore

Quando l'applicazione SAML Akamai Enterprise Application Access effettua una richiesta ad Azure AD B2C, la richiesta di autenticazione SAML include un Issuer attributo. Il valore di questo attributo è in genere uguale al valore dei metadati entityID dell'applicazione. Azure AD B2C usa questo valore per cercare la registrazione dell'applicazione nella directory e leggere la configurazione. Affinché questa ricerca abbia esito positivo, identifierUri nel manifesto di registrazione dell'applicazione deve essere popolato con un valore corrispondente all'attributo Issuer .

Screenshot shows the b2c saml configuration.

Nel manifesto di registrazione trovare il identifierURIs parametro e aggiungere il valore IssuerURI definito nel passaggio 2, Azure AD B2C ClaimsProvider.

Esempio:

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

Questo valore sarà lo stesso valore configurato nelle richieste SAML AuthN per EntityId all'applicazione e il entityID valore nei metadati dell'applicazione. Sarà anche necessario trovare il accessTokenAcceptedVersion parametro e impostare il valore su 2.

Importante

Se non si aggiorna l'oggetto accessTokenAcceptedVersion a 2 verrà visualizzato un messaggio di errore che richiede un dominio verificato.

Passaggio 8: Configurare le impostazioni di autenticazione per l'IDP di Azure AD B2C in Akamai Enterprise Application Access

Aggiornare akamai Enterprise Application Access Azure AD B2C IdP con informazioni di autenticazione come URL relying party.

  1. Accedere a Enterprise Center https://control.akamai.com/

  2. Nel menu di spostamento di Enterprise Center selezionare Application Access Identity Users Identity Providers .In the Enterprise Center navigation menu, select Application Access > Identity Users > Identity & Providers.

  3. Selezionare il nome del provider di identità creato nel passaggio 1.

  4. Caricare il file di metadati SAML di Azure AD B2C scaricato nel passaggio 5.

  5. Per caricare il file metadata.xml, selezionare Scegli file.

    Screenshot shows the metadata file.

  6. Selezionare Salva e distribuisci.

Passaggio 9: Distribuire gli Connessione or di accesso alle applicazioni Enterprise Akamai nel data center privato

Per abilitare l'accesso a un'applicazione privata, distribuire uno o più connettori Akamai Enterprise Application Access nel data center privato in cui risiede l'applicazione. Assicurarsi che i connettori possano raggiungere l'applicazione privata e avere accesso in uscita al cloud Akamai.

Passaggio 10: Definire un'applicazione di accesso in Akamai Enterprise Application Access per l'applicazione privata

  1. Definire e distribuire un'applicazione di accesso in Akamai Enterprise Application Access.

  2. Quando si definisce l'applicazione di accesso

Opzione 1: Intestazioni HTTP

In questo esempio si userà un'applicazione che visualizza le intestazioni docker header-demo-app. Dopo aver distribuito l'applicazione in un ambiente privato e un connettore è in grado di accedere all'applicazione, creare un'applicazione tipo HTTP personalizzato seguendo la documentazione akamai Configurare intestazioni HTTP personalizzate per un'applicazione di accesso.

  1. In Autenticazione selezionare l'IdP SAML di Azure AD B2C creato nei passaggi precedenti.

Screenshot shows the akamai authn application.

  1. Nella sezione Avanzate dell'applicazione eseguire il mapping dell'intestazione HTTP agli attributi SAML rilasciati da Azure AD B2C nella risposta SAML in caso di autenticazione riuscita.

Esempio:

Nome intestazione Attributo
ps-sso-first http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
ps-sso-last http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
ps-sso-EmailAddress emailaddress
ps-sso-uid objectId

Screenshot shows the akamai header app mapping.

Testare l'applicazione selezionando l'URL Akamai per l'applicazione Web tipo HTTP personalizzato creata.

Screenshot shows the akamai header app results.

Opzione 2: OpenID Connessione

In questo esempio si userà un'app Web MVC ASP.NET che consente agli utenti di accedere usando il middleware Open Web Interface for .NET (OWIN) e Microsoft Identity Platform.

  1. Configurare OIDC in SAML bridging in Azure AD B2C SAML IdP creato con i passaggi precedenti.

    Screenshot shows the akamai oidc app oidc settings.

  2. Creare un'applicazione tipo HTTP personalizzata seguendo l'istruzione Configure OpenID Connessione for an Access Application (Configura openID Connessione per un'applicazione di access).

  3. In Autenticazione selezionare l'IdP SAML di Azure AD B2C creato nei passaggi precedenti in base all'applicazione intestazione HTTP.

    Screenshot shows the akamai authn app settings.

  4. In Avanzate selezionare OpenID Connessione 1.0 come meccanismo di autenticazione e quindi selezionare Salva.

    Screenshot shows the akamai oidc app authentication settings.

  5. Viene visualizzata una nuova scheda OpenID , copiare l'URL di individuazione necessario più avanti nei passaggi durante la configurazione del componente OWIN per il test dell'applicazione.

    Screenshot shows the akamai oidc app settings.

  6. Nella sezione Attestazioni definire le attestazioni che Akamai emetterà per l'applicazione OIDC, eseguendo il mapping dei valori agli attributi SAML forniti da Azure AD B2C nella risposta SAML in caso di autenticazione riuscita. Queste attestazioni devono eseguire il mapping di quanto definito nel passaggio precedente durante la configurazione dell'OIDC al bridging SAML in Azure AD B2C SAML IdP.

    Screenshot shows the akamai oidc app claim settings.

  7. Sostituire la classe di avvio con il codice seguente nell'app Web MVC ASP.NET.

    Queste poche modifiche configurano la concessione del flusso del codice di autorizzazione, il codice di autorizzazione verrà riscattato per i token nell'endpoint del token per l'applicazione e introduce l'indirizzo dei metadati per impostare l'endpoint di individuazione per ottenere i metadati da 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. web.config Nel file aggiungere l'indirizzo metadati sostituire clientId, clientsecret, authority, redirectUri e PostLogoutRedirectUri con i valori dell'applicazione Akamai in appSettings.

    Questi valori sono disponibili nel passaggio 5 precedente nella scheda OpenID per l'applicazione HTTP Akamai, in cui è stato creato Discovery URL=MetadataAddress. redirectUri è l'indirizzo locale per il connettore Akamai da risolvere nell'applicazione OIDC locale. Authority è il authorization_endpoint che è possibile trovare dal .well-known/openid-configurationdocumento.

    URL di individuazione: 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>

    Testare l'applicazione selezionando l'URL Akamai per l'applicazione Web di tipo HTTP personalizzata creata.

    Screenshot shows the akamai oidc app results.

Test della soluzione

  1. Passare all'URL dell'applicazione usando l'URL esterno specificato in Akamai Enterprise Application Access.

  2. L'utente non autenticato viene reindirizzato alla pagina di accesso di Azure AD B2C.

  3. Selezionare il provider di identità dall'elenco nella pagina.

  4. Accedere come utente finale usando le credenziali collegate ad Azure AD B2C.

  5. Al termine dell'autenticazione, l'utente finale verrà reindirizzato all'applicazione e ha eseguito l'accesso all'applicazione come utente finale.

Risorse aggiuntive