Azure Active Directory B2C と Akamai Enterprise Application Access を構成して、SSO とセキュリティで保護されたハイブリッドアクセスを実現する

[アーティクル]
06/01/2023

このサンプルチュートリアルでは、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 を統合する方法を示しています。

Screenshot shows the integration architecture.

エンドユーザーは、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-starterpack
```
- LocalAccounts ディレクトリ内のすべてのファイルで、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 を、アップロードしたポリシーキーの名前に置き換えます。

スターターパックの作業ディレクトリに 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

Screenshot shows the akamai header app mapping.

作成したカスタム HTTP タイプ Web アプリケーションの Akamai URL を選択して、アプリケーションをテストします。

Screenshot shows the akamai header app results.

オプション 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 にリンクされた資格情報を使用して、エンドユーザーとしてサインインします。
認証が成功すると、エンドユーザーはアプリケーションにリダイレクトされ、エンドユーザーとしてアプリケーションにサインインします。

次の方法で共有

Azure Active Directory B2C と Akamai Enterprise Application Access を構成して、SSO とセキュリティで保護されたハイブリッドアクセスを実現する

前提条件

シナリオの説明

Akamai Enterprise Application Access にオンボードする

手順 1 - Akamai Enterprise Application Access で Azure AD B2C を SAML IdP として追加する

手順 2 - SAML アプリケーションを Azure AD B2C に登録する

手順 4 - ポリシーをアップロードする

手順 5 - Azure AD B2C IdP SAML メタデータをダウンロードする

手順 6 - Akamai Enterprise Application Access アプリケーションを Azure AD B2C に登録する

手順 7 - Akamai Enterprise Application Access アプリケーションを Azure AD B2C に構成する

識別子を追加する

手順 8 - Akamai Enterprise Application Access で Azure AD B2C IdP の認証設定を構成する

手順 9 - Akamai Enterprise Application Access Connector をプライベートデータセンターにデプロイする

手順 10 - Akamai Enterprise Application Access でプライベートアプリケーションのアクセスアプリケーションを定義する

オプション 1: HTTP ヘッダー

オプション 2: OpenID Connect

ソリューションをテストする

その他のリソース

フィードバック

その他のリソース

次の方法で共有

Azure Active Directory B2C と Akamai Enterprise Application Access を構成して、SSO とセキュリティで保護されたハイブリッド アクセスを実現する

前提条件

シナリオの説明

Akamai Enterprise Application Access にオンボードする

手順 1 - Akamai Enterprise Application Access で Azure AD B2C を SAML IdP として追加する

手順 2 - SAML アプリケーションを Azure AD B2C に登録する

手順 3 - SAML 用に構成されたサインアップまたはサインイン ポリシーを作成する

手順 4 - ポリシーをアップロードする

手順 5 - Azure AD B2C IdP SAML メタデータをダウンロードする

手順 6 - Akamai Enterprise Application Access アプリケーションを Azure AD B2C に登録する

手順 7 - Akamai Enterprise Application Access アプリケーションを Azure AD B2C に構成する

識別子を追加する

手順 8 - Akamai Enterprise Application Access で Azure AD B2C IdP の認証設定を構成する

手順 9 - Akamai Enterprise Application Access Connector をプライベート データセンターにデプロイする

手順 10 - Akamai Enterprise Application Access でプライベート アプリケーションのアクセス アプリケーションを定義する

オプション 1: HTTP ヘッダー

オプション 2: OpenID Connect

ソリューションをテストする

その他のリソース

フィードバック

その他のリソース

Azure Active Directory B2C と Akamai Enterprise Application Access を構成して、SSO とセキュリティで保護されたハイブリッドアクセスを実現する

手順 3 - SAML 用に構成されたサインアップまたはサインインポリシーを作成する

手順 9 - Akamai Enterprise Application Access Connector をプライベートデータセンターにデプロイする

手順 10 - Akamai Enterprise Application Access でプライベートアプリケーションのアクセスアプリケーションを定義する