Поделиться через

Настройка Azure Active Directory B2C с помощью Akamai Enterprise Application Access для единого входа и безопасного гибридного доступа

  • Статья

В этом примере руководства описано, как интегрировать проверку подлинности Azure Active Directory B2C (Azure AD B2C) с Akamai Enterprise Application Access. Akamai Enterprise Application Access — это решение ZTNA, которое обеспечивает безопасный удаленный доступ к современным и устаревшим приложениям, которые находятся в частных центрах обработки данных. Akamai Enterprise Application Access федеративные с поставщиком удостоверений (IdP) Azure AD B2C для проверки подлинности пользователей, а затем использует свои политики авторизации для непрерывной оценки удостоверения, устройства, приложения и контекста запроса, прежде чем разрешить доступ к частным приложениям.

Эта возможность доступна только для пользовательских политик. Чтобы ознакомиться с этапами установки, в предыдущем селекторе выберите Настраиваемая политика.

Необходимые компоненты

Чтобы приступить к работе, потребуется следующее.

  • Контракт Akamai Enterprise Access. Если у вас его нет, получите бесплатную пробную версию.

  • Подписка Azure. Если у вас нет подписки, вы можете получить бесплатную учетную запись.

  • Клиент Azure AD B2C, связанный с вашей подпиской Azure.

  • Виртуальная (модуль), развернутая за брандмауэром в центре обработки данных или в гибридных облачных средах для развертывания соединителя Akamai Enterprise Application Access

  • Приложение, использующее заголовки для проверки подлинности. В этом примере мы будем использовать приложение, отображающее заголовки docker header-demo-app.

  • ИЛИ приложение OpenID Подключение (OIDC). В этом примере мы будем использовать веб-приложение ASP.NET MVC, которое выполняет вход пользователей с помощью по промежуточного слоя Open Web Interface for .NET (OWIN) и платформа удостоверений Майкрософт.

Описание сценария

В этом сценарии вы включите проверку подлинности Azure AD B2C для конечных пользователей, пытаясь получить доступ к частным приложениям, защищенным Akamai Enterprise Application Access.

Компоненты, участвующие в этой интеграции, :

  • Azure AD B2C: поставщик удостоверений SAML, отвечающий за проверку подлинности конечных пользователей.

  • Akamai Enterprise Application Access: облачная служба ZTNA, которая отвечает за защиту доступа к частным приложениям с непрерывным применением политик ZTNA.

  • Akamai Enterprise Application Access Подключение or: виртуальная (модуль), развернутая в частном центре обработки данных. Он обеспечивает безопасное подключение к частным приложениям без открытия портов брандмауэра для входящего центра обработки данных.

  • Приложение: служба или приложение, развернутые в частном центре обработки данных, к которым пользователям требуется доступ.

Пользователь проходит проверку подлинности в Azure AD B2C (как SAML IdP), который будет отвечать на доступ к приложениям Akamai Enterprise (поставщик услуг) с утверждением SAML. Akamai Enterprise Application Access сопоставляет сведения из утверждения SAML и создает утверждения OpenID или внедряет заголовки HTTP, содержащие сведения о пользователе. Затем Akamai Enterprise Application Access передает это приложению, доступному через соединитель Akamai Enterprise Application Access. В нашем примере приложение отобразит содержимое этих заголовков. В случае использования приложения OIDC он отобразит утверждения пользователя.

На следующей схеме показано, как Akamai Enterprise Application Access (EAA) интегрируется с Azure AD B2C.

