WorkSpaces Personal で SAML 2.0 を設定する

1. WorkSpaces ディレクトリで使用する Microsoft Active Directory からのユーザー ID を統合するように IdP を設定します。WorkSpace を持つユーザーの場合、IdP を使用して WorkSpaces にサインインするには、Active Directory ユーザーおよび SAML クレーム値の sAMAccountName 属性と email 属性が一致している必要があります。Active Directory を IdP と統合する方法の詳細については、IdP のドキュメントを参照してください。

2. AWS との信頼関係を確立するために IdP を設定します。

   • AWS フェデレーションの構成の詳細については、「サードパーティーの SAML ソリューションプロバイダーと AWS の統合」を参照してください。関連する例には、AWS マネジメントコンソールにアクセスするための AWS IAM との IdP 統合があります。

   • IdP を使用して、組織を IdP として定義するフェデレーションメタデータドキュメントを生成し、ダウンロードします。署名されたこの XML ドキュメントは、証明書利用者の信頼を確立するために使用されます。後で IAM コンソールからアクセスできる場所にこのファイルを保存します。

3. WorkSpaces 管理コンソールを使用して、WorkSpaces のディレクトリを作成または登録します。詳細については、「WorkSpaces のディレクトリを管理する」を参照してください。WorkSpaces の SAML 2.0 認証は、次のディレクトリタイプでサポートされています。

   • AD Connector

   • AWS Managed Microsoft AD

4. サポートされているディレクトリタイプを使用して IdP にサインインできるユーザー用の WorkSpace を作成します。WorkSpaces 管理コンソール、AWS CLI、または WorkSpaces API を使用して WorkSpace を作成できます。詳細については、「WorkSpaces を使用して仮想デスクトップを起動する」を参照してください。

SAML IdP への IAM ロールを作成するには

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

2. ナビゲーションペインで [ロール] を選択してから、[ロールを作成する] を選択します。

3. [ロールタイプ] で [SAML 2.0 フェデレーション] を選択します。

4. [SAML プロバイダー] で、作成した SAML IdP を選択します。

   重要

   2 つの SAML 2.0 アクセスメソッド ([プログラムによるアクセスのみを許可する] または [プログラムによるアクセスと Amazon Web Services マネジメントコンソールによるアクセスを許可する]) のいずれも選択しないでください。

5. [属性] で 、[SAML:sub_type] を選択します。

6. [値] に「persistent」と入力します。この値は、値が persistent の SAML サブジェクトタイプアサーションを含む SAML ユーザーストリーミングリクエストへのロールアクセスを制限します。SAML:sub_type が persistent の場合、IdP は特定のユーザーからのすべての SAML リクエストで同じ一意の値を NameID 要素に送信します。SAML:sub_type アサーションに関する詳細は、「SAML ベースのフェデレーションを使用した AWS への API アクセス」の「SAML ベースのフェデレーションでユーザーを一意に識別する」を参照してください。

7. 正しい信頼されたエンティティおよび条件を確認して SAML 2.0 の信頼情報を確かめたら、[次: アクセス許可] を選択します。

8. [アクセス権限ポリシーをアタッチする] ページで、[Next: Tags] を選択します。

9. (オプション) 追加する各タグのキーと値を入力します。詳細については、「IAM ユーザーとロールのタグ付け」を参照してください。

10. 終了したら、[Next: Review] を選択します。後でこのロールにインラインポリシーを作成して埋め込みます。

11. [Role name] (ロール名) に、このロールの目的を識別できる名前を入力します。なぜなら複数エンティティがロールを参照している可能性があります。ロールが作成された後のロールの名前の編集はできません。

12. (オプション) [ロールの説明] に、新しいロールの説明を入力します。

13. ロールの詳細を確認し、[ロールの作成] を選択します。

14. 新しい IAM ロールの信頼ポリシーに sts:TagSession アクセス権限を追加します。詳細については、「AWS STS でのセッションタグの受け渡し」を参照してください。新しい IAM ロールの詳細ページで、[Trust relationships] (信頼関係) タブを選択してから、[Edit trust relationship] (信頼関係の編集) を選択します。信頼関係の編集ポリシーエディタが開いたら、[sts:TagSession*] アクセス許可を次のように設定します。

    JSON

    {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Federated": "arn:aws:iam::111122223333:saml-provider/IDENTITY-PROVIDER"
                },
                "Action": [
                    "sts:AssumeRoleWithSAML",
                    "sts:TagSession"
                ],
                "Condition": {
                    "StringEquals": {
                        "SAML:aud": "https://signin.aws.amazon.com/saml"
                    }
                }
            }
        ]
    }
    

1. 作成した IAM ロールの詳細で、[Permissions] (アクセス許可) タブを選択し、必要なアクセス許可を、ロールのアクセス許可ポリシーに追加します。[Create policy wizard] (ポリシーの作成ウィザード) が起動します。

2. [ポリシーの作成] で、[JSON] タブを選択します。

