[アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました

Takuya Shibata

2022.01.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

先日Amazon AppStream 2.0のサービスが更新され、SAML 2.0を使ったFederated Userを使用する場合にユーザーの属性によって利用可能なアプリケーションを選択できる機能(Application Entitlements)が増えました。

AWSのアナウンスは以下となります。

Application Entitlements？

Application EntitlementsはAWS上だとそのまま「アプリケーションエンタイトルメント」と呼称する様ですが、無理やり日本語にすると「アプリケーション利用資格」といったところでしょうか。
AppStream 2.0のイメージで公開するアプリケーションに対する利用資格となり、ユーザーごとにイメージ内で利用可能なアプリケーションを制御する仕組みとなります。

要はこういう事です。

たとえば「Calc」「Firefox」「Eclipse」の3つのアプリケーションを公開するイメージ(設定上はStackになる)があったとして、経理担当者には「CalcとFirefoxだけ公開」、開発者には「EclipseとFirefoxだけ公開」といった制御ができる様になりました。

技術的にはAppStream 2.0のSAML認証でやり取りできる新しい属性(PrincipalTag)が増え、IdPから属性情報をAWSに送ることで使用可能なアプリケーションのフィルタリングを行う形となります。
SAML 2.0に関わる機能拡張として実装されているためユーザープールのユーザーではこの機能は利用できません。 ^*1

新しい属性の一覧は以下の通りです。

https://aws.amazon.com/SAML/Attributes/PrincipalTag:roles
https://aws.amazon.com/SAML/Attributes/PrincipalTag:department
https://aws.amazon.com/SAML/Attributes/PrincipalTag:organization
https://aws.amazon.com/SAML/Attributes/PrincipalTag:groups
https://aws.amazon.com/SAML/Attributes/PrincipalTag:title
https://aws.amazon.com/SAML/Attributes/PrincipalTag:costCenter
https://aws.amazon.com/SAML/Attributes/PrincipalTag:userType

これらの属性情報を必要に応じてAWSに渡してやります。

試してみた

それでは早速この機能を試してみます。

今回はこちらのブログの内容に倣ってIdPにAzure ADを使う形とします。

AppStream 2.0標準で提供されているサンプルイメージを使い、Azure ADのグループに応じて利用可能なアプリケーションを切り替えてみます。

1. AppStream 2.0 Stackの準備

今回はAWSから提供されているサンプルイメージAmazon-AppStream2-Sample-Image-02-04-2019を使いFleetとStackを準備します。

(今回はmy-saml-stackという名前のStackを用意)

Stackの詳細情報に新たに「Application Entitlements」欄が増えていますので「Create entitlement」をクリックします。

この「Entitlement」で属性に応じた利用アプリケーションの設定を行います。
ここでは経理担当向けにkeiri-appsという名前で「groups属性の値が経理という文字列」だった場合に公開アプリケーション「calcとfirefox」だけを利用可能としてみました。

同様に開発者向けのEntitlementdev-appsも作り、「groups属性の値が開発者という文字列」だった場合に公開アプリケーション「eclipseとfirefox」だけを利用可能としています。

結果こんな感じになります。

2. Azure AD側設定

Azure AD側設定については、基本的にこちらの記事の通りではあるのですが、AppStream 2.0サービスの更新により一部手順が変わっています。

2-1. [AWS] IAM IDプロバイダー設定

Azure ADでエンタープライズアプリケーションを作成しフェデレーションメタデータを取得したのちAWS側でIAM IDプロバイダーの設定を行います。
このIAM IDプロバイダーに設定する信頼関係の設定が少し異なり"sts:TagSession"に対する許可も増やしてやる必要があります。

今回設定するアクセスコントロールポリシーリスト

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<Your account id>:saml-provider/<IAM Provider name>"
      },
      "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

上記ではAWS Blogの記述に倣い "Condition" を "SAML:aud" を使う様に変えていますが、後日改めて管理者ガイドを見ると "SAML:sub_type" のまま変更されていませんでした...
おそらくどちらを選んでも大丈夫だと思います。

Step 2: Create a SAML 2.0 Federation IAM Role

比較用に従来のアクセスコントロールポリシーリストを以下に記載しておきます。