Screenshot shows the integration architecture.

  1. Конечный пользователь пытается получить доступ к приложению, размещенном в частном центре обработки данных, с помощью внешнего URL-адреса приложения, зарегистрированного в Akamai Enterprise Application Access.

  2. Akamai Enterprise Application Access перенаправляет пользователя без проверки подлинности в Azure AD B2C.

  3. После успешной проверки подлинности Azure AD B2C перенаправляет пользователя обратно в Akamai Enterprise Application Access с утверждением SAML.

  4. Akamai Enterprise Application Access использует сведения об удостоверении SAML, чтобы определить пользователя и определить, разрешено ли пользователю получить доступ к запрошенном приложению.

  5. Akamai Enterprise Application Access создает утверждения OIDC или внедряет заголовки HTTP, которые отправляются в приложение.

  6. Приложение использует эти сведения для идентификации пользователя, прошедшего проверку подлинности, и создает сеанс приложения для конечного пользователя.

Подключение к приложению Akamai Enterprise Application Access

Чтобы приступить к работе с Akamai Enterprise Application Access, ознакомьтесь с руководством по началу работы с приложением Akamai Enterprise.

Шаг 1. Добавление Azure AD B2C в качестве поставщика удостоверений SAML в Akamai Enterprise Application Access

Akamai Enterprise Application Access поддерживает федерацию SAML с облачными поставщиками удостоверений, такими как Azure AD B2C. Добавьте Azure AD B2C в качестве стороннего поставщика удостоверений SAML в Akamai Enterprise Application Access.

  1. Вход в Enterprise Center https://control.akamai.com/

  2. В меню навигации Enterprise Center выберите поставщики удостоверений пользователей > удостоверений & доступа к > приложениям.

  3. Выберите добавить поставщика удостоверений (+).

  4. Введите имя, описание и выберите тип поставщика в качестве стороннего SAML.

  5. Выберите Продолжить. Откроется страница конфигурации поставщика удостоверений.

  6. В Параметры> General введите URL-адрес сервера удостоверений. Вы можете выбрать "Использовать домен Akamai" или "Использовать домен". Если вы используете собственный домен, используйте самозаверяющий сертификат или используйте отправленный пользовательский сертификат.

  7. В поле "Проверка подлинности" введите тот же URL-адрес, что и на предыдущем шаге в разделе "Общие" и "Сохранить".

    Screenshot shows the akamai settings.

Шаг 2. Регистрация приложения SAML в Azure AD B2C

  1. Скачайте начальные пакеты настраиваемых политик из GitHub, а затем обновите XML-файлы в начальном пакете LocalAccounts, указав имя своего арендатора Azure AD B2C:

    • Скачайте ZIP-файл или клонируйте репозиторий:

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

    • Во всех файлах в каталоге LocalAccounts замените строку yourtenant именем своего клиента Azure AD B2C. Например, если имя вашего клиента B2C — fabrikam, все экземпляры yourtenant.onmicrosoft.com должны иметь вид fabrikam.onmicrosoft.com.

  2. Создайте сертификат подписи для Azure AD B2C, чтобы подписать ответ SAML, отправленный в Akamai Enterprise Application Access:

    a. Получите сертификат. Если у вас еще нет сертификата, можно использовать самозаверяющий сертификат.

    b. Отправьте сертификат в клиенте Azure AD B2C. Запишите имя, так как оно потребуется в TechnicalProfile упоминание в следующих шагах.

  3. Включите политику для подключения к приложению SAML.

    a. Откройте LocalAccounts\TrustFrameworkExtensions.xml в начальном пакете настраиваемых политик. Найдите элемент ClaimsProviders. Если он не существует, добавьте его в корневой элемент TrustFrameworkPolicy и добавьте следующий фрагмент XML для реализации генератора ответов 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. Замените issuerUri URL-адрес Akamai, определенный в разделе "Общие параметры > доступа к приложениям Akamai Enterprise" на шаге 1.

    • Примере <Item Key="IssuerUri">https://fabrikam.login.go.akamai-access.com/saml/sp/response</Item>

    • Замените B2C_1A_AkamaiSAMLSigningCert именем переданного ключа политики.

