AWS SSO (Single Sign-On)

Learn via video courses

Overview

AWS Single Sign-on (SSO) service is a cloud-based SSO solution that gives a group of users streamlined and controlled access to Amazon web services as well as complete access to different cloud Apps and the AWS administration interface with a single set of login credentials. It assists users in managing SSO access and user rights across their AWS accounts.

What is AWS SSO?

Customers can use AWS Single Sign-On to seamlessly establish (or) link their personnel credentials and manage employee access across AWS accounts and applications in a centralized way. For organizations of any size or type, IAM Identity Centre is the recommended method for user authentication and authorization on AWS. AWS SSO for AWS governs access to AWS facilities and benefits. The  AWS SSO  handles access to all AWS accounts inside an AWS Organization, as well as accessibility to other cloud apps. AWS SSO features a user interface via which end users may locate and access their allocated AWS accounts, cloud apps, and custom applications all in one location.

Some keys features of AWS SSO are:

  • User interface for AWS SSO: Your users may quickly locate and access any applications and AWS accounts to which you have given them access on the user portal.

  • AWS Organizations Integration: You can control access to all of your organization's AWS accounts thanks to the integration of AWS SSO with Organizations.

  • Integrating Active Directory on-premises: AWS Directory Service is used to combine AWS SSO with your on-premises Active Directory. Using their Active Directory login information, users may access their AWS accounts and business apps.

  • Centralized administration of permissions: You may centrally control the permissions given to users who access AWS accounts through the AWS Management Console by using AWS SSO.

  • Application setup wizard: By utilizing the AWS SSO application configuration wizard, you may set up SSO access to any business application that supports SAML.

  • Built-in SSO integrations For many widely used corporate apps, including Office 365, Salesforce, and Box, AWS SSO offers built-in SSO connectors and detailed implementation guides.

  • Auditing in one location AWS SSO records all administrative and sign-in operations in CloudTrail. These logs may be sent to SIEM tools like Splunk and Sumo Logic for analysis.

Prerequisites for Setting SSO for AWS Accounts

To configure SSO for AWS organizations, you will require the following requirements.

  1. AWS organization account

  2. Configure the AWS Organization Service.

  3. Obtain the signed certificate from the AWS organization.

How to Use AWS SSO?

aws-sso-use-cases

  • The AWS Management Console provides access to the AWS SSO service.

  • After gaining access to the service, an IT administrator can integrate end users' identities and credentials from Microsoft AD. The administrator may then provide users access to numerous applications, and AWS Organization accounts by adding permissions to AD groups. It may also offer customized permission settings to various resources and AWS accounts based on a user's job role.

  • A user can use their AD credentials to visit the AWS SSO interface and gain access to resources. AWS SSO, like other single sign-on systems, eliminates the need for a user to remember numerous user names and passwords to access various services and apps.

Now we can discuss an example of one use case of AWS SSO to manage SSO access to business apps:  SSO access to widely used corporate apps like Box, Office 365, and Salesforce is already supported by AWS SSO. These applications are available in the AWS SSO interface, and the application configuration wizard makes configuring SSO access simple. Setting up SSO for corporate applications:

  • Select Applications in the navigation pane of the AWS SSO interface.

select-applications

  • Choose Select one or more of the apps from the list when adding a new application.

select-dropbox

  • You need to follow step-by-step instructions to set up the application for SSO access depending on whatever application you select. The instructions direct the user to set up your application using the information supplied in the AWS SSO metadata section before providing the application's configuration information. When you're finished, choose Save changes.

configure-dropbox

  • By selecting the Attribute mappings tab, you may optionally offer extra Security Assertion Markup Language (SAML) attribute mappings. This is only required if you wish to provide user characteristics from your corporate directory to the application.

attribute-mapping-for-dropbox

  • Select the Assigned user's option to provide your users access to this application. Select Assign users to search your linked directory, then select a person or group that may use this program.

select-assigned-users-in-dropbox

Setting up AWS SSO

Activating the service So let's give it a go. The first step is to enable the SSO service in your Amazon Web Services account.

Log in to your AWS administration account – the one at the heart of your firm that pays the bill. It must be the management account - AWS SSO requires this. Select the desired region – it doesn't matter which one because it's a worldwide service. However, your corporation may have data sovereignty concerns. Navigate to "AWS Single Sign-On." Let's get started by clicking the "Enable AWS SSO" button.

setting-up-aws-sso

Set the URL for your user portal. "AWS SSO enabled successfully," it reports. Brilliant! It suggests various activities to get us started, but first, let's peek at the User portal URL in the upper right corner. It's a little boring, so click Customize to modify that string of numbers into something more appropriate for your company.

Select your identification source Return to the suggested next steps and begin with step 1 - choose your identity source. Click on Change identity source. It will present you with three options. For the time being, choose AWS SSO, which will create a lightweight - and free - directory dedicated to this service. Other alternatives include connecting with other directories like ActiveDirectory or Google Workspaces, which, while not difficult to set up, we'll leave as a more sophisticated option. Click Next and proceed with the confirmation processes.

