Amazon Web Services ブログ

Amazon AppStream 2.0 の ID フェデレーションを AD FS 3.0 で実現する

既存のエンタープライズ認証情報を使用して AppStream 2.0 へのシングルサインオンアクセスを提供したいですか？ Active Directory Federation Services (AD FS) 3.0 は SAML 2.0 を使用した Amazon AppStream 2.0 へのシングルサインオンを提供するために使用することができます。

既存の Active Directory や任意の SAML 2.0 準拠の認証サービスを使用してユーザーに AppStream 2.0 アプリケーションへのシングルサインオンアクセスをセットアップすることができます。SAML 2.0 を使用した ID フェデレーションは現在すべての AppStream 2.0 リージョンで利用可能です。

この記事では Windows Server 2012 R2 で使用できる AD FS 3.0 を使用して AppStream 2.0 への ID フェデレーションを構成する方法について説明します。記事の最後に追加で、Windows Server 2016 で使用できる AD FS 4.0 を使用する場合についても補足します。

ウォークスルー

AppStream 2.0 への SAML 2.0 フェデレーションをセットアップすると、ユーザーは特別に作成された AD FS のリレーステート URL をブラウザで開くことで AppStream 2.0 アプリケーションに直接接続することができるようになります。

ユーザーがこの URL を開くと Active Directory で認証する事になります。認証後ブラウザは AD FS から認証レスポンスとして SAML アサーションを受け取り、ブラウザによって AWS サインインの SAML エンドポイントにポストされます。一時的なセキュリティ認証情報はアサーションと埋め込み属性が検証された後に発行されます。一時的な認証情報はサインイン URL を作成するために使用されます。ユーザーはAppStream 2.0ストリーミングセッションにリダイレクトされます。以下の図はこの流れを示したものです。

 

  1. ユーザーはhttps://aplications.exampleco.comをブラウザで開きます。サインオンページがユーザーに認証を要求します。
  2. フェデレーションサービスが組織内の認証ストアに認証を要求します。
  3. 認証ストアがユーザーを認証して認証結果をフェデレーションサービスに返します。
  4. 認証が成功であれば、フェデレーションサービスはユーザーのブラウザに SAML アサーションを返します。
  5. ユーザーのブラウザが AWS サインイン SAML エンドポイント(https://signin.thinkwithwp.com/saml) に SAML アサーションを送信します。AWS サインインは SAML リクエストを受け取り、処理、ユーザーを認証し、認証トークンを AppStram 2.0 サービスに転送します。
  6. AppStream 2.0は AWS からの認証トークンを使用してユーザーを認証してブラウザにアプリケーションを表示します。

この記事では、Active Directory ドメインの名前として domain.local を使用します。以下がウォークスルーのステップです。：

  1. AppStream 2.0 の ID フェデレーションを設定します。
  2. 信頼関係を設定します。
  3. 要求規則を作成します。
  4. リレーステートとフォーム認証を有効にします。
  5. AppStream 2.0 用リレーステート URL を作成してスタックにアクセスします。
  6. 設定をテストします。

前提条件

このウォークスルーは以下の前提条件を満たしていることを想定しています：

AppStream 2.0 ID フェデレーションを設定

まず AppStream 2.0 スタックを作成して、今後のステップでスタックを参照できるようにします。スタックに ExampleStack という名前を付けます。このウォークスルーでは、スタックにどのフリートを関連付けるかは関係ありません。利用可能な Amazon-AppStream2-Sample-Image イメージのひとつを使用してフリートを作成することも、既存のフリートをスタックに関連付けることもできます。

AD FS メタデータファイルの取得

はじめに必要なことは AD FS サーバーからメタデータファイルを取得することです。メタデータファイルは証明書利用者信頼 (relying party trust) を設定するためにこのガイドで後ほど使用する署名されたファイルです。このファイルを編集したり再フォーマットしないでください。

このファイルをダウンロードして保存するには、以下の URL の <FQDN_ADFS_SERVER> を自分の AD FS の FQDN で置き換えてブラウザ等で開きます。

https://<FQDN_ADFS_SERVER>/FederationMetadata/2007-06/FederationMetadata.xml

後ほど AWS Management Console にアップロードできるようにローカルの場所にファイルを保存します。

SAML プロバイダの作成

次に、コンソールを使用して IAM で SAML プロバイダを作成します。AWS CLI を使用して作成することもできます。

IAMコンソールで、IDプロバイダ、プロバイダの作成を選択します。

プロバイダの設定のページで、プロバイダーのタイプに SAML を選択します。プロバイダ名には、ADFS または同様の名前を入力します。ファイルの選択を選択して先ほどダウンロードしたメタデータドキュメントをアップロードします。次のステップを選択します。

プロバイダ情報を検証して、作成を選択します。

このウォークスルーで後ほど要求規則 (クレームルール) を構成するには、ID プロバイダ (IdP) の ARN (Amazon Resource Name) が必要です。そのため、作成した IdP を開き、概要のページで プロバイダのARNの値をコピーします。ARN は以下のようなフォーマットです。：

arn:aws:iam::<Account ID>:saml-provider/<Provider Name>

IAM ポリシーの設定

次に、AppStream 2.0 スタックへのアクセス許可のポリシーを設定します。これはフェデレーションしたユーザーに対して AWS 内での許可を与えます。

IAMコンソールで、ポリシー、ポリシーの作成を選択します。JSON タブに切り替えて、ポリシードキュメントを以下のスクリーンショットを参考に入力します。Region-Code、Account ID（ハイフンなし）、そして大文字小文字を区別して Stack-Name の値を書き換えて Review policy を選択します。

名前に適切な名前を入力します。説明には許可内容を記載します。

上記のスクリーンショットはユーザーに ExampleStack という名前の AppStream 2.0 スタックにだけ許可を与えるポリシーの例を示したものです。より詳細な情報は、ステップ 2: SAML 2.0 フェデレーション IAM ロールの作成を参照してください。

Region Codes には、AppStream 2.0 を使用するリージョン（AppStream 2.0が利用可能なリージョン）である以下の値のひとつを使用します。：

  • us-east-1
  • us-west-2
  • eu-west-1
  • ap-northeast-1
  • ap-southeast-1
  • ap-southeast-2

Create Policy を選択すると、以下の通知が表示されます。：

 

 

IAMロールの作成

ここでは、AppStream 2.0 を利用する Active Directory 上のユーザーがメンバーとなっている Active Directory グループに対して紐付けるロールを作成します。この設定では Active Directory グループと AWS ロールの大文字小文字が区別されます。ここでは “ExampleStack” という名前の IAM ロールと AWS-123456789012-ExampleStack のようにAWS-AcountNumber-RoleName のフォーマットの名前で Active Directory グループを作成します。

IAMコンソールで、ロール、ロールの作成を選択します。

信頼されたエンティティの種類を選択 で、SAML 2.0 フェデレーション を選択します。SAMLプロバイダ にさきほど作成した SAML プロバイダ（ADFSなど）を選択して、プログラムによるアクセスと AWS マネジメントコンソールによるアクセスを許可する を選択し、次のステップ: アクセス権限 を選択します。

※現在、日本語では上記の通り誤訳が表示される状態となっており「するには」は正しくは「SAML プロバイダ」です。

 

アクセス権限ポリシーをアタッチする ページで、先ほど作成した、フェデレーションしたユーザーに AppStream 2.0 の特定スタックにのみアクセスを許可するポリシーをアタッチします。このウォークスルーでは、ポリシーは AppStream2_ExampleStack という名前です。

正しいポリシーを選択した後、次のステップ: 確認 を選択します。

確認 ページで、ロールに ExampleStack という名前を付けます。要求規則を作成する箇所で説明しますが、この名前付けルールはカスタマイズ可能です。ロールの説明 は自由に記載して下さい。ロールの作成 を選択します。

作成されたロールの信頼関係は以下の通りとなります。

重要：フェデレーションしたユーザーにスタック以外にも許可を付与すると、AWS マネージメントコンソールのほかのエリアにもアクセスできるようになります。フェデレーションしたユーザーには共有したいリソースにのみアクセスを許可するポリシーをロールにアタッチすることを強く推奨します。

例えば、AppStream2_ExampleStack ポリシーの代わりに AdministratorAccess ポリシーをアタッチすると、Active Directory 上の ExampleStack グループ内の任意の AppStream 2.0 フェデレーションユーザーは AWS アカウントの AdministratorAccess 権限を持つことになります。AD FS がユーザーをスタックに誘導しても、ユーザーは特定のコンソールに直接移動するディープリンクを使用してコンソールの他のエリアに移動することが可能です。

次に、AWS-AccountNumber-RoleName 形式の名前で Active Directory グループを作成します。今作成した “ExampleStack” をロール名に指定します。この Active Directory グループ名は後ほど正規表現を使用して AD FS 要求規則で参照します。グループの範囲 には グローバル を、グループの種類 には セキュリティ を選択します。

メモ：このウォークスルーの通り実行するには、Active Directory グループの名前は正確に “AWS-AccountNumber-ExampleStack” の形式とし、AccountNumber を AWS アカウントID（ハイフンなし）に置き換えた名前にしてください。例えば以下のような名前です。：

AWS-123456789012-ExampleStack

証明書利用者信頼の設定

このセクションでは、AD FS 3.0 を設定して AWS で作成された構成と通信できるようにします。

AD FS 3.0 サーバー上で AD FS コンソールを開きます。

 

 

左側のペインにある AD FS を右クリックしてコンテクストメニューを開いて 証明書利用者信頼の追加 を選択します。

ようこそ ページで、開始 を選択します。データ ソースの選択 ページで、オンラインまたはローカル ネットワークで公開されている証明書利用者についてのデータをインポートする を選択されている状態にしておきます。フェデレーション メタデータのアドレス (ホスト名または URL) に AWS を証明書利用者として記述されている以下の SAML メタデータ URL を入力して、次へ を選択します。

https://signin.thinkwithwp.com/static/saml-metadata.xml

表示名の指定 ページで、表示名 に “AppStream 2.0 – ExampleStack” などの名前を入力します。注意事項 は必要に応じて入力して 次へ を選択します。

今すぐ多要素認証を構成しますか？ ページで、現時点ではこの証明書利用者信頼に多要素認証を構成しない が選択されたままにして、次へを選択します。

Active Directory グループと、ポリシーがアタッチされた IAM ロールを使用してスタックへのアクセスをコントロールしているため、発行承認規則の選択 ページで すべてのユーザーに対してこの証明書利用者へのアクセスを許可する を選択されたままにします。次へ を選択します。

信頼の追加の準備完了 ページで、変更すべき項目はありません。次へ を選択します。

完了 ページで、ウィザードの終了時にこの証明書利用者信頼の [要求規則の編集] ダイアログを開く のチェックを外します。これは後ほど開きます。閉じる を選択します。

次に、証明書利用者信頼のプロパティの中 識別子 タブ内のリストに https://signin.thinkwithwp.com/saml を追加します。そのためには、作成した証明書利用者信頼のコンテクスト（右クリック）メニューを開いて プロパティ を選択します。

監視 タブ内の 証明書利用者を監視する のチェックを外し、適用 を選択します。識別子 タブで、証明書利用者の識別子 のテキストボックスに、https://signin.thinkwithwp.com/saml を入力して 追加 を選択して追加し、OK を選択します。

 

 

要求規則を作成

このセクションでは AD FS 要求規則 (クレームルール) を作成します。要求規則ではアカウントを特定し、LDAP 属性をセットし、Active Directory グループを取得し、先ほど作成したロール名と一致させます。

AD FS コンソールで、信頼関係 を展開して 証明書利用者信頼 を選び、先程作成した証明書利用者信頼（この場合、表示される名前は AppStream 2.0 – ExampleStack）を選択します。証明書利用者のコンテクスト（右クリック）メニューを開いて 要求規則の編集 を選びます。規則の追加 を選択します。

規則 1: Name ID

この要求規則では、欲しい規則のタイプとどのように規則を AWS に送るのかを定義します。AD FS は UPN を受信し AWS にフォワードするときにはそれを Name ID としてタグづけます。この規則はユーザーのグループを取得する 3 番目の規則と連携します。

要求規則テンプレート: 入力方向の要求を変換

要求規則の構成:
　要求規則名:  Name ID
　入力方向の要求の種類:  UPN
　出力方向の要求の種類:  Name ID
　出力方向の名前 ID の形式:  永続 ID
　すべての要求値をパス スルーする:  選択

規則 2: RoleSessionName

このルールはユーザーに固有の識別子をセットします。今回は、E-Mail-Addresses を使用します。

要求規則テンプレート: LDAP 属性を要求として送信

要求規則の構成:
　要求規則名:  RoleSessionName
　属性属性ストア:  Active Directory
　LDAP 属性:  E-Mail-Addresses
　出力方向の要求の種類:  https://thinkwithwp.com/SAML/Attributes/RoleSessionName

規則 3: Active Directory グループの取得

このルールは Active Directory にクエリして、ユーザーがアサインされている AWS-123456789012-ExampleStack のようなグループを返します。

要求規則テンプレート: カスタム規則を使用して要求を送信

要求規則の構成:
　要求規則名:  Get Active Directory Groups
　カスタム規則:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

規則 4: ロール

このルールは AWS-AccountNumber のプレフィックスではじめる Active Directory グループを AWS が認識するロールに変換します。この規則では先ほど記録した AWS IdP の ARN が必要になります。 AWS の IdP が ADFS、AccountID が 123456789012 の場合、ARNは次のようになります：

arn:aws:iam::123456789012:saml-provider/ADFS

要求規則テンプレート: カスタム規則を使用して要求を送信

要求規則の構成:
　要求規則名:  Roles
　カスタム規則:

c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"]

 => issue(Type = "https://thinkwithwp.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-123456789012-", "arn:aws:iam::123456789012:saml-provider/ADFS,arn:aws:iam::123456789012:role/"));
  • arn:aws:iam::123456789012:saml-provider/ADFS を自分の AWS IdP の ARN に変更
  • 123456789012 を自分の AWS アカウントの ID (ハイフンなし) に変更

