Compartilhar via


Configurar o Azure Active Directory B2C com o Akamai Enterprise Application Access para SSO e acesso híbrido seguro

Neste tutorial de amostra, aprenda a integrar a integrar a autenticação do Azure AD B2C (Azure Active Directory B2C) com o Akamai Enterprise Application Access. O Akamai Enterprise Application Access é uma solução de acesso à rede ZTNA (Confiança Zero) que permite acesso remoto seguro a aplicativos modernos e herdados que residem em datacenters privados. O Akamai Enterprise Application Access federa com o IdP (Provedor de Identidade) Azure AD B2C para autenticar usuários e, em seguida, usa suas políticas de autorização para executar a avaliação contínua da identidade, dispositivo, aplicativo e contexto de solicitação antes de permitir o acesso a aplicativos privados.

Esse recurso só está disponível para políticas personalizadas. Para obter as etapas de instalação, escolha Política personalizada no seletor anterior.

Pré-requisitos

Para começar, você precisará de:

  • Um contrato do Akamai Enterprise Access. Se você não tiver um, obtenha uma avaliação gratuita.

  • Uma assinatura do Azure. Caso você não tenha uma assinatura, obtenha uma conta gratuita.

  • Um locatário do Azure AD B2C vinculado à sua assinatura do Azure.

  • Uma solução de virtualização implantada por trás do firewall em seu datacenter ou em ambientes de nuvem híbrida para implantar o conector do Akamai Enterprise Application Access

  • Um aplicativo que usa cabeçalhos para autenticação. Neste exemplo, usaremos um aplicativo que exibe cabeçalhos docker header-demo-app.

  • OU um aplicativo OIDC (OpenID Connect). Neste exemplo, usaremos um aplicativo Web ASP.NET MVC que conecta usuários usando o middleware OWIN (Open Web Interface para .NET) e a plataforma de identidade da Microsoft.

Descrição do cenário

Nesse cenário, você habilitará a autenticação do Azure AD B2C para usuários finais enquanto eles tentam acessar aplicativos privados protegidos pelo Akamai Enterprise Application Access.

Os componentes envolvidos nessa integração são:

  • Azure AD B2C: o provedor de identidade SAML responsável por autenticar usuários finais.

  • Akamai Enterprise Application Access: o serviço de nuvem ZTNA responsável por proteger o acesso a aplicativos privados com a imposição contínua da política ZTNA.

  • Conector do Akamai Enterprise Application Access: uma solução de virtualização implantada no datacenter privado. Ele permite a conectividade segura com aplicativos privados sem abrir nenhuma porta de firewall de entrada do datacenter.

  • Aplicativo: um serviço ou aplicativo implantado em seu datacenter privado ao qual os usuários finais precisam de acesso.

O usuário se autentica no Azure AD B2C (como IdP do SAML) que responderá ao Akamai Enterprise Application Access (o Provedor de Serviços) com uma declaração SAML. O Akamai Enterprise Application Access mapeia informações da declaração SAML e constrói declarações OpenID ou injeta cabeçalhos HTTP contendo informações sobre o usuário. O Akamai Enterprise Application Access passará isso para o Aplicativo acessível por meio do conector do Akamai Enterprise Application Access. Em nosso exemplo, o aplicativo exibirá o conteúdo desses cabeçalhos. No caso de uso do Aplicativo OIDC, ele exibirá as declarações do usuário.

O diagrama a seguir mostra como o EAA (Akamai Enterprise Application Access) se integra ao Azure AD B2C.

Screenshot shows the integration architecture.

  1. Um usuário final tenta acessar um aplicativo hospedado no datacenter privado usando a URL externa do aplicativo registrada no Akamai Enterprise Application Access.

  2. O Akamai Enterprise Application Access redireciona o usuário final não autenticado para Azure AD B2C para autenticação.

  3. Após a autenticação bem-sucedida o Azure AD B2C redireciona o usuário de volta para o Akamai Enterprise Application Access com uma declaração SAML.

  4. O Akamai Enterprise Application Access usa as informações de identidade da declaração SAML para identificar o usuário e determinar se o usuário tem permissão para acessar o aplicativo solicitado.

  5. O Akamai Enterprise Application Access constrói declarações OIDC ou injeta cabeçalhos HTTP, que são enviados para o aplicativo.

  6. O aplicativo usa essas informações para identificar o usuário autenticado e cria uma sessão de aplicativo para o usuário final.

