Post

AWS - IdenAccessManage - SSO Single Sign-On

Posted
By Grace L
11 min read

[toc]

AWS Single Sign-On

  • cloud-based single sign-on (SSO) service
  • centrally manage SSO access to all of your AWS accounts and cloud applications.
  • manage SSO access and user permissions across all your AWS accounts in AWS Organizations.
  • manage access and permissions to commonly used third-party software as a service (SaaS) applications, AWS SSO-integrated applications as well as custom applications that support Security Assertion Markup Language (SAML) 2.0.
  • AWS SSO includes a user portal where your end-users can find and access all their assigned AWS accounts, cloud applications, and custom applications in one place.

AWS SSO Features

  • Integration with AWS Organizations
    • AWS SSO is integrated deeply with AWS Organizations and AWS API operations, unlike other cloud native SSO solutions.
    • AWS SSO natively integrates with AWS Organizations and enumerates all your AWS accounts.
    • If have organized your accounts under organizational units (OUs) will see them displayed that way within the AWS SSO console.
    • That way quickly discover your AWS accounts, deploy common sets of permissions, and manage access from a central location.
  • SSO access to your AWS accounts and cloud applications
    • AWS SSO makes it simple for to manage SSO across all your AWS accounts, cloud applications, AWS SSO-integrated applications, and custom SAML 2.0–based applications, without custom scripts or third-party SSO solutions.
    • Use the AWS SSO console to quickly assign which users should have one-click access to only the applications that you’ve authorized for their personalized end-user portal.
  • Create and manage users and groups in AWS SSO
    1. enable the service for the first time, AWS create a default store in AWS SSO. use this store to manage users and groups directly in the console.
    2. Or connect to an existing AWS Managed Microsoft AD directory and manage users with standard Active Directory management tools provided in Windows Server.
    3. also provision users and groups from an external identity provider into AWS SSO and manage access permissions in the AWS SSO console. manage users in AWS SSO, quickly create users and then easily organize them into groups, all within the console.
  • Leverage your existing corporate identities
    • AWS SSO is integrated with Microsoft AD through the AWS Directory Service. That means your employees can sign in to your AWS SSO user portal using their corporate Active Directory credentials. To grant Active Directory users access to accounts and applications, simply add them to the appropriate Active Directory groups.
    • For example, grant the DevOps group SSO access to your production AWS accounts. Users added to the DevOps group are then granted SSO access to these AWS accounts automatically. This automation makes it easy to onboard new users and give existing users access to new accounts and applications quickly.
  • Compatible with commonly used cloud applications
    • AWS SSO supports commonly used cloud applications such as Salesforce, Box, and Office 365.
    • This cuts the time needed to set up these applications for SSO by providing application integration instructions. These instructions act as guard rails to help administrators set up and troubleshoot these SSO configurations. This eliminates the need for administrators to learn the configuration nuances of each cloud application.
  • Easy to set up and monitor usage
    • With AWS SSO, enable a highly available SSO service with just a few clicks.
    • There is no additional infrastructure to deploy or AWS account to set up. AWS SSO is a highly available and a completely secure infrastructure that scales to your needs and does not require software or hardware to manage. AWS SSO records all sign-in activity in AWS CloudTrail, giving the visibility to monitor and audit SSO activity in one place.
  • Co-exists with existing IAM users, roles, and policies
    • Enabling AWS SSO, including enabling AWS Organizations, has no impact on the users, roles, or policies that you’re already managing in IAM. continue to use your existing access management processes and tools as your organization adopts AWS SSO.
  • No-cost identity management
    • add any AWS account managed using AWS Organizations to AWS SSO. Both AWS SSO and AWS Organizations are available at no additional cost.

Getting Started

  1. AWS SSO Prerequisites
  2. Enable AWS SSO
  3. Choose Your Identity Source
  4. Set Up SSO to Your AWS Accounts
  5. Set Up SSO to Your Applications