規則 3 で保存した Active Directory グループの変数から 名前が AWS- から始まるグループを返して、グループ名から AWS-123456789012- を削除して IAM ロール名の ExampleStack が残るようにします。IAM ロール名を AWS-ExampleStack という名前にするなどロールの命名規則をカスタマイズするには、規則の最後にあるロール ARN の末尾に “ADFS-” を追加し、arn:aws:iam::1234567891012:role/ADFS- とします。:

これで4つの要求規則を作成しました：

  • NameID
  • RoleSessionName
  • Get Active Directory Groups
  • Role

リレーステートとフォーム認証の有効化

デフォルトでは、AD FS 3.0 は リレーステート (RelayState) パラメータが有効になっていません。AppStream 2.0 はリレーステートを指定した URL を使用してユーザーを AppStream 2.0 スタックに誘導します。

AD FS サーバー上で、メモ帳を管理者として実行し、以下のファイルを開きます。：

%systemroot%\adfs\Microsoft.IdentityServer.Servicehost.exe.config

Microsoft.IdentityServer.Servicehost.exe.config ファイル内から <microsoft.identityServer.web> セクションを探します。このセクション内に以下の行を追加して、保存します。：

<useRelayStateForIdpInitiatedSignOn enabled="true" />

追加すると以下のようになります。：

 