Шаг 3. Создание политики регистрации или входа, настроенной для SAML

  1. Создайте копию SignUpOrSignin.xml файла в рабочем каталоге начального пакета и сохраните его с новым именем. Эта статья используется SignUpOrSigninSAML.xml в качестве примера. Он представляет собой файл политики для проверяющей стороны. По умолчанию он настроен на выдачу ответа JWT.

  2. SignUpOrSigninSAML.xml Откройте файл в предпочтительном редакторе.

  3. Обновите tenant-name имя клиента Azure AD B2C, измените и PublicPolicyUri значения PolicyId политики на B2C_1A_signup_signin_saml и 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. В конце пути взаимодействия пользователя Azure AD B2C содержит шаг SendClaims. Этот шаг ссылается на технический профиль издателя маркера. Чтобы выдавать ответ SAML, а не заданный по умолчанию ответ JWT, измените шаг SendClaims, чтобы он ссылался на новый технический профиль издателя маркера SAML — Saml2AssertionIssuer.

    Добавьте следующий фрагмент XML-кода перед элементом <RelyingParty>. Этот XML-код перезаписывает шаг 4 в SignUpOrSignIn пути пользователя, если вы используете LocalAccount начальные пакеты настраиваемой политики.

    Если вы начали из другой папки в начальном пакете или настроили путь взаимодействия пользователя, добавив или удалив шаги оркестрации, убедитесь, что число в элементе order соответствует числу, заданному в пути взаимодействия пользователя для шага издателя маркера. Например, в других папках начального пакета соответствующий номер шага равен 7 для SocialAndLocalAccounts, 6 для SocialAccountsи 9 для SocialAndLocalAccountsWithMfa.

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

    Элемент проверяющей стороны определяет протокол, используемый приложением. Значение по умолчанию — OpenId. Значение элемента Protocol необходимо изменить на SAML. Выходные утверждения будут создавать сопоставление утверждений с утверждением SAML.

    Замените весь элемент <TechnicalProfile> в элементе <RelyingParty> следующим XML-кодом технического профиля.

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

    Окончательный файл политики для проверяющей стороны должен выглядеть подобно приведенному ниже 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>

Примечание.

Вы можете следовать этому же процессу, чтобы реализовать другие типы потоков, например вход, сброс пароля или потоки редактирования профиля.

Шаг 4. Отправка политики

Сохраните изменения и отправьте TrustFrameworkBase.xmlновые TrustFrameworkExtensions.xml файлы и SignUpOrSigninSAML.xml файлы политики в портал Azure.

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. На портале Azure найдите и выберите Azure AD B2C.

  4. В разделе "Политики" выберите Identity Experience Framework. Выберите " Отправить настраиваемую политику", а затем отправьте два измененных файла политики в следующем порядке:

    • Базовый файл, например TrustFrameworkBase.xml
    • Политика расширения, например TrustFrameworkExtensions.xml
    • Затем политика проверяющей стороны, например SignUpOrSigninSAML.xml.

Шаг 5. Скачивание метаданных SAML idP в Azure AD B2C

После отправки файлов политики Azure AD B2C использует сведения о конфигурации, чтобы создать документ метаданных SAML поставщика удостоверений, который будет использоваться приложением. Документ метаданных SAML содержит расположения служб, таких как методы входа, методы выхода и сертификаты.

  • Метаданные политики Azure AD B2C доступны по следующему URL-адресу: https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

  • Замените <tenant-name> именем вашего клиента Azure AD B2C. Замените <policy-name> именем (ID) политики. Приведем пример: https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Скачайте метаданные SAML и сохраните его локально на устройстве. Это необходимо с помощью следующего шага, чтобы завершить настройку в Akamai Enterprise Application Access.

Шаг 6. Регистрация приложения Akamai Enterprise Application Access в Azure AD B2C