Integrado com o Akamai Enterprise Application Access

Para começar a usar o Akamai Enterprise Application Access, consulte a guia de introdução do Akamai Enterprise Application Access.

Etapa 1 – Adicionar o Azure AD B2C como um IdP do SAML no Akamai Enterprise Application Access

O Akamai Enterprise Application Access dá suporte à federação SAML com IdPs de nuvem, como Azure AD B2C. Adicione o Azure AD B2C como um IdP do SAML de terceiros no Akamai Enterprise Application Access.

  1. Entrar no Enterprise Center https://control.akamai.com/

  2. No menu de navegação do Enterprise Center, selecione Provedores de Identidade de Usuários > de Identidade & do Application Access>.

  3. Selecione Adicionar provedor de identidade (+).

  4. Insira um nome, uma descrição e selecione o tipo de provedor como SAML de terceiros.

  5. Selecione Continuar. A página de configuração do provedor de identidade é exibida.

  6. Em Configurações>Gerais, insira um URL para o Servidor de Identidade. Você pode selecionar Usar domínio do Akamai ou Usar seu domínio. Se você usar seu próprio domínio, use um certificado autoassinado ou use o certificado personalizado carregado.

  7. Em Autenticação, insira a mesmo URL definido na etapa anterior em Geral e Selecione Salvar.

    Screenshot shows the akamai settings.

Etapa 2 – Registrar um aplicativo SAML no Azure AD B2C

  1. Obtenha os pacotes iniciais de políticas personalizadas no GitHub. Em seguida, atualize os arquivos XML no pacote de início de LocalAccounts com nome de seu locatário do Azure AD B2C:

    • Baixar os arquivos .zip ou clonar o repositório:

      git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
      
    • Em todos os arquivos do diretório LocalAccounts, substitua a cadeia de caracteres yourtenant pelo nome do locatário do Azure AD B2C. Por exemplo, se o nome do locatário do B2C for fabrikam, todas as instâncias de yourtenant.onmicrosoft.com se transformarão em fabrikam.onmicrosoft.com.

  2. Crie um certificado de autenticação para Azure AD B2C para assinar a resposta SAML enviada ao Akamai Enterprise Application Access:

    a. Obter um certificado. Se você ainda não tiver um certificado, será possível usar um certificado autoassinado.

    b. Carregue o certificado para seu locatário do Azure AD B2C. Anote o nome, pois ele será necessário no TechnicalProfile mencionado nas próximas etapas.

  3. Habilitar sua política para se conectar a um aplicativo SAML.

    a. Abra LocalAccounts\TrustFrameworkExtensions.xml no pacote inicial de política personalizada. Localize o elemento ClaimsProviders. Se ele não existir, adicione-o sob o elemento raiz, TrustFrameworkPolicy e adicione o seguinte snippet XML para implementar o gerador de resposta 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. Substitua o issuerUri pelo URL do Akamai definido em Akamai Enterprise Application Access Configuração > Geral na Etapa 1

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

    • Substitua B2C_1A_AkamaiSAMLSigningCert pelo nome da chave de política carregada.