3. 次の JSON ポリシーを JSON ウィンドウにコピーして貼り付けます。次に、AWS リージョンコード、アカウント ID、ディレクトリ ID を入力してリソースを編集します。以下のポリシーでは、"Action": "workspaces:Stream" は、WorkSpaces ディレクトリのデスクトップセッションに接続する権限を WorkSpaces ユーザーに提供するアクションです。

   JSON

   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "workspaces:Stream",
               "Resource": "arn:aws:workspaces:us-east-1:123456789012:directory/DIRECTORY-ID",
               "Condition": {
                   "StringEquals": {
                       "workspaces:userId": "${saml:sub}"
                   }
               }
           }
       ]
   }
   

   REGION-CODE を WorkSpaces ディレクトリが存在する AWS リージョンに置換します。DIRECTORY-ID を WorkSpaces 管理コンソールで確認できる WorkSpaces ディレクトリ ID に置換します。AWS GovCloud (米国西部) または AWS GovCloud (米国東部) のリソースの場合は、ARN の形式として arn:aws-us-gov:workspaces:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:directory/DIRECTORY-ID を使用します。

4. 完了したら、[ポリシーの確認] をクリックします。構文エラーがある場合は、「ポリシーの検証」によってレポートされます。

SAML 2.0 との統合を有効にするには

1. https://console.aws.amazon.com/workspaces/v2/home で WorkSpaces コンソールを開きます。

2. ナビゲーションペインで [ディレクトリ] を選択します。

3. WorkSpaces のディレクトリ ID を選択します。

4. [Authentication] (認証) で、[Edit] (編集) を選択します。

5. [Edit SAML 2.0 Identity Provider] (SAML 2.0 ID プロバイダーの編集) を選択します。

6. [Enable SAML 2.0 authentication] (SAML 2.0 認証の有効化) チェックボックスをオンにします。

7. [User Access URL] (ユーザーアクセス URL) と [IdP deep link parameter name] (IdP ディープリンクパラメータ名) には、ステップ 1 で設定した IdP とアプリケーションに該当する値を入力します。IdP ディープリンクパラメータ名を省略すると、デフォルトで「RelayState」という名前になります。次の表に、アプリケーションの ID プロバイダー別に固有のユーザーアクセス URL とパラメータ名を示します。

   許可リストに追加するドメインと IP アドレス

   ID プロバイダー	パラメータ	ユーザーアクセス URL
   ADFS	RelayState	https://<host>/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID=<relaying-party-uri>
   Azure AD	RelayState	https://myapps.microsoft.com/signin/<app_id>?tenantId=<tenant_id>
   Duo Single Sign-On	RelayState	https://<sub-domain>.sso.duosecurity.com/saml2/sp/<app_id>/sso
   Okta	RelayState	https://<sub_domain>.okta.com/app/<app_name>/<app_id>/sso/saml
   OneLogin	RelayState	https://<sub-domain>.onelogin.com/trust/saml2/http-post/sso/<app-id>
   JumpCloud	RelayState	https://sso.jumpcloud.com/saml2/<app-id>
   Auth0	RelayState	https://<DefaultTenatName>.us.auth0.com/samlp/<Client_Id>
   PingFederate	TargetResource	https://<host>/idp/startSSO.ping?PartnerSpId=<sp_id>
   PingOne for Enterprise	TargetResource	https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=<app_id>&idpid=<idp_id>

   ユーザーアクセス URL は、通常、未承諾の IdP を起点とする SSO のプロバイダーによって定義されます。ユーザーはこの URL をウェブブラウザに入力して、SAML アプリケーションに直接フェデレートできます。IdP のユーザーアクセス URL とパラメータ値をテストするには、[Test] (テスト) を選択します。テスト URL をコピーして現在のブラウザまたは別のブラウザのプライベートウィンドウに貼り付けると、現在の AWS マネジメントコンソールセッションを中断せずに SAML 2.0 ログオンをテストできます。IdP を起点とするフローが開いたら、WorkSpaces クライアントを登録できます。詳細については、「Identity provider (IdP)-initiated flow」(ID プロバイダー (IdP) を起点とするフロー) を参照してください。

8. [Allow clients that do not support SAML 2.0 to login] (SAML 2.0 をサポートしていないクライアントにログインを許可する) チェックボックスをオンまたはオフにして、フォールバック設定を管理します。SAML 2.0 をサポートしていないクライアントタイプまたはバージョンを使用しているユーザーに WorkSpaces へのアクセスを引き続き提供する場合や、ユーザーが最新のクライアントバージョンにアップグレードする時間が必要な場合に、この設定をオンにします。

   注記

   この設定により、ユーザーは SAML 2.0 ではなく、古いクライアントバージョンを使用したディレクトリ認証を通じてログインできます。

9. ウェブクライアントで SAML を使用するには、Web Access を有効にします。詳細については、「Amazon WorkSpaces Web Access を有効化および設定する」を参照してください。

   注記

   SAML を使用する PCoIP は Web Access ではサポートされていません。

10. [保存] を選択します。これで WorkSpaces ディレクトリで SAML 2.0 との統合が有効になりました。IdP およびクライアントアプリケーションを起点とするフローを使用して WorkSpaces クライアントアプリケーションを登録し、WorkSpaces にサインインできます。