Чтобы Azure AD B2C доверял Akamai Enterprise Application Access, создайте регистрацию приложения Azure AD B2C. Эта регистрация содержит сведения о конфигурации, такие как конечная точка метаданных приложения.

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. В меню слева щелкните Azure AD B2C. Либо выберите Все службы, а затем найдите и выберите Azure AD B2C.

  4. Щелкните Регистрация приложений и выберите Новая регистрация.

  5. Введите имя приложения. Например, введите Akamai B2C Enterprise Application Access.

  6. В разделе "Поддерживаемые типы учетных записей" выберите только учетные записи в этом каталоге организации (только B2C — один клиент).

  7. В разделе URI перенаправления выберите веб-сайт и введите URL-адрес Akamai, определенный в параметре доступа к корпоративным приложениям Akamai Enterprise\General на шаге 1. Например, https://fabrikam.login.go.akamai-access.com/saml/sp/response.

  8. Выберите Зарегистрировать.

Шаг 7. Настройка приложения Akamai Enterprise Application Access в Azure AD B2C

Для SAML необходимо настроить несколько свойств в манифесте регистрации приложения.

  1. В портал Azure перейдите к регистрации приложения, созданной на шаге 3.

  2. В разделе Управление выберите Манифест, чтобы открыть редактор манифестов. Затем измените свойства, описанные в следующем разделе.

Добавление идентификатора

Когда приложение AKamai Enterprise Application Access SAML отправляет запрос к Azure AD B2C, запрос проверки подлинности SAML включает Issuer атрибут. Значение этого атрибута обычно совпадает со значением entityID метаданных приложения. В Azure AD B2C это значение используется для поиска регистрации приложения в каталоге и чтения конфигурации. Для успешного identifierUri поиска в манифесте регистрации приложения должно быть заполнено значение, соответствующее атрибуту Issuer .

Screenshot shows the b2c saml configuration.

В манифесте регистрации найдите identifierURIs параметр и добавьте значение IssuerURI , определенное на шаге 2, Azure AD B2C ClaimsProvider.

Пример:

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

Это значение будет совпадать со значением, настроенным в запросах AuthN SAML для EntityId в приложении, и значением entityID в метаданных приложения. Вам также потребуется найти accessTokenAcceptedVersion параметр и задать для параметра значение 2.

Важно!

Если не обновить accessTokenAcceptedVersion до 2, появится сообщение об ошибке, в котором требуется проверенный домен.

Шаг 8. Настройка параметров проверки подлинности для поставщика удостоверений Azure AD B2C в Akamai Enterprise Application Access

Обновите Идентификатор поставщика удостоверений Azure AD B2C в Akamai Enterprise Application Access Azure AD B2C с информацией о проверке подлинности, например URL-адресами проверяющей стороны.

  1. Вход в Enterprise Center https://control.akamai.com/

  2. В меню навигации Enterprise Center выберите поставщики удостоверений пользователей > удостоверений & доступа к > приложениям.

  3. Выберите имя поставщика удостоверений, созданное на шаге 1.

  4. Отправьте файл метаданных SAML Azure AD B2C, скачанный на шаге 5.

  5. Чтобы отправить файл metadata.xml, выберите " Выбрать файл".

    Screenshot shows the metadata file.

  6. Выберите " Сохранить" и "Развернуть".

Шаг 9. Развертывание Подключение приложений Akamai Enterprise в частном центре обработки данных

Чтобы включить доступ к частному приложению, разверните один или несколько соединителей Akamai Enterprise Application Access в частном центре обработки данных, где находится ваше приложение. Убедитесь, что соединители могут получить доступ к частному приложению и получить исходящий доступ к Akamai Cloud.

Шаг 10. Определение приложения Access в Akamai Enterprise Application Access для частного приложения

  1. Определение и развертывание приложения Access в Akamai Enterprise Application Access.

  2. При определении приложения Access

Вариант 1. Заголовки HTTP

