AWS workspaces: Update WorkSpaces SAML IAM role setup and trust policy conditions
Summary
Rewrites the IAM role creation steps for WorkSpaces SAML federation: the old 'Important' warning about not choosing SAML 2.0 programmatic access methods is removed, the SAML:sub_type=persistent restriction is re-documented as an explicit console condition (StringEquals), and the role trust policy example is updated to add the sts:TagSession permission while changing the SAML:aud check from an exact StringEquals match to a wildcarded StringLike match ('https://*signin.aws.amazon.com/saml*').
Security assessment
The change reworks identity-federation guidance for the IAM trust policy that grants SAML-authenticated users access to WorkSpaces. It documents hardening (SAML:sub_type=persistent restricts which SAML assertions can assume the role, and sts:TagSession is explicitly added), but it also weakens the SAML:aud condition from StringEquals to a wildcarded StringLike, which broadens the accepted audience values; there is no reference to a specific vulnerability, CVE, or incident, so this is security-relevant documentation rather than a fix for a known issue.
Evidence
+ "SAML:sub_type": "persistent"
Diff
diff --git a/workspaces/latest/adminguide/setting-up-saml.md b/workspaces/latest/adminguide/setting-up-saml.md index 201be8318..ad472e195 100644 --- a//workspaces/latest/adminguide/setting-up-saml.md +++ b//workspaces/latest/adminguide/setting-up-saml.md @@ -132 +132 @@ To create an IAM role for SAML IdP - 4. For **SAML Provider** select the SAML IdP that you created. + 4. For **SAML Provider** , select the SAML IdP that you created. @@ -134,7 +134 @@ To create an IAM role for SAML IdP -###### Important - -Don't choose either of the two SAML 2.0 access methods, **Allow programmatic access only** or **Allow programmatic and Amazon Web Services Management Console access**. - - 5. For **Attribute** , choose **SAML:sub_type**. - - 6. For **Value** enter `persistent`. This value restricts role access to SAML user streaming requests that include a SAML subject type assertion with a value of persistent. If the SAML:sub_type is persistent, your IdP sends the same unique value for the NameID element in all SAML requests from a particular user. For more information about the SAML:sub_type assertion, see the **Uniquely identifying users in SAML-based federation** section in [ Using SAML-based federation for API access to AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html#CreatingSAML-configuring). + 5. For **Condition** , choose **Add condition** , and then do the following: @@ -142 +136 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 7. Review your SAML 2.0 trust information, confirming the correct trusted entity and condition, and then choose **Next: Permissions**. + 1. For **Key** , choose **SAML:sub_type**. @@ -144 +138 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 8. On the **Attach permissions policies** page, choose **Next: Tags**. + 2. For **Condition** , choose **StringEquals**. @@ -146 +140 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 9. (Optional) Enter a key and value for each tag that you want to add. For more information, see [Tagging IAM users and roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html). + 3. For **Value** , enter `persistent`. @@ -148 +142 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 10. When you're done, choose **Next: Review**. You'll create and embed an inline policy for this role later. +This value restricts role access to SAML user streaming requests. The request must include a SAML subject type assertion with a value of persistent. If the SAML:sub_type attribute is set to persistent, your IdP sends the same unique value for the NameID element in all SAML requests from a particular user. For more information about the SAML:sub_type assertion, see the **Uniquely identifying users in SAML-based federation** section in [ Using SAML-based federation for API access to AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html#CreatingSAML-configuring). @@ -150 +144 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 11. For **Role name** , enter a name that identifies the purpose of this role. Because multiple entities might reference the role, you can't edit the role's name once it is created. + 6. Choose **Next**. @@ -152 +146 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 12. (Optional) For **Role description** , enter a description for the new role. + 7. On the **Add permissions** page, choose **Next**. Don't add a permissions policy here. You embed an inline policy for this role later, in Step 3: Embed an inline policy for the IAM role. @@ -154 +148 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 13. Review the role details and choose **Create role**. + 8. On the **Name, review, and create** page, for **Role name** , enter a name that identifies the purpose of this role. Because multiple entities might reference the role, you can't edit the role's name after it is created. @@ -156 +150 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc - 14. Add the sts:TagSession permission to your new IAM role's trust policy. For more information, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). In your new IAM role's details, choose the **Trust relationships** tab, and then choose **Edit trust relationship***. When Edit Trust Relationship policy editor opens, add the **sts:TagSession*** permission, as follows: + 9. (Optional) For **Description** , enter a description for the new role. @@ -158 +152 @@ Don't choose either of the two SAML 2.0 access methods, **Allow programmatic acc -JSON + 10. (Optional) Under **Step 3: Add tags** , choose **Add new tag** and enter a key and value for each tag that you want to add. For more information, see [Tagging IAM users and roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html). @@ -159,0 +154 @@ JSON + 11. Choose **Create role**. @@ -161,2 +156 @@ JSON -**** - + 12. Add the `sts:TagSession` permission to your new IAM role's trust policy. For more information, see [Passing session tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). In your new IAM role's details, choose the **Trust relationships** tab, and then choose **Edit trust policy**. When the Edit trust policy editor opens, add the `sts:TagSession` permission so that the policy matches the following: @@ -178 +172,4 @@ JSON - "SAML:aud": "https://signin.aws.amazon.com/saml" + "SAML:sub_type": "persistent" + }, + "StringLike": { + "SAML:aud": "https://*signin.aws.amazon.com/saml*" @@ -188,2 +185 @@ JSON - -Replace `IDENTITY-PROVIDER` with the name of the SAML IdP you created in Step 1. Then choose **Update Trust Policy**. +In the policy, `IDENTITY-PROVIDER` matches the name of the SAML IdP that you selected in Step 1, and `111122223333` is your AWS account ID. After you add the `sts:TagSession` permission, choose **Update policy**.