AD FS コンソールで、フォーム認証を有効になっていることを確認します。認証ポリシー を選択します。プライマリ認証 にある、グローバル設定で、編集を選択します。

 

 

エクストラネットで、Forms Authenticationを選択します。イントラネットでも、同様にして選択して OK を選択します。

 

 

AD FSサーバー上で、コマンドプロンプトを管理者として開いて、以下のコマンドを実行し AD FSサービス を停止して開始し、変更を反映します。：

net stop adfssrv
net start adfssrv

 

AppStream 2.0 用のリレーステート URL を作成してスタックにアクセスする

これでリレーステートが有効になったので、URL を生成することができます。

ADFS のリレーステート URL を生成するための Excel スプレッドシートを作成しましたので、RelayGenerator.xlsx からダウンロードできます。このスプレッドシートは AD FS サーバーの完全修飾ドメイン名、アカウントID（ハイフンなし）、スタック名（大文字小文字）、そして AppStream 2.0 リージョンのみ指定が必要です。すべての項目を入力すると、スプレッドシートは以下のスクリーンショットにあるように、青のボックスに URL を生成します。生成されたリレーステート URL を取得するために青のボックスの文字列全体をコピーします。
（訳注：上記 Excel は Excel オンラインや Excel 2016 for Mac では URL 生成が動作できません）

 

 