Add users and configure permissions.

  • The next step is to add some users.
  • On the left menu, select "Users," then "Add user." Fill in your personal information and then click Next.
  • It will ask us to add the new user to a group, but we don't have any yet, so click Next, then confirm the data and click "Add user" one last time.
  • You see a pop-up window having the user's credentials; store them somewhere secure.
  • This is where things get interesting - let's start allowing the user access to your organization's AWS accounts. To do this, we establish a three-way link between a group of AWS accounts and a "permission set," essentially an Identity and Access Management (IAM) policy describing what the accounts can and cannot do.

Set up an Admin Group  Assigning access to specific individuals is never recommended; build a group of users instead:

  • Go to the Groups page, add your new user to the Administrators group you just created, and then save the group.
  • Click "Create permission set," "Predefined permission set," "AdministratorAccess," twice-click "Next," and then "Create" on the permission sets screen.
  • We finish the connection by visiting the "AWS accounts" page. In this case, our administrators must manage every account, so click "Assign users or groups" after selecting each account in the organization with a check (you can do this by switching from hierarchy to list view).
  • The Administrators group should be checked in the Groups tab, then click Next. Tick the box for our new AdministratorAccess permission set, then click Next and Submit to finish the procedure.

Test AWS SSO

aws-sso-tests

This page contains a list of all AWS accounts in my company, along with links to visit the administration interface or obtain API access credentials. Each account's AdministratorAccess line is located beneath the account name. Therefore, using my login and password to access any account within my company is now quite simple. Swapping roles or using new credentials for each account is not required. Just log in once and enjoy the "Single Sign-on" experience.

AWS IAM vs. AWS SSO

Accounts Addition The administrator must set up two new AWS accounts, a test account, and a production account, for Lambda and DynamoDB in order to separate environments and guarantee adequate access. Following the registration procedure, the user must establish two new accounts using AWS IAM. The user must launch the AWS Organizations service and add two new accounts using AWS SSO.

Setting Identification Services  Adding multiple identity providers to a single account is supported by AWS IAM. Administrators must sign in to each AWS account using AWS IAM and set JumpCloud as the identity provider. There is only one identity provider that AWS SSO supports. Once the administrator has set up JumpCloud as his identity provider using AWS SSO, it will serve as the identity provider for all of his AWS accounts, both new and old.

Specifying Roles and Permissions The permissions and policies that determine what users are allowed and forbidden to do within an AWS account, as well as which AWS resources they have access to, must be set by the administrator. Using AWS IAM, the administrator must sign in to each AWS account and create a new role. Alternatively, from one AWS account, Account A, the administrator can create policies that permit a role to be assumed in another AWS account and restrict access to resources like S3, Lambda, and CloudWatch in Account B. Administrators can utilize current AWS SSO rules and permission settings by utilizing AWS SSO. At the account level, policies and permission sets are applied to groups of users or at the organization level. He can establish new ones via the AWS SSO admin panel if the previously specified ones do not apply to these new accounts.

Group and User Provisioning Federated users log in using AWS IAM as a role rather than their unique user identity. No requirement for the administrator to establish users or groups. The administrator will need to manually create a user in AWS IAM if it is necessary to create a user account that is not controlled by an identity provider and can log in as a user identity. He could build groups to organize his AWS users and make giving them access to resources easier if he has a business case that calls for several AWS users. The administrator can set up AWS SSO to automatically generate users in SCIM when new users are established in his identity provider. Otherwise, he would have to manually establish users and groups within AWS.

Access Control Now that the roles have been developed, the administrator may assign them to his users and groups.

AWS IAM assigns responsibilities to federated users based on attributes in the SAML assertion for each AWS account. Administrators must create a role attribute at the connector, group, or user level in JumpCloud for each role. He must obtain the Amazon Resource Name (ARN) for each account and role declared, as well as generate the SAML attribute value from the ARNs of the roles and accounts. You can either create new users and groups in AWS Single Sign-On (SSO) or work with existing users and groups in Active Directory or an external identity provider. SSO must first be aware of the users and groups before they can be utilized to provide access rights in an AWS account. Similarly, SSO-enabled apps may interact with SSO-aware users and groups. The process of making user and group information available for usage by SSO enabled apps is known as provisioning.

Conclusion

  • AWS SSO is great for managing many Amazon Web Services accounts. Admin may now provide users access to the accounts they require at the user or group level after creating an Engineering group in AWS SSO.

  • AWS SSO can scale up to large corporate domains and down to a single person's AWS account.

  • Suppose a user wishes to offer the Engineering group access to the production account for Lambda and DynamoDB. In that case, all they have to do via the AWS SSO service is choose AWS accounts, check the account box, and assign them at either the group or user level.

  • AWS SSO automatically grants each new user who joined the group the same degree of access as other group members. It will provide Power User access to the Lambda and DynamoDB production accounts to the New User.

  • AWS is encouraging users to migrate from AWS IAM to AWS SSO. Amazon has a banner advertising AWS SSO on the identity providers page of AWS IAM.