How exactly to delegate management of identification in AWS Single Sign-On
In this blog post, I show how you can use AWS Single Sign-On (AWS SSO) to delegate administration of user identities. Delegation is the process of providing your teams permissions to manage identities and accounts associated with their teams. You can achieve this by using the existing integration that AWS SSO has with AWS Organizations , and by using tags and conditions in AWS Identity and Access Management (IAM) .
AWS SSO makes it easy to centrally manage access to multiple Amazon Web Services (AWS) accounts and business applications, and to provide users with single sign-on access to all their assigned applications and accounts from one place.
AWS SSO uses permission sets —a collection of administrator-defined policies—to determine a user’s effective permissions to access a given AWS account. Permission sets can contain either AWS managed policies or custom policies that are stored in AWS SSO. Policies are documents that act as containers for one or more permission statements. These statements represent individual access controls (allow or deny) for various tasks, which determine what tasks users can or cannot perform within the AWS account. Permission sets are provisioned as IAM roles in your organizational accounts, and are managed using AWS SSO centrally.
AWS SSO is integrated with aws Organizations tightly, and runs in your AWS Organizations management account. This integration enables AWS SSO to retrieve and manage permission sets across your AWS Organizations configuration.
As you continue to build more of your workloads on AWS, managing access to AWS services and accounts becomes more time consuming for team members that manage identities. With a centralized identity approach that uses AWS SSO, there’s an increased need to delegate control of permission accounts and sets to domain and application owners. Although this is a valid use case, access to the management account in Organizations should be guarded as a security best practice tightly. As an administrator in the management account of an organization, you can control how users and teams access your AWS accounts and applications.
This post shows how you can build comprehensive delegation models in AWS SSO to securely and effectively delegate control of identities to various teams.
Solution overview
Suppose you’ve implemented AWS SSO in Organizations to manage identity across your entire AWS environment. Your organization is growing and the number of accounts and teams that need access to your AWS environment is also growing. You have a small Identity team that is adding constantly, updating, or deleting users or groups and permission sets to enable your teams to gain access to their required services and accounts.
Note : You can learn how to enable AWS SSO from the Introducing AWS Single Sign-On blog post.
As the true number of teams grows, you want to start using a delegation model to enable account and application owners to manage access to their resources, in order to reduce the heavy lifting that is done by teams that manage identities.
Figure 1 shows a simple organizational structure that your organization implemented.
Figure 1: AWS SSO with AWS Organizations
In this scenario, you’ve already built a collection of organizational-approved permission sets that are used across your organization. You have a tagging strategy for permission sets , and you’ve implemented two tags across all your permission sets:
- Environment : The values for this tag are Production or Development . You only apply Production permission sets to Production accounts.
- OU : This tag identifies the organizational unit (OU) that the permission set belongs to.
A value of All can be assigned to either tag to identify organization-wide use of the permission set.
You identified three models of delegation that you want to enable based on the setup just described, and your Identity team has identified three use cases that they want to implement:
- A simple delegation model for a united team to manage all permission sets for a set of accounts.
- A delegation model for support teams to apply read-only permission sets to all accounts.
- A delegation model based on AWS Organizations, where a united team can manage only the permission sets intended for a specific OU.
The AWS SSO delegation model enables three key conditions for restricting user access:
- Permission sets.
- Accounts
- Tags that use the condition aws:ResourceTag , to ensure that tags are present on your permission sets as part of your delegation model.
In the rest of this blog post, I show you how AWS SSO administrators can use these conditions to implement the use cases highlighted here to build a delegation model.
See Delegating permission set administration and Actions, resources, and condition keys for AWS SSO for more information.
Important : The use cases that follow are examples that can be adopted by your organization. The permission sets in these use cases show only what is needed to delegate the components discussed. You need to add additional policies to give groups and users access to AWS SSO.
Some examples:
Identify your permission set and AWS SSO instance IDs
You can use either the AWS Command Line Interface (AWS CLI) v2 or the AWS Management Console to identify your permission set and AWS SSO instance IDs.
Use the AWS CLI
To use the AWS CLI to identify the Amazon resource names (ARNs) of the AWS SSO instance and permission set, make sure you have AWS CLI v2 installed .
To list the AWS SSO instance ID ARN
Run the following command:
To list the permission set ARN
Run the following command:
Use the console
You can also use the console to identify your permission AWS and sets SSO instance IDs.
To list the AWS SSO Instance ID ARN
- Navigate to the AWS SSO in your Region. Choose the Dashboard and then choose Choose your identity source .
- Copy the AWS SSO ARN ID.
Figure 2: AWS SSO ID ARN
To list the permission set ARN
- Navigate to the AWS SSO Service in your Region. Choose AWS Accounts and then Permission Sets .
- Select you were set by the permission want to use.
- Copy the ARN of the permission set.
Figure 3: Permission set ARN
Use case 1: Accounts-based delegation model
In this use case, you create a single policy to allow administrators to assign any permission set to a specific set of accounts.
First, you need to create a custom permission set to use with the following example policy.
The example policy is as follows.
This policy specifies that delegated admins are allowed to provision any permission set to the three accounts listed in the policy.
Note : To apply this permission set to your environment, replace the account numbers following with your account numbers Resource .
Use case 2: Permission-based delegation model
In this use case, you create a single policy to allow administrators to assign a specific permission set to any account. The policy is as follows.
This policy specifies that delegated admins are allowed to provision only the specific permission set listed in the policy to any account.
Note :
Use case 3: OU-based delegation model
In this use case, the Identity team wants to delegate the management of the Development permission sets (identified by the tag key Environment ) to the Test OU (identified by the tag key OU ). You use the Environment and OU tags on permission sets to restrict access to only the permission sets that contain both tags.
To build this permission set for delegation, you need to create two policies in the same permission set:
- A policy that filters the permission sets based on both tags— Environment and OU .
- A policy that filters the accounts belonging to the Development OU.
The policies are as follows.
In the delegated policy, the group or user is only allowed to provision permission sets that have both tags, Environment and OU , set to “Development” and only to accounts in the Development OU.
Note : In the example above arn:aws:sso:::instance/ssoins-11112222233333 is the ARN for the AWS SSO Instance ID. To get your AWS SSO Instance ID, refer to Identify your permission set and AWS SSO Instance IDs .
Create a delegated admin profile in AWS SSO
That you know what’s required to delegate permissions now, you can create a delegated deploy and profile that to your users and groups.
To create a delegated AWS SSO profile
- In the AWS SSO console, sign in to your management browse and account to the Region where AWS SSO is provisioned.
- Navigate to AWS Accounts and choose Permission sets , and choose Create permission set then.
Figure 4: AWS SSO permission sets menu
- Choose Create a custom permission set .
Figure 5: Create a new permission set
- Give a name to your permission set based on your naming standards and select a session duration from your organizational policies.
- For Relay state , enter the following URL:
where is the AWS Region in which you deployed AWS SSO.
The relay state will automatically redirect the user to the Accounts section in the AWS SSO console, for simplicity.
Figure 6: Custom permission set
- Choose Create new permission set . Here is where you can decide the known level of delegation required for your application or domain administrators.
Figure 7: Assign users
See some of the examples in the earlier sections of this post for the permission set.
- If you’re using AWS SSO with AWS Directory Service for Microsoft Active Directory , you’ll need to provide access to AWS Directory Service in order for your administrator to assign permission sets to users and groups.
To provide this access, navigate to the AWS Accounts screen in the AWS SSO console, and select your management account. Assign the required groups or users, and select the permission earlier set that you created. Choose Finish then. - To test this delegation, sign in to AWS SSO. See the newly created permission set you’ll.
Figure 8: AWS SSO sign-on page
- Next to developer-delegated-admin , choose Management console . This should automatically redirect you to AWS SSO in the AWS Accounts submenu.
If you try to provision access by assigning or creating new permission sets to accounts or permission sets you are not explicitly allowed, according to the policies you earlier specified, you shall receive the following error.
Figure 9: Error based on lack of permissions
Otherwise, the provisioning shall be successful.
Summary
You’ve seen that by using tags and conditions on permission sets, application and account owners can use delegation models to manage the deployment of permission sets across the accounts they manage, providing them and their teams with secure access to AWS services and accounts.
Additionally, because AWS SSO supports attribute-based access control (ABAC) , you can create a more dynamic delegation model based on attributes from your identity provider, to match the tags on the permission set.
If you have feedback about this blog post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Single Sign-On forum .
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter .
You must be logged in to post a comment.