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 Identity Administration 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 Identity Administration 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 Identity Administration 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 Identity Administration portal

To add and configure the Amazon Web Services (SAML + Provisioning) application in the Identity Administration portal

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

  2. Enter your AWS Account ID (root account) on the Identity Administration 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 Identity Administration 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 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 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 Identity Administration 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 Identity Administration portal.

    The roles in the Identity Administration portal must match the names of the AWS IAM roles exactly.

    1. In the Identity Administration 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

  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 Identity Administration 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 CyberArk Identity to successfully provision them to Amazon Web Services.

  1. Under Sync Options, specify how CyberArk Identity handles situations when it determines that the user already has an account in the target application.

    How CyberArk Identity determines duplicate user accounts:

    If the user accounts in CyberArk Identity and the target application match for the fields that make an Amazon Web Services user unique, then 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 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 Identity Administration 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.



Support details

Web browser client



Mobile client


iOS and Android

SAML 2.0



SP-initiated SSO



IdP-initiated SSO



Force user login via SSO only


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


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

User lockout



Administrator lockout



User provisioning through SAML



Multiple User Types


Refer to Amazon Web Services documentation for details.

Self-service password


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

Access restriction using a corporate IP range


You can specify an IP Range in the Identity Administration portal Policy page to restrict access to the application.