AWS singlesignon documentation change
Summary
Updated references from 'AWS Directory Service' to 'Directory Service' and fixed URL formatting in documentation links
Security assessment
The changes primarily involve terminology updates (removing 'AWS' from Directory Service references) and URL formatting fixes. No new security content was added nor existing security guidance modified. The updates maintain existing security recommendations about delegated admin permissions and SCIM token management without introducing new security implications.
Diff
diff --git a/singlesignon/latest/userguide/delegated-admin.md b/singlesignon/latest/userguide/delegated-admin.md index 6fdb2032c..bf14a2396 100644 --- a//singlesignon/latest/userguide/delegated-admin.md +++ b//singlesignon/latest/userguide/delegated-admin.md @@ -54 +54 @@ Here are some best practices to consider before you configure delegated administ -If you use an external identity source such as an IdP or AWS Directory Service, you should implement policies that limit the identity store actions that an IAM Identity Center admin can take from within the delegated administration account. Write and delete operations should be carefully considered. Generally, the external identity source is the source of truth for users and their attributes, and for group memberships. If you modify these using the identity store APIs or the console, your changes will be overwritten during normal synchronization cycles. It's best to leave these operations to the exclusive control of your identity source of truth. This also guards against an IAM Identity Center administrator modifying group memberships to grant access to a group-assigned permission set or application, rather than leaving the group membership control to your IdP admin. You should also guard who can create SCIM bearer tokens from the delegated administration account, as these could enable a member account admin to modify groups and users through a SCIM client. +If you use an external identity source such as an IdP or Directory Service, you should implement policies that limit the identity store actions that an IAM Identity Center admin can take from within the delegated administration account. Write and delete operations should be carefully considered. Generally, the external identity source is the source of truth for users and their attributes, and for group memberships. If you modify these using the identity store APIs or the console, your changes will be overwritten during normal synchronization cycles. It's best to leave these operations to the exclusive control of your identity source of truth. This also guards against an IAM Identity Center administrator modifying group memberships to grant access to a group-assigned permission set or application, rather than leaving the group membership control to your IdP admin. You should also guard who can create SCIM bearer tokens from the delegated administration account, as these could enable a member account admin to modify groups and users through a SCIM client. @@ -58 +58 @@ There may be times when write or delete operations are appropriate from the dele -The example SCP below prevents assigning users to groups through the Identity Store API and the AWS Management Console, which is recommended when your identity source is external. This does not affect user sync from AWS Directory Service or from an external IdP (via SCIM). +The example SCP below prevents assigning users to groups through the Identity Store API and the AWS Management Console, which is recommended when your identity source is external. This does not affect user sync from Directory Service or from an external IdP (via SCIM). @@ -74 +74 @@ It is possible that, although you use an external identity source, your organiza -If you'd like to prevent adding users only to groups that grant access to the management account, you can reference those specific groups using the group ARN in the following format: `arn:${Partition}:identitystore:::group/${GroupId}`. This and other resource types available in the Identity Store are documented in [Resource types defined by AWS Identity Store](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentitystore.html#awsodemtotustpre-resoruces-for-iam-policies) in the _Service Authorization Reference_. You can also consider including additional Identity Store APIs in the SCP. For more information, see [Actions](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_Operations.html)in the Identity Store API Reference. +If you'd like to prevent adding users only to groups that grant access to the management account, you can reference those specific groups using the group ARN in the following format: `arn:${Partition}:identitystore:::group/${GroupId}`. This and other resource types available in the Identity Store are documented in [Resource types defined by AWS Identity Store](https://docs.aws.amazon.com//service-authorization/latest/reference/list_awsidentitystore.html#awsodemtotustpre-resoruces-for-iam-policies) in the _Service Authorization Reference_. You can also consider including additional Identity Store APIs in the SCP. For more information, see [Actions](https://docs.aws.amazon.com//singlesignon/latest/IdentityStoreAPIReference/API_Operations.html)in the Identity Store API Reference. @@ -90 +90 @@ If your delegated admin needs to set up user provisioning with SCIM, or perform -If you create your users and groups directly in IAM Identity Center, rather than using an external IdP or AWS Directory Service, then you should take precautions for who can create users, reset passwords, and control group membership. These actions give the administrator great powers for who can sign in and who can gain access through membership in groups. These policies are best implemented as in-line policies within the permission sets you use for your IAM Identity Center administrators, rather than as SCPs. The following example inline policy has two objectives. Firstly, it prevents adding users to specific groups. You can use this to prevent delegated admins from adding users to groups that grant access to the management account. Secondly, it prevents the issuance of SCIM bearer tokens. +If you create your users and groups directly in IAM Identity Center, rather than using an external IdP or Directory Service, then you should take precautions for who can create users, reset passwords, and control group membership. These actions give the administrator great powers for who can sign in and who can gain access through membership in groups. These policies are best implemented as in-line policies within the permission sets you use for your IAM Identity Center administrators, rather than as SCPs. The following example inline policy has two objectives. Firstly, it prevents adding users to specific groups. You can use this to prevent delegated admins from adding users to groups that grant access to the management account. Secondly, it prevents the issuance of SCIM bearer tokens.