Azure Active Directory B2C と Akamai Enterprise Application Access を構成して、SSO とセキュリティで保護されたハイブリッド アクセスを実現する
このサンプル チュートリアルでは、Azure Active Directory B2C (Azure AD B2C) 認証と Akamai Enterprise Application Access を統合する方法について説明します。 Akamai Enterprise Application Access は、プライベート データセンターに存在する最新およびレガシ アプリケーションへの安全なリモート アクセスを可能にする、ゼロ トラスト ネットワーク アクセス (ZTNA) ソリューションです。 Akamai Enterprise Application Access は、ID プロバイダー (IdP) Azure AD B2C とフェデレーションしてユーザーを認証し、その認可ポリシーを使用して、プライベート アプリケーションへのアクセスを許可する前に、ID、デバイス、アプリケーション、要求コンテキストの継続的な評価を実行します。
この機能は、カスタム ポリシーでのみ使用できます。 セットアップ手順は、前のセレクターで [カスタム ポリシー] を選択します。
前提条件
作業を開始するには、以下が必要です。
Akamai Enterprise Access の契約。 所有していない場合は、無料試用版を入手してください。
Azure サブスクリプション。 サブスクリプションがない場合は、無料アカウントを取得できます。
お使いの Azure サブスクリプションにリンクされている Azure AD B2C テナント。
Akamai Enterprise Application Access コネクタをデプロイするための仮想アプライアンスが、データセンターまたはハイブリッド クラウド環境のファイアウォールの背後にデプロイされている。
認証にヘッダーを使用するアプリケーション。 このサンプルでは、ヘッダー docker header-demo-app を表示するアプリケーションを使用します。
または、OpenID Connect (OIDC) アプリケーション。 このサンプルでは、Open Web Interface for .NET (OWIN) ミドルウェアと Microsoft ID プラットフォームを使用してユーザーのサインインを処理する ASP.NET MVC Web アプリを使用します。
シナリオの説明
このシナリオでは、Akamai Enterprise Application Access によってセキュリティ保護されたプライベート アプリケーションにアクセスしようとするときに、エンド ユーザーに対して Azure AD B2C 認証を有効にします。
この統合に関連するコンポーネントは次のとおりです。
Azure AD B2C: エンド ユーザーの認証を担う SAML ID プロバイダー。
Akamai Enterprise Application Access: ZTNA ポリシーを継続的に適用してプライベート アプリケーションへのアクセスをセキュリティで保護する役割を持つ ZTNA クラウド サービス。
Akamai Enterprise Application Access Connector: プライベート データセンターにデプロイされた仮想アプライアンス。 データセンターの受信ファイアウォール ポートを開くことなく、プライベート アプリへの接続がセキュリティで保護されます。
アプリケーション: エンド ユーザーがアクセスする必要がある、プライベート データセンターにデプロイされたサービスまたはアプリケーション。
ユーザーは、SAML アサーションを使用して Akamai Enterprise Application Access (サービス プロバイダー) に応答する Azure AD B2C (SAML IdP) に対して認証を行います。 Akamai Enterprise Application Access では、SAML アサーションからの情報をマップして、OpenID クレームを作成するか、ユーザーに関する情報を含む HTTP ヘッダーを挿入します。 Akamai Enterprise Application Access によって、Akamai Enterprise Application Access コネクタを介してアクセスできるアプリケーションにこれが渡されます。 このサンプルでは、アプリケーションにこれらのヘッダーの内容が表示されます。 OIDC アプリケーションのユース ケースでは、ユーザーのクレームが表示されます。
次の図は、Akamai Enterprise Application Access (EAA) と Azure AD B2C を統合する方法を示しています。
エンド ユーザーは、Akamai Enterprise Application Access に登録されているアプリケーションの外部 URL を使用して、プライベート データセンターでホストされているアプリケーションにアクセスしようとします。
Akamai Enterprise Application Access では、認証されていないエンド ユーザーを認証のために Azure AD B2C にリダイレクトします。
認証が成功すると、Azure AD B2C によってユーザーは SAML アサーションと共に Akamai Enterprise Application Access にリダイレクトされます。
Akamai Enterprise Application Access では、SAML アサーションの ID 情報を使用してユーザーを識別し、ユーザーが要求されたアプリケーションへのアクセスを許可されているかどうかを判断します。
Akamai Enterprise Application Access では、OIDC クレームを作成するか、アプリケーションに送信される HTTP ヘッダーを挿入します。
アプリケーションでは、この情報を使用して、認証されたユーザーを識別し、エンド ユーザーのアプリケーション セッションを作成します。
Akamai Enterprise Application Access にオンボードする
Akamai Enterprise Application Access の使用を開始するには、Akamai Enterprise Application Access の概要ガイドを参照してください。
手順 1 - Akamai Enterprise Application Access で Azure AD B2C を SAML IdP として追加する
Akamai Enterprise Application Access では、Azure AD B2C などのクラウド IdP との SAML フェデレーションがサポートされています。 Akamai Enterprise Application Access で Azure AD B2C をサード パーティ SAML IdP として追加します。
Enterprise Center https://control.akamai.com/ にサインインします。
[エンタープライズ センター] ナビゲーション メニューで、[アプリケーション アクセス] > [ID とユーザー] > [ID プロバイダー] を選択します。
[ID プロバイダーの追加 (+)] を選択します。
名前、説明を入力し、プロバイダーの種類として [サード パーティ SAML] を選択します。
[続行] をクリックします。 [ID プロバイダー] の構成ページが表示されます。
[設定] > [全般] に、ID サーバーの URL を入力します。 [Akamai ドメインを使用する] または [独自のドメインを使用する] を選択できます。 独自のドメインを使用する場合は、自己署名証明書を使用するか、アップロードされたカスタム証明書を使用します。
[認証] で、前の手順で [全般] に定義したものと同じ URL を入力して、[保存] を選択します。
手順 2 - SAML アプリケーションを Azure AD B2C に登録する
GitHub からカスタム ポリシー スターター パックを取得し、LocalAccounts スターター パック内の XML ファイルを実際の Azure AD B2C テナントの名前で更新します。
.zip ファイルをダウンロードするか、リポジトリを複製します。
git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpackLocalAccounts ディレクトリ内のすべてのファイルで、
yourtenant文字列を Azure AD B2C テナントの名前に置き換えます。 たとえば、B2C テナントの名前がfabrikamであれば、yourtenant.onmicrosoft.comのすべてのインスタンスはfabrikam.onmicrosoft.comになります。
Azure AD B2C の署名証明書を作成して、Akamai Enterprise Application Access に送信される SAML 応答に署名します。
a. 証明書を取得します。 証明書をまだ持っていない場合は、自己署名証明書を使用できます。
b. 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>b.
issuerUriを、手順 1 の Akamai Enterprise Application Access の [設定] > [全般] で定義した Akamai URL に置き換えます。たとえば、
<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ステップが含まれます。 このステップでは、トークン発行者の技術プロファイルが参照されます。 既定の JWT 応答ではなく SAML 応答を発行するには、新しい SAML トークン発行者の技術プロファイルSaml2AssertionIssuerを参照するように、SendClaimsステップを変更します。<RelyingParty>要素の直前に次の XML スニペットを追加します。 この XML によって、LocalAccountカスタム ポリシー スターター パックを使用していることを想定して、SignUpOrSignInユーザー体験のオーケストレーション手順 4 が上書きされます。スターター パックの別のフォルダーから開始した場合、またはオーケストレーション ステップを追加または削除してユーザー体験をカスタマイズした場合は、
order要素の番号がトークン発行者ステップのユーザー体験で指定された番号に対応していることを確認してください。 たとえば、他のスターター パック フォルダーでは、対応するステップ番号は、SocialAndLocalAccountsの場合は 7、SocialAccountsの場合は 6、SocialAndLocalAccountsWithMfaの場合は 9 です。<UserJourneys> <UserJourney Id="SignUpOrSignIn"> <OrchestrationSteps> <OrchestrationStep Order="4" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="AkamaiSaml2AssertionIssuer"/> </OrchestrationSteps> </UserJourney> </UserJourneys>証明書利用者要素によって、アプリケーションで使用されるプロトコルが決まります。 既定では、
OpenIdです。Protocol要素をSAMLに変更する必要があります。 出力要求により、SAML アサーションに対する要求のマッピングが作成されます。<RelyingParty>要素の<TechnicalProfile>要素全体を次のテクニカル プロファイル 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 portal にアップロードします。
Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選び、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal で、 [Azure AD B2C] を検索して選択します。
[ポリシー] で [Identity Experience Framework] を選択します。 [カスタム ポリシーのアップロード] を選択し、変更した 2 つのポリシー ファイルを次の順序でアップロードします。
- 基本ファイル (
TrustFrameworkBase.xmlなど) - 拡張機能ポリシー (
TrustFrameworkExtensions.xmlなど) - 証明書利用者ポリシー (
SignUpOrSigninSAML.xmlなど)
- 基本ファイル (
手順 5 - Azure AD B2C IdP SAML メタデータをダウンロードする
ポリシー ファイルがアップロードされた後、Azure AD B2C では構成情報を使用して、アプリケーションで使用される ID プロバイダーの 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 のアプリケーション登録を作成します。 その登録には、アプリケーションのメタデータ エンドポイントなどの構成情報が含まれます。
Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選び、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
左側のメニューで、 [Azure AD B2C] を選択します。 または、[すべてのサービス] を選択し、[Azure AD B2C] を検索して選択します。
[アプリの登録] を選択し、 [新規登録] を選択します。
アプリケーションの名前を入力します。 たとえば、「Akamai B2C Enterprise Application Access」と入力します。
[サポートされているアカウントの種類] で、[この組織ディレクトリのみに含まれるアカウント (B2C のみ - シングル テナント)] を選択します。
[リダイレクト URI] で、[Web] を選択し、手順 1 の Akamai Enterprise Application Access の [設定] > [全般] で定義した Akamai URL を入力します。 たとえば、「
https://fabrikam.login.go.akamai-access.com/saml/sp/response」のように入力します。[登録] を選択します。
手順 7 - Akamai Enterprise Application Access アプリケーションを Azure AD B2C に構成する
SAML の場合、アプリケーションの登録のマニフェストでいくつかのプロパティを構成する必要があります。
Azure portal で、手順 3 で作成したアプリケーションの登録に移動します。
[管理] で、 [マニフェスト] を選択してマニフェスト エディターを開きます。 その後、以降のセクションで説明されているプロパティを変更します。
識別子を追加する
Akamai Enterprise Application Access SAML アプリケーションで Azure AD B2C に対して要求が行われると、SAML 認証要求に Issuer 属性が含められます。 この属性の値は、通常、アプリケーションのメタデータ entityID 値と同じです。 Azure AD B2C では、この値を使用して、ディレクトリ内でアプリケーションの登録を検索し、構成を読み取ります。 この検索を成功させるには、アプリケーションの登録マニフェスト内の identifierUri に、Issuer 属性と一致する値を設定する必要があります。
登録マニフェストで、identifierURIs パラメーターを見つけて、手順 2 で定義した IssuerURI 値 (Azure AD B2C ClaimsProvider) を追加します。
例:
"identifierUris": [
"https://fabrikam.login.go.akamai-access.com/saml/sp/response"
],
この値は、アプリケーションで EntityId の SAML AuthN 要求内に構成されたのと同じ値であり、アプリケーションのメタデータ内の entityID 値となります。 また、accessTokenAcceptedVersion パラメーターを見つけて、値を 2 に設定する必要があります。
重要
accessTokenAcceptedVersion を 2 に更新しない場合は、検証済みドメインを求めるエラー メッセージが表示されます。
手順 8 - Akamai Enterprise Application Access で Azure AD B2C IdP の認証設定を構成する
証明書利用者 URL などの認証情報を使用して、Akamai Enterprise Application Access の Azure AD B2C IdP を更新します。
Enterprise Center https://control.akamai.com/ にサインインします。
[エンタープライズ センター] ナビゲーション メニューで、[アプリケーション アクセス] > [ID とユーザー] > [ID プロバイダー] を選択します。
手順 1 で作成した ID プロバイダー名を選択します。
手順 5 でダウンロードした Azure AD B2C SAML メタデータ ファイルをアップロードします。
metadata.xml ファイルをアップロードするには、[ファイルの選択] を選択します。
[保存してデプロイ] を選択します。
手順 9 - Akamai Enterprise Application Access Connector をプライベート データセンターにデプロイする
プライベート アプリケーションへのアクセスを有効にするために、アプリケーションが存在するプライベート データセンターに 1 つ以上の Akamai Enterprise Application Access コネクタ をデプロイします。 コネクタでプライベート アプリケーションに到達でき、Akamai Cloud に送信アクセスできることを確認します。
手順 10 - Akamai Enterprise Application Access でプライベート アプリケーションのアクセス アプリケーションを定義する
Akamai Enterprise Application Access で、アクセス アプリケーションを定義してデプロイします。
アクセス アプリケーションを定義するとき
前の手順で作成した Enterprise Application Access Azure AD B2C IdP 定義に関連付けます。
プライベート アプリケーションへの SSO を有効にするには、アプリケーションに対する認証を構成します。
- オプション 1: アクセス アプリケーションのカスタム HTTP ヘッダーを構成する
- オプション 2: アクセス アプリケーションの OpenID Connect を構成する
オプション 1: HTTP ヘッダー
このサンプルでは、ヘッダー docker header-demo-app を表示するアプリケーションを使用します。 アプリケーションがプライベート環境にデプロイされ、コネクタでアプリケーションにアクセスできるようになったら、Akamai のドキュメント「アクセス アプリケーションのカスタム HTTP ヘッダーを構成する」に従って、カスタム HTTP タイプ アプリケーションを作成します。
- [認証] で、前の手順で作成した Azure AD B2C SAML IdP を選択します。
- アプリケーションの [詳細設定] セクションで、認証の成功時に Azure AD B2C によって SAML 応答に発行された SAML 属性に HTTP ヘッダーをマップします。
例:
| ヘッダー名 | 属性 |
|---|---|
| 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 |
作成したカスタム HTTP タイプ Web アプリケーションの Akamai URL を選択して、アプリケーションをテストします。
オプション 2: OpenID Connect
このサンプルでは、Open Web Interface for .NET (OWIN) ミドルウェアと Microsoft ID プラットフォームを使用してユーザーのサインインを処理する ASP.NET MVC Web アプリを使用します。
前の手順で作成した Azure AD B2C SAML IdP に、OIDC から SAML へのブリッジを構成します。
「アクセス アプリケーションの OpenID Connect の構成」に従って、カスタム HTTP タイプ アプリケーションを作成します。
[認証] で、前の手順で HTTP ヘッダー アプリケーションに従って作成した [Azure AD B2C SAML IdP] を選択します。
[詳細設定] で、認証メカニズムとして [OpenID Connect 1.0] を選択し、[保存] を選択します。
新しい [OpenID] タブが表示されたら、後でアプリケーションをテストするために OWIN コンポーネントを構成するときに必要となる [探索 URL] をコピーします。
[クレーム] セクションで、Akamai で OIDC アプリケーションに対して発行するクレームを定義し、認証の成功時に Azure AD B2C によって SAML 応答で提供される SAML 属性にその値をマッピングします。 これらのクレームでは、前の手順で AZURE AD B2C SAML IdP で OIDC から SAML へのブリッジを構成するときに定義した内容をマップする必要があります。
ASP.NET MVC Web アプリのスタートアップ クラスを次のコードに置き換えます。
これらのいくつかの変更により、認可コード フローの許可が構成され、認可コードがアプリケーションのトークン エンドポイントでトークンに引き換えられます。また、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 をappSettingsの Akamai アプリケーションの値に置き換えます。これらの値は、前の手順 5 の
Discovery URL=MetadataAddressを作成した HTTP Akamai アプリケーションの [OpenID] タブにあります。redirectUriは、ローカル OIDC アプリケーションに解決される Akamai コネクタのローカル アドレスです。Authorityは、.well-known/openid-configurationの ドキュメントから見つけることができる authorization_endpoint です。探索 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>作成したカスタム HTTP タイプ Web アプリケーションの Akamai URL を選択して、アプリケーションをテストします。
ソリューションをテストする
Akamai Enterprise Application Access で指定された外部 URL を使用して、アプリケーション URL に移動します。
認証されていないユーザーは、Azure AD B2C サインイン ページにリダイレクトされます。
ページの一覧から IdP を選択します。
Azure AD B2C にリンクされた資格情報を使用して、エンド ユーザーとしてサインインします。
認証が成功すると、エンド ユーザーはアプリケーションにリダイレクトされ、エンド ユーザーとしてアプリケーションにサインインします。