AWS IAM SAML Single Sign-On (SSO)

This topic provides instructions on how to deploy Amazon Web Services (AWS) to your users for single sign-on (SSO) via SAML from the User Portal. The CyberArk SSO integration works by enabling CyberArk-federated users to assume designated AWS roles. An AWS role is an Identity and Access Management (IAM) identity that has specific permissions and can be assumed by anyone who needs it. AWS IAM roles are not associated with specific users and do not have long-term credentials such as passwords or access keys. The intent of an AWS role is to provide temporary security credentials for the role session.

You can create an AWS IAM role for each set of permissions that you want to make available to your federated users. For example, you might have users who need access to just EC2, and other users who need access to just S3. In that case, create two separate AWS IAM roles with appropriate permissions policies attached. Next, create the Admin Portal roles with the same names as the AWS IAM roles, and populate the roles' members list with the desired federated users.

Once you have deployed the AWS application to the Admin Portal roles matching the AWS IAM roles, federated users who are members of those roles can launch the AWS console from their User Portal and will have access as defined by the permissions policy attached to the AWS IAM role.

If you have different subscriptions available in different AWS accounts, create a new AWS application in the Admin Portal for each AWS account.

Refer to Amazon's documentation for more information about AWS IAM terminology and concepts.

If you’re trying to configure the Amazon Web Services for SSO and provisioning using Amazon's proprietary authentication method, refer to Amazon Web Services (AWS) Amazon Specific Single Sign-On (SSO).

Amazon Web Services (SAML) requirements for SSO

Before you configure the Amazon Web Services (AWS) web application for SSO, you need an active Amazon Web Services account root user.

Configure Amazon Web Services (SAML) in the Admin Portal

To add and configure the Amazon Web Services (SAML + Provisioning) application in the Admin Portal

  1. Open a new tab in your web browser, then go to the AWS Management Console and sign in with a root user:

    https://console.aws.amazon.com

  2. Enter your AWS Account ID (root account) on the Admin Portal Settings tab.

    You can find your AWS Account ID by logging in to the management console with a root user, then click <Username> > My Account. The Account id is shown under Account Settings.

  3. In the AWS management console, under Security, Identity, & Compliance, click IAM.

  4. Click Identity providers.

  5. Click the Create Provider button, and choose SAML as the provider type from the drop-down list.
  6. Enter CyberArk as the Provider Name.
  7. On the Trust page in the Admin Portal, find the Identity Provider Configuration > Metadata section and click Download Metadata File.

    If you are using your own certificate, you must upload it before downloading the SAML metadata.

  8. On the AWS management console, click Upload metadata, then click Choose File and select the XML file you just downloaded.
  9. Click Next Step, and verify the provider information, then click Create.
  10. Click Do this now in the information box at the top of the page to create an Identity and Access Management (IAM) role using this provider in the role’s trust policy.

  11. Click Create Role.

    Refer to https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html for more information about using AWS roles to permit SAML 2.0 federated users access to the AWS Management Console.

  12. Click SAML for the type of trusted entity.

  13. Select the provider you just created from the SAML provider drop-down list.
  14. Select Allow programmatic and AWS Management Console access.
  15. Click Next: Permissions.
  16. Select the check box for the policy you want to assign to this role.

    You may need to use the search box to locate your policy name.

    Refer to https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html for more information about AWS policies.

  17. Click Next: Tags, then optionally enter tags (key-value pairs) to help you organize, track, or control access to the role.
  18. Click Next: Review., then enter a Role name and optionally, a Role description..

    Note the role name; you will have to create a matching role in the Admin Portal.

  19. Click Create Role.

    You can create additional roles using SAML as the trusted entity for different sets of permissions. For example, you might have users who need access to just EC2, and other users who need access to just S3. In that case, create two separate roles with appropriate permissions policies attached.

  20. Create matching roles in the Admin Portal.

    The roles in the Admin Portal must match the names of the AWS IAM roles exactly.

    1. In the Admin Portal, click Core Services, then right-click Roles and select Open Link in New Tab.
    2. Click Add Role.
    3. Type the role name and an optional description.

      Remember to exactly match the role names in AWS that you want users to have access to.
    4. Click Members > Add to add users to the role.

      Add the users that you want to have access to the matching AWS IAM role permissions. For example, if you are creating a role named AWS-EC2 to match an AWS IAM role of the same name, add the users that need access to AWS EC2.

  21. Deploy the application by assigning it to the newly created roles.

    1. Click Assigned Applications, then click Add.
    2. Select the check box associated with each application you want to assign, then click Add.

    3. Click Save.
  22. Repeat the process of creating matching role names, adding members, and assigning the AWS application as needed.

    This completes the required steps to deploy AWS to your users. Members of the roles created previously can log in to their User Portal and launch the AWS management console. If the users have access to multiple AWS IAM roles, they can select the role they want to use when they sign in.

    Users can verify the AWS IAM role by clicking their username in the AWS management console; the drop-down menu shows:

    Federated Login
    <role>/<userEmail>

  23. (Optional) Add linked applications.

    Amazon Web Services (SAML) has a number of pre-formatted linked apps that can be linked to it. Linked apps inherit permissions from the parent app by default. You can further refine permissions within the linked app. For example, you could deploy AWS to users in roles named Marketing, Sales, and ProductManagement. You can then add linked applications AWS EC2 and AWS S3 and set permissions on the linked apps so only the Marketing role gets AWS S3 while Sales and ProductManagement get AWS EC2.

    See Add or delete linked applications for details.

  24. Click Save in AWS application configuration the Admin Portal browser tab.