Etapa 3 – Criar uma política de inscrição ou de entrada que seja configurada para SAML

  1. Crie uma cópia do arquivo SignUpOrSignin.xml no diretório de trabalho do pacote inicial e salve-a com um novo nome. Este artigo usa SignUpOrSigninSAML.xml como exemplo. Esse arquivo é seu arquivo de política para a terceira parte confiável. Ele está configurado para emitir uma resposta JWT por padrão.

  2. Abra o arquivo SignUpOrSigninSAML.xml em seu editor preferido.

  3. Atualize tenant-name com o nome do locatário do Azure AD B2C, altere os PolicyId valores e PublicPolicyUri da política para 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. No final do percurso do usuário, o Azure Active Directory B2C contém uma etapa SendClaims. Esta etapa faz referência ao perfil técnico do Emissor do Token. Para emitir uma resposta de SAML em vez da resposta JWT padrão, modifique a etapa SendClaims para fazer referência ao novo perfil técnico do Emissor do token SAML, Saml2AssertionIssuer.

    Adicione o trecho XML a seguir imediatamente antes do elemento <RelyingParty>. Esse XML substitui a etapa de orquestração 4 no percurso do SignUpOrSignIn usuário supondo que você esteja usando os LocalAccount pacotes de início de política personalizados.

    Se você começou em uma pasta diferente no pacote inicial ou personalizou o percurso do usuário adicionando ou removendo etapas de orquestração, verifique se o número no elemento order corresponde ao número especificado no percurso do usuário para a etapa de emissor do token. Por exemplo, nas outras pastas do pacote inicial, o número da etapa correspondente é 7 para SocialAndLocalAccounts, 6 para SocialAccounts e 9 para SocialAndLocalAccountsWithMfa.

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

    O elemento de terceira parte confiável determina o protocolo que será usado pelo seu aplicativo. O padrão é OpenId. O elemento Protocol deve ser configurado como SAML. As declarações de saída criarão o mapeamento de declarações para a instrução de declaração SAML.

    Substitua todo o elemento <TechnicalProfile> no elemento <RelyingParty> pelo XML de perfil técnico a seguir.

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

    O arquivo final de política para a terceira parte confiável deve ser semelhante ao seguinte código XML:

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

Observação

Siga esse mesmo processo para implementar outros tipos de fluxos, por exemplo, fluxos de edição de perfil, de entrada e de redefinição de senha.

Etapa 4 – Carregar sua política

Salve suas alterações e carregue o TrustFrameworkBase.xml, o novo TrustFrameworkExtensions.xml e SignUpOrSigninSAML.xmlos arquivos de política no portal do Azure.

  1. Entre no portal do Azure.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.

  3. No portal do Azure, pesquise e selecione Azure AD B2C.

  4. Em Políticas, selecione Estrutura de experiência de identidade. SelecioneCarregar o Azure Policy Personalizado e carregue os dois arquivos de política alterados, na seguinte ordem:

    • O arquivo base, por exemplo TrustFrameworkBase.xml
    • A política de extensão, por exemploTrustFrameworkExtensions.xml
    • Em seguida, a política de terceira parte confiável, como SignUpOrSigninSAML.xml.

Etapa 5 – Baixar os metadados IdP do SAML do Azure AD B2C

Depois que os arquivos de política forem carregados, o Azure Active Directory B2C usará as informações de configuração para gerar o documento de metadados SAML do provedor de identidade que o aplicativo usará. O documento de metadados SAML contém os locais dos serviços, como métodos de entrada, métodos de saída e certificados.

  • Os metadados de política do Azure AD B2C estão disponíveis no seguinte URL: https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

  • Substitua <tenant-name> pelo nome de seu locatário do Azure AD B2C. Substitua <policy-name> pelo nome (ID) da política. Aqui está um exemplo: https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Baixe os metadados SAML e salve-os localmente em seu dispositivo. Isso é necessário com a etapa a seguir para concluir a configuração no Akamai Enterprise Application Access.

Etapa 6 – Registrar o aplicativo Akamai Enterprise Application Access no Azure AD B2C