AWS SSO Prerequisites

  1. set up the AWS Organizations service and have All features set to enabled.
  2. Sign in with the AWS Organizations master account credentials before begin setting up AWS SSO. These credentials are required to enable AWS SSO.
    1. cannot set up AWS SSO while signed in with credentials from an Organization’s member account.
  3. chosen an identity source to determine which pool of users has SSO access to the user portal.
    1. use the default AWS SSO identity source for your user store, no prerequisite tasks are required.
      1. The AWS SSO store is created by default once enable AWS SSO and is immediately ready for use.
      2. There is no cost for using this store.
    2. Connect to External Identity Provider using Azure Active Directory.
    3. connect to an existing Active Directory for your user store, must have the following:
      1. An existing AD Connector or AWS Managed Microsoft AD directory set up in AWS Directory Service, and it must reside within your organization’s master account.
        1. can connect only one AWS Managed Microsoft AD directory at a time.
        2. However, can change it to a different AWS Managed Microsoft AD directory or change it back to an AWS SSO store at any time.
      2. must set up AWS SSO in the Region where your AWS Managed Microsoft AD directory is set up.
        1. AWS SSO stores the assignment data in the same Region as the directory.
        2. To administer AWS SSO, switch to the Region where have setup AWS SSO.
        3. AWS SSO’s user portal uses the same access URL as your connected directory.
  4. If currently filter access to specific Amazon Web Service (AWS) domains or URL endpoints using a web content filtering solution such as next-generation firewalls (NGFW) or secure web gateways (SWG), must add the following domains and/or URL endpoints to web-content filtering solution allow-lists in order for AWS SSO to work properly:
    1. Specific DNS domains
      1. *.awsapps.com (https://awsapps.com/)
      2. *.signin.aws
    2. Specific URL End-points
      1. https://[yourdirectory].awsapps.com/start
      2. https://[yourdirectory].awsapps.com/login
      3. https://[yourregion].signin.aws/platform/login

Enable AWS SSO

  • Once enabled, AWS SSO creates
    • a service-linked role in all accounts within the organization in AWS Organizations.
    • creates the same service-linked role in every account that is subsequently added to your organization.
    • This role allows AWS SSO to access each account’s resources on your behalf.
  • To enable AWS SSO
    • Sign in to the AWS Management Console with your AWS Organizations master account credentials.
    • Open the AWS SSO console.
    • Choose Enable AWS SSO.
    • If have not yet set up AWS Organizations, will be prompted to create an organization. Choose Create AWS organization to complete this process.

Choose Your Identity Source

  • Choosing an identity source determines where AWS SSO looks for users and groups that need SSO access.
  • By default, get an AWS SSO store for quick and easy user management.
  • Optionally, can also connect an external identity provider or connect an AWS Managed Microsoft AD directory with your self-managed Active Directory.
  • AWS SSO provides users in this identity source with a personalized user portal from which they can easily launch multiple AWS accounts or cloud applications.
    • Users sign in to the portal using their corporate credentials or with credentials they set up in AWS SSO.
    • Once they sign in, they have one-click access to all applications and AWS accounts that have previously authorized.

identity source type

  • Manage Identities in AWS SSO
  • Connect to Your Microsoft AD Directory
  • Connect to Your External Identity Provider

Set Up SSO to Your AWS Accounts

  • grant users in your directory with SSO access to one or more AWS consoles for specific AWS accounts in your organization in AWS Organizations.
  • When do, AWS SSO uses the service-linked role that was created during enablement to create IAM roles.
  • Your end users can access their AWS accounts using these new roles.
    • Users within these accounts see only the AWS account icon (for example, Development) that they’ve been assigned from within their user portal.
    • When they choose the icon, they can then choose which IAM role they want to use when signing in to the AWS Management Console for that AWS account.

Set Up SSO to Your Applications

  • With AWS SSO, can use AWS applications that are integrated with AWS SSO, cloud-applications for which AWS provides preintegration, and custom SAML 2.0 applications.
  • application type for set up
    • Add and Configure an AWS SSO-Integrated Application
    • Add and Configure a Cloud Application
    • Add and Configure a Custom SAML 2.0 Application

Understanding Key AWS Single Sign-On Concepts

  1. Users, Groups, and Provisioning
    1. AWS SSO manages access to all your AWS Organizations accounts, AWS SSO-integrated applications, and other business applications that support the Security Assertion Markup Language (SAML) 2.0 standard.
    2. User name and email address uniqueness
      1. When working in AWS SSO, users must be uniquely identifiable.
      2. AWS SSO implements user name is the primary identifier for users.
      3. Although most people set the user name equal to a user’s email address, AWS SSO and the SAML standard do not require this.
      4. large percentage of SAML-based applications use email address as the unique identifier for users.
        1. They obtain this from assertions that a SAML identity provider sends during authentication.
        2. Such applications depend upon the uniqueness of email addresses for each user.
      5. AWS SSO allows to specify something other than an email address for user sign-in.
      6. AWS SSO requires that all user names and email addresses for your users are non-NULL and unique.
    3. Groups
      1. AWS SSO does not support adding a group to a group (nested groups).
      2. Groups are useful when assigning access to AWS accounts and applications.
        1. Rather than assign each user individually, give permissions to a group.
        2. add or remove users from a group, the user dynamically gets or loses access to accounts and applications that assigned to the group.
    4. User and group provisioning
      1. create users and groups directly in AWS SSO, or work with users and groups have in Active Directory or an external identity provider.
      2. for AWS SSO to assign users and groups for permissions in an AWS SSO account, AWS SSO must first be aware of the users and groups.
      3. Similarly, AWS SSO-integrated applications can work with users and groups for which AWS SSO is aware.
      4. Provisioning is the process of making user and group information available for use by AWS SSO and AWS SSO-integrated applications.
      5. Provisioning in AWS SSO varies based on the identity source use.
  2. User Authentications
    1. user signs in to the user portal using user name.
    2. When they do, AWS SSO redirects the request to the AWS SSO authentication service based on the directory associated with the user email address.
    3. Once authenticated, users have SSO access to any of the AWS accounts and third-party software-as-a-service (SaaS) applications that show up in the portal without additional sign-in prompts.
    4. users no longer need to keep track of multiple account credentials for the various assigned AWS applications
  3. Permission Sets
    1. a collection of administrator-defined policies
    2. AWS SSO uses it to determine user’s effective permissions to access a given AWS account.
    3. Permission sets
      1. can contain either AWS managed policies or custom policies that are stored in AWS SSO.
        1. Policies are essentially documents that act as containers for one or more permission statements.
        2. These statements represent individual access controls (allow or deny) for various tasks that determine what tasks users can or cannot perform within the AWS account.
      2. stored in AWS SSO and are only used for AWS accounts.
        1. not used to manage access to cloud applications.
      3. ultimately get created as IAM roles in a given AWS account, with trust policies that allow users to assume the role through AWS SSO.
    4. Delegating Permission Set Administration
      1. AWS SSO enables you to delegate management of permission sets and assignments in accounts by creating IAM policies that reference the Amazon Resource Names (ARNs) of AWS SSO resources.
        1. For example, create policies that enable different administrators to manage assignments in specified accounts for permission sets with specific tags.
      2. use any of the following three methods to create these kinds of policies.
        1. (Recommended) Create permission sets in AWS SSO,
          1. each with a different policy, and assign the permission sets to different users or groups.
          2. to manage administrative permissions for users that sign in using your chosen AWS SSO identity source.
        2. Create custom policies in IAM,
          1. and then attach them to IAM roles that your administrators assume.
          2. enables IAM users or IAM federated users to assume the role to get their assigned AWS SSO administrative permissions.
        3. Create custom policies in IAM,
          1. and then attach them to IAM users that you use for AWS SSO administrator purposes.
          2. to give individual IAM users specific AWS SSO administrative permissions.
    5. AWS SSO resource ARNs are case sensitive.
      1. The following shows the proper case for referencing the AWS SSO permission set and account resource types.
Resource TypesARNContext Keys
PermissionSetarn:${Partition}:sso:::permissionSet/${InstanceId}/${PermissionSetId}aws:ResourceTag/${TagKey}
Accountarn:${Partition}:sso:::account/${AccountId}Not Applicable

.

01AWS, IdenAccessManage
AWS SSO
This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.