В этом примере мы будем использовать приложение, отображающее заголовки docker header-demo-app. После развертывания приложения в частной среде и соединитель может получить доступ к приложению, создайте пользовательское приложение типа HTTP после документации Akamai Configure custom HTTP headers for a access application.

  1. В проверке подлинности выберите Azure AD B2C SAML IdP, созданный на предыдущих шагах.

Screenshot shows the akamai authn application.

  1. В разделе "Дополнительно" приложения сопоставьте заголовок HTTP с атрибутами SAML, выданными Azure AD B2C в ответе SAML при успешной проверке подлинности.

Пример:

Имя заголовка Атрибут
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.

Протестируйте приложение, выбрав URL-адрес Akamai для созданного веб-приложения пользовательского типа HTTP.

Screenshot shows the akamai header app results.

Вариант 2. OpenID Подключение

В этом примере мы будем использовать веб-приложение ASP.NET MVC, которое выполняет вход пользователей с помощью по промежуточного слоя Open Web Interface for .NET (OWIN) и платформа удостоверений Майкрософт.

  1. Настройте OIDC на подключение SAML в Azure AD B2C SAML IdP , созданного с помощью предыдущих шагов.

    Screenshot shows the akamai oidc app oidc settings.

  2. Создайте пользовательское приложение типа HTTP после настройки OpenID Подключение для приложения Access.

  3. В проверке подлинности выберите azure AD B2C SAML IdP, созданный на предыдущих шагах в зависимости от приложения заголовка HTTP.

    Screenshot shows the akamai authn app settings.

  4. В разделе "Дополнительно" выберите OpenID Подключение 1.0 в качестве механизма проверки подлинности и нажмите кнопку "Сохранить".

    Screenshot shows the akamai oidc app authentication settings.

  5. Откроется новая вкладка OpenID , скопируйте URL-адрес обнаружения, необходимый позже при настройке компонента OWIN для тестирования приложения.

    Screenshot shows the akamai oidc app settings.

  6. В разделе "Утверждения" определите утверждения, которые Akamai будет выдавать для приложения OIDC, сопоставляя их значения с атрибутами SAML, предоставляемыми Azure AD B2C в ответе SAML при успешной проверке подлинности. Эти утверждения должны сопоставить то, что вы определили на предыдущем шаге при настройке OIDC на переход SAML в Azure AD B2C SAML IdP.

    Screenshot shows the akamai oidc app claim settings.

  7. Замените класс запуска следующим кодом в веб-приложении MVC ASP.NET.

    Эти немногие изменения настраивают предоставление потока кода авторизации, код авторизации будет активирован для маркеров в конечной точке маркера для приложения, и он представляет адрес метаданных, чтобы задать конечную точку обнаружения для получения метаданных из 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 В файле добавьте адрес метаданных, замените clientId, clientecret, authority, redirectUri и PostLogoutRedirectUri значениями из приложения Akamai вappSettings.

    Эти значения можно найти на предыдущем шаге 5 на вкладке OpenID для приложения HTTP Akamai, где вы создали Discovery URL=MetadataAddress. redirectUri — это локальный адрес соединителя Akamai для разрешения локального приложения OIDC. Authority — это authorization_endpoint, который можно найти в .well-known/openid-configurationдокументе.

    URL-адрес обнаружения: 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>

    Протестируйте приложение, выбрав URL-адрес Akamai для созданного пользовательского веб-приложения типа HTTP.

    Screenshot shows the akamai oidc app results.

Тестирование решения

  1. Перейдите по URL-адресу приложения, используя внешний URL-адрес, указанный в Akamai Enterprise Application Access.

  2. Пользователь, не прошедший проверку подлинности, перенаправляется на страницу входа Azure AD B2C.

  3. Выберите IdP из списка на странице.

  4. Войдите в качестве конечного пользователя, используя учетные данные, связанные с Azure AD B2C.

  5. После успешной проверки подлинности конечный пользователь будет перенаправлен обратно в приложение и войдет в приложение в качестве конечного пользователя.

Дополнительные ресурсы