Para que o Azure AD B2C confie no Akamai Enterprise Application Access, crie um registro de aplicativo do Azure Active Directory B2C. O registro contém informações de configuração, como o ponto de extremidade de metadados do aplicativo.

  1. Entre no portal do Azure.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o seu locatário do Azure Active Directory B2C no menu Diretórios + assinaturas.

  3. No menu à esquerda, selecione Azure Active Directory B2C. Ou selecione Todos os serviços e, em seguida, pesquise e selecione Azure Active Directory B2C.

  4. Escolha Registros de aplicativo e Novo registro.

  5. Insira um Nome para o aplicativo. Por exemplo, insira Akamai B2C Enterprise Application Access.

  6. Em Tipos de conta com suporte, selecione Contas somente neste diretório organizacional (somente B2C – único locatário).

  7. Em URI de redirecionamento, selecione Web e, em seguida, insira o URL do Akamai definida em Akamai Enterprise Application Access Setting\General na Etapa 1. Por exemplo, https://fabrikam.login.go.akamai-access.com/saml/sp/response.

  8. Selecione Registrar.

Etapa 7 – Configurar o aplicativo Akamai Enterprise Application Access no Azure AD B2C

Em SAML, é necessário configurar várias propriedades no manifesto do registro de aplicativo.

  1. No portal do Microsoft Azure, acesse o registro de aplicativo criado na Etapa 3.

  2. Em Gerenciar, selecione Manifesto para abrir o editor de manifesto. Em seguida, modifique as propriedades descritas na seção a seguir.

Adicionar o identificador

Quando o aplicativo SAML do Akamai Enterprise Application Access faz uma solicitação para o Azure AD B2C, a solicitação de autenticação SAML inclui um atributo Issuer. O valor desse atributo normalmente é o mesmo que o valor entityID de metadados do aplicativo. O Azure AD B2C usa esse valor para pesquisar o registro de aplicativo no diretório e ler a configuração. Para que essa pesquisa seja realizada com sucesso, identifierUri no manifesto de registro de aplicativo deverá ser preenchido com um valor que corresponda ao atributo Issuer.

Screenshot shows the b2c saml configuration.

No manifesto de registro, localize o parâmetro identifierURIs e adicione o valor issuerURI definido na Etapa 2, Provedor de declarações do Azure AD B2C.

Exemplo:

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

Este será o mesmo valor configurado nas solicitações AuthN SAML para EntityId no aplicativo, e o valor entityID nos metadados do aplicativo. Você também precisará localizar o parâmetro accessTokenAcceptedVersion e definir o valor como 2.

Importante

Se você não atualizar o accessTokenAcceptedVersion para 2, receberá uma mensagem de erro exigindo um domínio verificado.

Etapa 8 – Definir as configurações de autenticação para o IdP do Azure AD B2C no Akamai Enterprise Application Access

Atualize o IdP de Akamai Enterprise Application Access do Azure AD B2C com informações de autenticação, como URLs de terceira parte confiável.

  1. Entrar no Enterprise Center https://control.akamai.com/

  2. No menu de navegação do Enterprise Center, selecione Provedores de Identidade de Usuários > de Identidade & do Application Access>.

  3. Selecione o Nome do provedor de identidade criado na Etapa 1.

  4. Carregue o arquivo de metadados SAML do Azure AD B2C que você baixou na Etapa 5.

  5. Para carregar o arquivo de metadata.xml, selecione Escolher arquivo.

    Screenshot shows the metadata file.

  6. Selecione Salvar e Implantar.

Etapa 9 – Implantar conectores do Akamai Enterprise Application Access em seu datacenter privado

Para habilitar o acesso a um aplicativo privado, implante um ou mais conectores do Akamai Enterprise Application Access no datacenter privado em que seu aplicativo reside. Verifique se os conectores podem acessar seu aplicativo privado e ter acesso de saída à nuvem do Akamai.

Etapa 10 – Definir um aplicativo de acesso no Akamai Enterprise Application Access para o aplicativo privado

  1. Definir e implantar um aplicativo de acesso no Akamai Enterprise Application Access.

  2. Ao definir o Aplicativo de Acesso

Opção 1: cabeçalhos HTTP

