ためすこと
前回、AppStream2.0をLinuxフリートインスタンスで試してみました。今回はAppStream2.0のユーザーをActiveDirectoryで認証させることを試してみます。フリート自体はドメイン参加させません。
IAM Identity Centerのユーザー認証情報を連携
AWS公式にIAM Identity Centerのユーザー認証情報をAppStream2.0のユーザーにフェでレートする手順の紹介がありますので、参照します。
この記事に記載の９つの手順を実施するようです。
少し残念なことにIAM Identity CenterのことをSSOと読んでいたり、画面が今とかなり異なっていたりと手順が最新になっていないため、この通りにいかない可能性があります。
手順確認
それでは１つずつ手順を確認しながら進めていきます。
1) AWS SSO directory options
IAM Identity Center（旧AWS SSO）に接続する方法はいくつかあるようです。今回 AD Connectorを使用します。
2) Connect AWS SSO to an existing directory
IAM Identity Centerをディレクトリサービスに接続します。私の環境は、すでにローカルPCのActiveDirectoryと接続しています。
3) Create the AWS SSO Application for AppStream 2.0
IAM Identity Centerのダッシュボードで、新規にSAMLアプリケーションを登録する手順となっています。
IAM Identity Center > アプリケーションへ移動します。「カスタマー管理」タブに移り、「アプリケーションを追加」をクリックします。
アプリケーション選択の画面になります。記載の手順とだいぶ違う感じです。「カタログからアプリケーションを選択する」を選びます。
アプリケーションカタログに「AppStream2.0」があるので選択して、「次」をクリックします。
アプリケーションの設定で表示名を入力します。デフォルトがAppStream2.0となっていますが、ここは手順にならってスタック名にします。事前に作成したスタック名と同じにします。
手順にもあるメタデータセクションです。ファイルをダンロードしておけと書いてありますが、たぶん後でもダウンロードできると思いますので無視します。だめです。ステップ4)ですぐに必要になりますので、「IAM Identity Center SAML メタデータ」ファイルをダウンロードしてください。
アプリケーションプロパティセクションです。手順では、アプリケーション開始URLは空白で、リレーステートURLを入力しろとの指示があります。
私の場合、https:// 以降は appstream2.ap-northeast-1.aws.amazon.com/saml?stack=MyAppStreamStack1&accountId=<アカウントID>としました。
アプリケーションメタデータセクションでは、すでに必要な値が入力されていましたので、「送信」をクリックします。
アプリケーションが追加されました。
4) Create AppStream 2.0 identity provider
次にAppStream2.0へID情報を提供するIdPを作成します。マネジメントコンソールのIAM画面より行います。
IAM > ID プロバイダ へ移動し、「プロバイダを追加」をクリックします。
プロバイダの設定で「SAML」を選択、プロバイダ名を手順にならって入力し、ステップ3)でダウンロードしていたメタデータファイルをアップロードします。
「プロバイダを追加」をクリックします。
IdPが追加されました。
5) Create the AppStream 2.0 stack stream access role
次にフェデレーションされたユーザーに割当たるIAM Roleを作成します。
IAM > ロールに移動し、「ロールを作成」をクリックします。
信頼されたエンティティタイプは「SAML2.0 フェデレーション」を選択します。
SAML2.0 フェデレーションの設定で以下のようにして、「次へ」をクリックします。
ステップ4)で作成したIdPを選択
許可されるアクセスは２つともチェックしない
属性に「SAML:aud」を選択
値に「https://signin.aws.amazon.com/saml」を入力
許可ポリシーでは何も追加せずに、「次へ」をクリックします。
ロール名を入力します。それ以外はデフォルトのまま「ロールを作成」をクリックします。
ロールが作成されます。ロールのARNをメモしてください。（ステップ7で使用します）
6) Attach an inline policy to the AppStream 2.0 Stream access role
5)で作成したロールにインラインポリシーを追加します。手順ではインラインポリシーになっていますが、カスタムポリシーを別に作成してアタッチしてもよいと思います。
許可を追加より、「インラインポリシーを作成」をクリックします。
以下のポリシーを追加します。
※手順の画像では、Condition句に"saml:sub_type": "persistent" もStringEqualsの条件に追加されていますが、リンク先ではこの記述がなかったため、記述なしを使用しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appstream:Stream",
"Resource": "arn:aws:appstream:ap-northeast-1:<アカウントID>:stack/MyAppStreamStack1",
"Condition": {
"StringEquals": {
"appstream:userId": "${saml:sub}"
}
}
}
]
}
ポリシー名を入力して、「ポリシーの作成」をクリックします。
インラインポリシーが追加されました。
7) Create AWS SSO attribute mappings
今度はIAM Identity Centerのアプリケーションの設定画面に戻り、属性マッピングの設定を行います。このステップの手順ではフリートがドメイン参加している場合の説明になっています。フリートがドメイン参加していない場合（LinuxOSなど）、属性マッピングが利用できるか不明です。
IAM Identity Center > アプリケーション > MyAppStreamStack1へ移動し、アクションから「属性マッピングを編集」をクリックします。
手順にならって入力します。１行目と２行目はデフォルトで入力されていたため、３行目だけ追加しました。 すると、ステップ8のテストで403 forbiddenエラーになってしまいました。１行目と2行目の値を、${user:subject}に変更し、3行目を追加しました。
| 行数 | 属性名 | 値 | 形式 |
|---|---|---|---|
| 1 | Subject | ${user:subject} | persistent |
| 2 | https://aws.amazon.com/SAML/Attributes/RoleSessionName | ${user:subject} | unspecified |
| 3 | https://aws.amazon.com/SAML/Attributes/Role | arn:aws:iam::012345678910:role/ExampleStack,arn:aws:iam:: 012345678910:saml-provider/AWS_SSO_ExampleStack | unspecified |
値は、ステップ5で作成したIAM RoleのARNと、ステップ4で作成したIDプロバイダのARNをカンマで繋いだ文字列になっています。
8) Assign users and test
最後の調整です。IAM Identity Centerのアプリケーションにユーザーを割当ます。
IAM Identity Center > アプリケーション > MyAppStreamStack1へ移動し、「ユーザーとグループを割り当てる」をクリックします。
AD Connectorで取得したADユーザが表示されています。ユーザーを選択して、「ユーザーを割り当て」をクリックします。
ユーザーが割り当てられました。
それではAppStreamへADユーザーでログインできるかテストします。
IAM Identity Centerのサインインページへアクセスします。
割り当てしたADユーザーでログインします。
サインインすると、登録したアプリケーションが表示されています。MyAppStreamStack1をクリックします。
残念ながら、エラーになってしまいました。なにか権限が必要そうです。
※どうやら属性マッピングの指定に問題があったようです。
ステップ7は修正済みです。
こちらはIAM Identity Centerからみたユーザーのプロファイル情報ですが、手順の設定では「プライマリEメール」の値を利用するようになっていたため、うまくいかなかったようです。
属性マッピングの指定を修正後、MyAppStreamStack1を起動すると、AppStreamのアプリを選択する画面に遷移しました。
アプリのストリーミングも問題なくできました！
ステップ8の残りの手順ではADのセキュリティグループを利用して、そのメンバーのユーザーでも利用できることを確認していますが、ここでは省略させていただきます。
9) Using the AWS SSO Directory to manage user access to AppStream 2.0
最後のステップは、ActiveDirectoryではなく、IAM Identity Center自体のディレクトリを利用する内容となっていたため、今回試す要件がないため、ここまでとなります。
まとめ
AppStream2.0のユーザーをIAM Identity Centerで認証させることができました。そのソースをActiveDirectoryとすることで、ActiveDirectoryのユーザーを使用して認証させることができました。属性マッピングについては理解できていないことが多いので、いつか整理してみたいと思います。