Amazon Web Services provisioning

Provisioning automatically adds or removes user accounts in AWS by syncing attributes from the source directory. Whenever you make changes to a mapped role or a source directory object in a mapped role (i.e., users or groups), CyberArk Identity automatically synchronizes the changes in AWS.

Provisioning is based on roles; users and groups must be members of a mapped role to have accounts provisioned in AWS. You can't provision individual users that are not members of a role.

CyberArk Identity can synchronize user accounts from Active Directory, LDAP, the CyberArk Cloud Directory, or any combination of those sources.

AWS provisioning maps CyberArk roles to AWS groups; members of the CyberArk roles have matching IAM users created or deleted in destination AWS groups. You can map CyberArk roles to an existing AWS group, or you can create a new AWS group based on either the CyberArk role name or a string that you manually enter.

Source directory users must have a valid email address for the CyberArk Identity to successfully provision them to Amazon Web Services.

Before you begin, complete the steps in Configure Amazon Web Services (SAML) in the Admin Portal
  1. Under Sync Options, specify how the CyberArk Identity handles situations when it determines that the user already has an account in the target application.

    How the CyberArk Identity determines duplicate user accounts:

    If the user accounts in the CyberArk Identity and the target application match for the fields that make an Amazon Web Services user unique, then the CyberArk Identity handles the user account updates according to your instructions. In many applications, the user’s email address or Active Directory userPrincipalName is the primary field used to identify a user—and in many cases, the userPrincipalName is the email address. You can look at the application’s provisioning script to see the fields that CyberArk Identity uses to match user accounts.

    • Sync (overwrite): Updates account information in the target application (this includes removing data if the target account has a value for a user attribute that is not available from the CyberArk Identity).
    • Do not sync (no overwrite): Keeps the target user account as it is; CyberArk Identity skips and does not update duplicate user accounts in the target application.
    • Do not de-provision (deactivate or delete): The user's account in the target application is not de-provisioned when a role membership change that would trigger a de-provisioning event occurs.
    • Select Deprovision users in this application when they are disabled in source directory to enable the feature.

      If checked, a user will be deprovisioned when they are marked as disabled in the source directory. Deprovisioning behavior and available deprovisioning options depend on what the target application supports.

CyberArk Amazon Web Services CLI utilities

CyberArk offers Python and PowerShell CLI utilities to access Amazon Web Services by leveraging CyberArk Identity. The AWS CLI utilities are available from the Downloads area of the Admin Portal.

Refer to The CyberArk Developer Program for more information about how to install and use the AWS CLI utilities.

AWS (SAML) Specifications

Each SAML application is different. The following table lists features and functionality specific to Amazon Web Services.

Capability

Supported?

Support details

Web browser client

Yes

 

Mobile client

Yes

iOS and Android

SAML 2.0

Yes

 

SP-initiated SSO

No

 

IdP-initiated SSO

Yes

 

Force user login via SSO only

No

After SSO is enabled, users can continue to log in to Amazon Web Services with their local user name and password.

Separate administrator login
after SSO is enabled

Yes

After SSO is enabled, administrators can continue to log in to Amazon Web Services with their local user name and password.

User lockout

No

 

Administrator lockout

No

 

User provisioning through SAML

Yes

 

Multiple User Types

Yes

Refer to Amazon Web Services documentation for details.

Self-service password

Yes

Users can reset their own passwords. Note that administrators cannot reset a user’s password.

Access restriction using a corporate IP range

Yes

You can specify an IP Range in the Admin Portal Policy page to restrict access to the application.