Neste exemplo, usaremos um aplicativo que exibe cabeçalhos docker header-demo-app. Depois que o Aplicativo for implantado em um ambiente privado e um conector for apto a acessar o aplicativo, crie um aplicativo de tipo HTTP personalizado seguindo a documentação do Akamai Configurar cabeçalhos HTTP personalizados para um aplicativo de acesso.

  1. Em Autenticação, selecione o IdP do SAML do Azure AD B2C criado nas etapas anteriores.

Screenshot shows the akamai authn application.

  1. Na seção Avançado do aplicativo, mapeie o cabeçalho HTTP para os atributos SAML emitidos pelo Azure AD B2C na resposta SAML após uma autenticação bem-sucedida.

Exemplo:

Nome do cabeçalho Atributo
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.

Teste o aplicativo selecionando o URL do Akamai para o aplicativo Web tipo HTTP personalizado que você criou.

Screenshot shows the akamai header app results.

Opção 2: OpenID Connect

Neste exemplo, usaremos um aplicativo Web ASP.NET MVC que conecta usuários usando o middleware OWIN (Open Web Interface para .NET) e a plataforma de identidade da Microsoft.

  1. Configure a ponte OIDC para SAML no IdP do SAML do AZURE AD B2C criado com as etapas anteriores.

    Screenshot shows the akamai oidc app oidc settings.

  2. Crie um aplicativo de tipo HTTP personalizado seguindo Configurar o OpenID Connect para um Aplicativo de Acesso.

  3. Em Autenticação, selecione o IdP do SAML do Azure AD B2C criado nas etapas anteriores de acordo com o aplicativo de cabeçalho HTTP.

    Screenshot shows the akamai authn app settings.

  4. Em Avançado, selecione OpenID Connect 1.0 como mecanismo de autenticação e, em seguida, selecione Salvar.

    Screenshot shows the akamai oidc app authentication settings.

  5. Uma nova guia OpenID é exibida, copie o URL de descoberta que é necessária posteriormente nas etapas ao configurar o componente OWIN para testar o aplicativo.

    Screenshot shows the akamai oidc app settings.

  6. Na seção Declarações, defina as declarações que o Akamai emitirá para o aplicativo OIDC, mapeando seus valores para os atributos SAML fornecidos pelo Azure AD B2C na resposta SAML após uma autenticação bem-sucedida. Essas declarações precisam mapear o que você definiu na etapa anterior ao configurar a ponte OIDC para SAML no IdP do SAML do Azure AD B2C.

    Screenshot shows the akamai oidc app claim settings.

  7. Substitua a classe de inicialização pelo código a seguir no aplicativo Web ASP.NET MVC.

    Essas poucas alterações configuram a concessão de fluxo de código de autorização, o código de autorização será resgatado para tokens no ponto de extremidade de token para o aplicativo e introduz o Endereço de Metadados para definir o ponto de extremidade de descoberta para obter metadados do 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. No arquivo web.config, adicione o endereço de Metadados, substitua clientId, clientsecret, authority, redirectUri e PostLogoutRedirectUri pelos valores do aplicativo Akamai no appSettings.

    Você pode encontrar esses valores na etapa anterior 5 na guia OpenID para o aplicativo HTTP Akamai, em que você criou Discovery URL=MetadataAddress. redirectUri é o endereço local do conector do Akamai a ser resolvido para o aplicativo OIDC local. Authority é o authorization_endpoint que você pode encontrar em seu .well-known/openid-configurationdocumento.

    URL de descoberta: 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>
    

    Teste o aplicativo selecionando o URL do Akamai para o aplicativo Web do tipo HTTP Personalizado criado.

    Screenshot shows the akamai oidc app results.

Testar a solução

  1. Navegue até o URL do aplicativo, usando o URL externo especificado no Akamai Enterprise Application Access.

  2. O usuário não autenticado é redirecionado para a página de entrada do Azure AD B2C.

  3. Selecione o IdP na lista na página.

  4. Entre como um usuário final usando credenciais vinculadas ao Azure AD B2C.

  5. Após a autenticação bem-sucedida, o usuário final será redirecionado de volta para o aplicativo e conectado ao aplicativo como o usuário final.

Recursos adicionais