Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Это важно
Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".
В этом примере руководства описано, как интегрировать проверку подлинности 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 Connect (OIDC). В этом примере мы будем использовать веб-приложение ASP.NET MVC, которое выполняет вход пользователей через промежуточное программное обеспечение Open Web Interface for .NET (OWIN) и платформу идентификации Microsoft.
Описание сценария
В этом сценарии вы включите проверку подлинности Azure AD B2C для конечных пользователей, пытаясь получить доступ к частным приложениям, защищенным Akamai Enterprise Application Access.
Компоненты, участвующие в этой интеграции, :
Azure AD B2C: поставщик удостоверений SAML, отвечающий за проверку подлинности конечных пользователей.
Akamai Enterprise Application Access: облачная служба ZTNA, которая отвечает за защиту доступа к частным приложениям с непрерывным применением политик ZTNA.
Соединитель доступа к приложениям Akamai Enterprise: виртуальное устройство, развернутое в частном центре обработки данных. Он обеспечивает безопасное подключение к частным приложениям без открытия портов брандмауэра для входящего центра обработки данных.
Приложение: служба или приложение, развернутые в частном центре обработки данных, к которым пользователям требуется доступ.
Пользователь аутентифицируется в Azure AD B2C (как SAML IdP), который будет отвечать на запрос Akamai Enterprise Application Access (поставщик услуг) с утверждением 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.
Конечный пользователь пытается получить доступ к приложению, размещенном в частном центре обработки данных, с помощью внешнего URL-адреса приложения, зарегистрированного в Akamai Enterprise Application Access.
Akamai Enterprise Application Access перенаправляет пользователя без проверки подлинности в Azure AD B2C.
После успешной проверки подлинности Azure AD B2C перенаправляет пользователя обратно в Akamai Enterprise Application Access с утверждением SAML.
Akamai Enterprise Application Access использует сведения об удостоверении SAML, чтобы определить пользователя и определить, разрешено ли пользователю получить доступ к запрошенном приложению.
Akamai Enterprise Application Access создает утверждения OIDC или внедряет заголовки HTTP, которые отправляются в приложение.
Приложение использует эти сведения для идентификации пользователя, прошедшего проверку подлинности, и создает сеанс приложения для конечного пользователя.
Начало работы с 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.
Вход в Enterprise Center https://control.akamai.com/
В меню навигации Enterprise Center выберите "Удостоверение доступа к > приложениям" и "Поставщики удостоверений пользователей>".
Выберите добавить поставщика удостоверений (+).
Введите имя, описание и выберите тип поставщика как SAML стороннего поставщика.
Нажмите Продолжить. Появляется страница настройки провайдера идентификации.
В разделе "Общие параметры>" введите URL-адрес сервера удостоверений. Вы можете выбрать "Использовать домен Akamai" или "Использовать домен". Если вы используете собственный домен, используйте самозаверяющий сертификат или используйте отправленный пользовательский сертификат.
В разделе «Проверка подлинности» введите тот же URL-адрес, что и на предыдущем шаге в разделе «Общие», и выберите «Сохранить».
Шаг 2. Регистрация приложения SAML в Azure AD B2C
Получите начальные пакеты настраиваемой политики из 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.
Создайте сертификат подписи для Azure AD B2C, чтобы подписать ответ SAML, отправленный в Akamai Enterprise Application Access:
a. Получите сертификат. Если у вас еще нет сертификата, можно использовать самозаверяющий сертификат.
б. Отправьте сертификат в клиенте Azure AD B2C. Запишите имя, так как оно понадобится в
TechnicalProfile, упомянутом в следующих шагах.Включите политику для подключения к приложению 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>б. Замените
issuerUriURL-адрес Akamai, определенный в разделе "Общие параметры > доступа к приложениям Akamai Enterprise" на шаге 1.Пример
<Item Key="IssuerUri">https://fabrikam.login.go.akamai-access.com/saml/sp/response</Item>Замените B2C_1A_AkamaiSAMLSigningCert именем переданного ключа политики.
Шаг 3. Создание политики регистрации или входа, настроенной для SAML
Создайте копию
SignUpOrSignin.xmlфайла в рабочем каталоге начального пакета и сохраните его с новым именем. В этой статьеSignUpOrSigninSAML.xmlиспользуется в качестве примера. Этот файл представляет собой файл политики для проверяющей стороны. Он настроен на выдачу ответа JWT по умолчанию.SignUpOrSigninSAML.xmlОткройте файл в предпочтительном редакторе.Обновите
tenant-name, указав имя вашего клиента Azure AD B2C, измените значенияPolicyIdиPublicPolicyUriполитики на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">В конце пути взаимодействия пользователя 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.
Войдите на портал Azure.
Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.
На портале Azure найдите и выберите Azure AD B2C.
В разделе "Политики" выберите 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>именем (идентификатором) политики. Приведем пример: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. Регистрация содержит сведения о конфигурации, такие как конечная точка метаданных приложения.
Войдите на портал Azure.
Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.
В меню слева выберите Azure AD B2C. Или выберите все службы , а затем найдите и выберите Azure AD B2C.
Выберите регистрации приложений и нажмите кнопку "Создать регистрацию".
Введите имя приложения. Например, введите Akamai B2C Enterprise Application Access.
В разделе "Поддерживаемые типы учетных записей" выберите только учетные записи в этом каталоге организации (только B2C — один клиент).
В разделе URI перенаправления выберите веб-сайт и введите URL-адрес Akamai, определенный в параметре доступа к корпоративным приложениям Akamai Enterprise\General на шаге 1. Например:
https://fabrikam.login.go.akamai-access.com/saml/sp/response.Выберите Зарегистрировать.
Шаг 7. Настройка приложения Akamai Enterprise Application Access в Azure AD B2C
Для SAML необходимо настроить несколько свойств в манифесте регистрации приложения.
На портале Azure перейдите к регистрации приложения, созданной на шаге 3.
В разделе "Управление" выберите "Манифест" , чтобы открыть редактор манифеста. Затем измените свойства, описанные в следующем разделе.
Добавление идентификатора
Когда приложение AKamai Enterprise Application Access SAML отправляет запрос к Azure AD B2C, запрос проверки подлинности SAML включает Issuer атрибут. Значение этого атрибута обычно совпадает со значением метаданных entityID приложения. Azure AD B2C использует это значение для поиска регистрации приложения в каталоге и чтения конфигурации. Для успешного поиска в манифесте регистрации приложения поле identifierUri должно быть заполнено значением, соответствующим атрибуту Issuer.
В манифесте регистрации найдите identifierURIs параметр и добавьте значение IssuerURI , определенное на шаге 2, Azure AD B2C ClaimsProvider.
Пример:
"identifierUris": [
"https://fabrikam.login.go.akamai-access.com/saml/sp/response"
],
Это значение будет таким же, как значение, настроенное в запросах SAML AuthN в приложении для EntityId, и значение entityID в метаданных приложения. Вам также потребуется найти accessTokenAcceptedVersion параметр и задать для параметра значение 2.
Это важно
Если вы не обновите accessTokenAcceptedVersion до 2, вы получите сообщение об ошибке, требующее подтверждения домена.
Шаг 8. Настройка параметров проверки подлинности для поставщика удостоверений Azure AD B2C в Akamai Enterprise Application Access
** Обновите удостоверение поставщика идентификации (IdP) Azure AD B2C для Akamai Enterprise Application Access, добавив информацию аутентификации, например, URL-адреса доверенных сторон.
Вход в Enterprise Center https://control.akamai.com/
В меню навигации Enterprise Center выберите "Удостоверение доступа к > приложениям" и "Поставщики удостоверений пользователей>".
Выберите имя поставщика удостоверений, созданное на шаге 1.
Отправьте файл метаданных SAML Azure AD B2C, скачанный на шаге 5.
Чтобы отправить файл metadata.xml, выберите "Выбрать файл".
Выберите "Сохранить" и "Развернуть".
Шаг 9. Развертывание соединителей доступа к корпоративным приложениям Akamai в частном центре обработки данных
Чтобы включить доступ к частному приложению, разверните один или несколько соединителей Akamai Enterprise Application Access в частном центре обработки данных, где находится ваше приложение. Убедитесь, что соединители могут дотягиваться до вашего частного приложения и имеют возможность исходящего соединения с Akamai Cloud.
Шаг 10. Определение приложения Access в Akamai Enterprise Application Access для частного приложения
Определение и развертывание приложения Access в Akamai Enterprise Application Access.
При определении приложения Access
Свяжите это с определением Enterprise Application Access IdP Azure AD B2C, которое вы создали с помощью предыдущих шагов.
Настройте аутентификацию для приложений, чтобы включить функцию единого входа в частное приложение.
Вариант 1. Заголовки HTTP
В этом примере мы будем использовать приложение, отображающее заголовки docker header-demo-app. После развертывания приложения в частной среде и когда соединитель может получить к нему доступ, создайте пользовательское приложение типа HTTP, следуя документации Akamai Настройка пользовательских заголовков HTTP для приложения с доступом.
- В проверке подлинности выберите Azure AD B2C SAML IdP, созданный на предыдущих шагах.
- В разделе "Дополнительно " приложения сопоставьте заголовок HTTP с атрибутами SAML, выданными Azure AD B2C в ответе SAML при успешной проверке подлинности.
Пример:
| Имя заголовка | Свойство |
|---|---|
| ps-sso-первый | 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-АдресЭлектроннойПочты | адрес электронной почты |
| ps-sso-uid | objectId |
Протестируйте приложение, выбрав URL-адрес Akamai для созданного веб-приложения пользовательского типа HTTP.
Вариант 2. OpenID Connect
В этом примере мы будем использовать веб-приложение ASP.NET MVC, которое выполняет вход пользователей с помощью промежуточного слоя Open Web Interface for .NET (OWIN) и платформы управления идентификацией Microsoft.
Настройте мост OIDC-SAML в Azure AD B2C SAML IdP, созданном с помощью предыдущих шагов.
Создайте пользовательское приложение типа HTTP после настройки OpenID Connect для приложения Access.
В разделе "Аутентификация" выберите Azure AD B2C SAML IdP, созданный на предыдущих шагах, в соответствии с приложением заголовка HTTP.
В разделе "Дополнительно" выберите OpenID Connect 1.0 в качестве механизма проверки подлинности и нажмите кнопку "Сохранить".
Откроется новая вкладка OpenID , скопируйте URL-адрес обнаружения, необходимый позже при настройке компонента OWIN для тестирования приложения.
В разделе "Утверждения" определите утверждения, которые Akamai будет выдавать для приложения OIDC, сопоставляя их значения с атрибутами SAML, предоставляемыми Azure AD B2C в ответе SAML при успешной проверке подлинности. Эти утверждения должны соответствовать тому, что вы определили на предыдущем шаге при настройке моста между OIDC и SAML в Azure AD B2C SAML IdP.
Замените класс запуска следующим кодом в веб-приложении 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); } }web.configВ файле добавьте адрес метаданных, замените clientId, clientsecret, 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.
Тестирование решения
Перейдите по URL-адресу приложения, используя внешний URL-адрес, указанный в Akamai Enterprise Application Access.
Пользователь, не прошедший проверку подлинности, перенаправляется на страницу входа Azure AD B2C.
Выберите IdP (поставщика удостоверений) из списка на странице.
Войдите в качестве конечного пользователя, используя учетные данные, связанные с Azure AD B2C.
После успешной проверки подлинности конечный пользователь будет перенаправлен обратно в приложение и войдет в приложение в качестве конечного пользователя.