もしくは、Excelを持っていない場合、リレーステート URL 生成のためのサードパーティツールがあります。しかしながら、AppStream 2.0 で使うにはいくつかのカスタマイズが必要になります。そのようなツールにおけるカスタマイズの手順は以下の通りです。

CodePlex には AD FS RelayState generetor という、HTML ファイルをローカルにダウンロードしてリレーステート URL を作成できるものがあります。このジェネレータは AD FS 2.0 用となっていますが AD FS 3.0 にも利用できます。手動でリレーステート URL を生成することもできますが、文法や大文字小文字が少しでも間違っていると動作しないため、確実に有効な URL となるようにツールを利用することをおすすめします。
（訳注：ジェネレータを利用するには AD FS RelayState generetor ページ内の download archive を選択して zip ファイルをダウンロードし、ファイルを展開します。展開したファイル内の releases/0 フォルダ内のファイルがジェネレータです。ファイルには拡張子が付いていないため、ファイル名の最後に拡張子として .html を付けて開いて下さい。）

URL ジェネレータを開き、デフォルトのテキストフィールドをクリアします。ツールは以下のように表示されます：

 

URL を生成するには、3つの情報が必要になります：

  • IDP URL String
  • Relying Party Identifier
  • Relay State / Target App

 IDP URL String