(設定不要) 従来のアクセスコントロールポリシーリスト

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<Your account id>:saml-provider/<IAM Provider name>"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:sub_type": "persistent"
        }
      }
    }
  ]
}

ちなみにアクセス権限については従来同様に設定してください。

2-2. [Azure AD] SAML 2.0クレーム設定

続けてAzure AD側でSAML 2.0のクレーム設定をする際に、従来は

https://aws.amazon.com/SAML/Attributes/Role
https://aws.amazon.com/SAML/Attributes/RoleSessionName
https://aws.amazon.com/SAML/Attributes/SessionDuration

の3クレームを記述しますが、Application Entitlementsを利用する場合、これに加えて最初に紹介した新属性を必要に応じて追加してやります。
今回はAzure ADユーザーの所属グループに応じて利用アプリケーションを切り替えたいのでhttps://aws.amazon.com/SAML/Attributes/PrincipalTag:groups属性に対するクレームを追加します。

Azure ADエンタープライズアプリケーションのSAMLクレームの追加画面で以下の様に

名前 : PrincipalTag:groups
名前空間 : https://aws.amazon.com/SAML/Attributes

を指定します。

そして画面下の「要求条件」をクリックし利用メンバーに応じて属性値を変えてやります。

細かい手順までは説明しませんが、上図の場合だと

1行目で「Azure ADユーザーの所属グループが経理グループ」の場合「属性値 : "経理"」をAWSに渡す
2行目で「Azure ADユーザーの所属グループが開発者グループ」の場合「属性値 : "開発者"」をAWSに渡す

となります。
これでクレームを保存し、最終的に4つのクレームを渡す様に設定します。

2-3. その他設定

その他手順については前掲リンク先記事の通りにしてください。

3. 接続確認

SAML 2.0の設定が完了した後は接続確認をします。

今回はAzure ADの検証ユーザーとして「経理グループ」に所属する担当者01ユーザーと「開発者グループ」に所属する担当者02ユーザーを用意しました。

まずは担当者01ユーザーでhttps://myapps.microsoft.comに接続してAppStream 2.0を利用します。

この様にApplication Entitlementsで設定した「CalcとFirefoxのみ」が利用可能アプリケーションとしてリストアップされます。

次に担当者02ユーザーでAppStream 2.0を利用すると「EclipseとFirefoxのみ」リストアップされます。

この様に利用者の属性に応じて利用アプリケーションを分けることができます。

補足1 : 対象外ユーザーによる利用

ちなみにどちらのグループにも所属しないユーザーで試してみたところ「利用可能アプリケーションなし」になりました。

補足2 : 後からApplication Entitlementsを削除した場合

また、一度設定したApplication Entitlements設定を後から削除した場合は従来どおりイメージに登録されている全アプリケーションが表示されます。

余談 : SAML 2.0 Federated UserのMulti Stack Accessサポートについて

今回Application Entitlementsの追加に合わせて、SAML 2.0で使用するリレー状態のURLからStack名を除外し複数のStackから条件にマッチするアプリケーションをリストアップできる様になったとのことです。

項目	値
従来のリレー状態	https://relay-state-region-endpoint?stack=stackname&accountId=aws-account-id-without-hyphens
現在指定可能なリレー状態	https://relay-state-region-endpoint?accountId=aws-account-id-without-hyphens

イメージとしてはこんな感じでしょう。（未検証）

今回この機能は試しませんが、詳細は以下のドキュメントに記載されていますので参照してください。

SAML 2.0 Multi-Stack Application Catalog

最後に

以上となります。

これまでは利用者ごとで利用アプリケーションを分けたい場合はイメージ(およびStack)自体を分けるしかありませんでした。
このため似た様なイメージを複数運用していた環境もあったことでしょう。
今回の更新によりその様なイメージを集約することができるため運用負荷を下げることが可能になりました。

ユーザー毎の属性情報を使うためSAML 2.0 Federated Userのみ利用可能な制限はあるものの環境によっては非常に便利に使えると思います。

脚注

ユーザープールのユーザーでは追加の属性情報を持てない ↩

[アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました

Application Entitlements？

試してみた

1. AppStream 2.0 Stackの準備