IDP URL String は AD FS サインオンページを表示するURLで、通常以下のようになります。：

https://<ADFSInstance>/adfs/ls/idpinitiatedsignon.aspx

この構成では、以下のようになります。：

https://adfs01.domain.local/adfs/ls/idpinitiatedsignon.aspx

Relying Party Identifier

この値は常に以下とします。：

https://signin.thinkwithwp.com/saml

Relay State / Target App

AppStream 2.0 スタックへのリレーステート URL です。この URL のフォーマットは以下の通りです。：

https://appstream2.<region>.thinkwithwp.com/saml?stack=Case_Sensitive_Stack_Name&accountID=account_id_without_hyphens

このウォークスルーの例では、region は ap-northeast-1 で、Case_Sensitive_Stack_anem は ExampleStack、account_id_without_hyphenes は 123456789012 で、最終的には以下の URL となります。タック名は大文字小文字が区別されます。

https://appstream2.ap-northeast-1.thinkwithwp.com/saml?stack=ExampleStack&accountId=123456789012

より詳しい情報については、ステップ 6: フェデレーションの中継状態を設定する を見て下さい。

URLジェネレータに値を入力して、リレーステート URL を生成します。

生成されたURL (大文字小文字を区別):

https://adfs01.domain.local/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%253A%252F%252Fsignin.thinkwithwp.com%252Fsaml%26RelayState%3Dhttps%253A%252F%252Fappstream2.us-east-1.thinkwithwp.com%252Fsaml%253Fstack%253D%2520ExampleStack%2526accountId%253D123456789012

生成されたリレーステート URL は保存して、AD FS サーバーにアクセス可能であればどこからでも、既存のドメイン認証を使用して直接ログインできるようになります。認証された後、ユーザーは直接 AppStream 2.0 スタックにシームレスに誘導されます。

設定のテスト

Domain.local に Test User という AD ユーザを TUser というユーザ名でメールアドレスを持たせて作成します。メールアドレスは要求規則で使用されるため必須となります。

次に、AWS-123456789012-ExampleStack スタック用に作成した AD グループに TUser を追加します。

 

 

次に、リレーステート URL を開き、domain\TUser でログインします。

ログイン後、ExampleStack スタックのストリームセッションに誘導されます。管理者として、フェデレーションに影響を与えず、このスタックからフリートの関連付けを外したり異なるアプリケーションのフリートを関連付けしたりして、フェデレーションしたユーザに異なるアプリケーションを届ける事ができます。

ロールにはこの AppStream 2.0 のスタックにのみアクセスを許可するポリシーが割当てられているため、Aamazon EC2 のような他のセクションのコンソールにフェデレーションしたユーザがアクセスしようとしても、以下のスクリーンショットのようにどのリソースに対しても何も操作が許可されていないことがわかります。これが特定の AppStream 2.0 スタックにしかアクセスを許可しないことが重要な理由です。

 

 

AD FS 4.0 を設定

もし AD FS 4.0 (Windows Server 2016) を利用している場合は、これまで説明してきた手順と少しことなるところがあります。

AD FS 3.0 向けの「リレーステートとフォーム認証の有効化」で説明した以下のファイルは、設定変更しないで下さい。:

%systemroot%\adfs\Microsoft.IdentityServer.Servicehost.exe.config

リレーステート URL を生成する時に使用する IdP-initiated サインオンページを有効化するには、PowerShell ターミナルを管理者として開いて以下のコマンドを実行します。:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

この操作でこれまで説明してきた以下の URL が有効になります。:

https://<ADFSInstance>/adfs/ls/idpinitiatedsignon.aspx

次に、リレーステートを有効化するには、管理者として実行した PowerShell ターミナルで以下のコマンドを実行します。:

Set-AdfsProperties -EnableRelayStateForIdpInitiatedSignOn $true

これらの変更を AD FS に反映するために、管理者として実行した PowerShell ターミナルあるいはコマンドプロンプトで以下のコマンドを実行して AD FS サービスを再起動します。

net stop adfssrv
net start adfssrv

これらの変更を実施後に、AD FS 4.0 は AppStream 2.0 の認証フェデレーションに対して動作するようになるはずです。

トラブルシューティング

これまでの通り設定してもエラーが発生した場合には、以下の一般的なエラーメッセージとその際にチェックをお勧めする設定を確認して下さい。

ポリシーが無効

Unable to authorize the session. (Error Code: INVALID_AUTH_POLICY);Status Code:401

このエラーメッセジは、IAM ポリシーで AppStream 2.0 へのアクセスが許可されていない時に出る場合があります。しかしながら、ポリシーやリレーステート URL 内のスタック名が大文字小文字の違い含め適切に入力されていない場合も発生します。例えば、AppStream 2.0 内のスタック名が “ExampleStack” であるにも関わらず、ポリシーには “examplestack” であったり、リレーステート URL に “examplestack” などように大文字小文字間違いがある場合には、このエラーメッセージが表示されます。

リレーステートが無効

Error: Bad Request.(Error Code: INVALID_RELAY_STATE);Status Code:400

このエラーメッセージが表示される場合は、リレーステート URL に他の問題があると思われます。スタック名の間違いや大文字小文字の違いである場合もあります。

この URL には ステップ 6: フェデレーションの中継状態を設定する に一覧があるリージョン毎のエンドポイントが使用されていなければいけません。

アカウント跨ぎのアクセス

Unable to authorize the session. Cross account access is not allowed. (Error Code: CROSS_ACCOUNT_ACCESS_NOT_ALLOWED);Status Code:401

このエラーメッセージが表示される場合は、リレーステート URL にある AccoutId 番号が正しいか確認して下さい。

まとめ

このブログ記事では、AppStream 2.0 の ID フェデレーションを AD FS 3.0 で実現する方法を紹介しました。AD FS 3.0 あるいは 4.0 で AppStream 2.0 の ID フェデレーションを実現できるようになったかと思います。質問等があれば、このブログ記事（翻訳元記事）の最後にあるコメントセクションに書き込んでください。

– Matt Guanti (翻訳は SA 渡邉 源太、辻 義一 が担当しました。原文はこちら)