AWS Single Sign-On SAML Single Sign-On (SSO)

AWS Single Sign-On (AWS SSO) is a cloud service provided by Amazon that allows you to grant user access to AWS resources, such as Amazon EC2 instances, across multiple AWS accounts. AWS Single Sign-On centralizes the administration of users and permission sets across multiple AWS accounts using the concept of AWS organizations. This enables administrators to establish federation with an identity provider once and manage access to AWS.

CyberArk integrates with AWS Single Sign-On as an identity provider for AWS, automatically provisioning users and groups, and providing simplified, secure user access to authorized AWS accounts and resources.

This topic provides instructions on how to configure SSO and provisioning to the AWS Single Sign-On application. If AWS is the first application you are configuring for SSO through CyberArk Identity, read these topics before you get started:

AWS Single Sign-On requirements

Before you configure the AWS Single Sign-On application for SSO, you need the following:

  • An AWS Organizations management account.
  • The AWS Organization Service set up.

    See the following link for AWS SSO prerequisites and information on how to set up AWS organizations: https://docs.aws.amazon.com/singlesignon/latest/userguide/prereqs.html

  • A signed certificate. You can either download one from the Admin Portal or use your organization’s trusted certificate.

Configure AWS for SSO

The following steps are specific to this application and are required in order to enable SSO. For information on optional configuration settings available in the Admin Portal, see Configure optional application settings.

During the following procedures, it is helpful to open the Admin Portal and the AWS Management Console simultaneously to copy and paste settings between the two browser windows.

Step 1: Add the AWS Single Sign-On application in the Admin Portal.

  1. In the Admin Portal, select Apps > Web Apps, then click Add Web Apps.

    The Add Web Apps screen appears.

  2. On the Search tab, enter AWS Single Sign-On (SSO) in the Search field and click the search icon.

  3. Next to AWS Single Sign-On (SSO), click Add.

  4. In the Add Web App screen, click Yes to confirm.

  5. Click Close to exit the Application Catalog.

    The AWS Single Sign-On (SSO) application opens to the Settings page.

Step 2: Access the AWS Management Console Single Sign-On page to enable an external identity provider.

  1. Open a new tab in your web browser, then go to the AWS Management Console and sign in using your AWS Organizations management account.
  2. Under Security, Identity, & Compliance, click AWS Single Sign-On.
  3. At the Enable AWS Single Sign-On (SSO) page, click Enable SSO.
  4. Click Settings, and then click Change next to Identity Source.
  5. Under Choose where your identities are sourced, click External identity provider.

Step 3: Select the Trust page in the Admin Portal to configure Identity Provider and Service Provider information.

  1. Click the Trust page in the Admin Portal, and then select Manual Configuration in the Identity Provider Configuration area to access the configuration content required in the AWS Management Console.

  2. In the Identity Provider Configuration area of the Trust page, expand the certificate area and select the certificate that you want to use for the application, then click Download.

  3. In the AWS Management Console, navigate to the Identity provider metadata section, and then select the link, If you don't have a metadata file, you can manually type your metadata values. The following screen appears.

  4. Next to IdP certificate*, click Browse and then select the file you downloaded from the Admin Portal.
  5. Configure the following additional identity provider fields:

    Admin PortalOption

    Configuration

    Single Sign on URL

    Copy the URL from the Admin Portal Trust page into the IdP sign-in URL field in the AWS Management Console. (The CyberArk Identity generates the content for this field.)

    Note: When a user goes to the AWS URL, AWS has the CyberArk Identity authenticate the user. If the user isn’t already logged in to the User Portal, then the CyberArk Identity prompts the user to log in. If the user is already logged in to the User Portal, then the CyberArk Identity authenticates the user and logs the user in to AWS.

    IdP Entity ID / IdP Issuer

    Copy the URL from the Admin Portal Trust page into the corresponding field in the into the IdP sign-in URL field in the AWS Management Console. (The CyberArk Identity automatically generates the content for this field.)

  6. In the AWS Management Console, navigate to the Service provider metadata section, and click Download metadata file.`
  7. In the Admin Portal Service Provider Configuration area, select Metadata > Choose File and then select the file you downloaded from the AWS Management Console.

  8. In the Admin Portal, click Save.
  9. In the AWS Management Console, click Next: Review and review your changes, enter CONFIRM and then click Finish.

    SP-initiated SSO: Users can access the AWS Single Sign-On application directly and authenticate with the CyberArk Identity using the User portal URL link in the AWS Management Console > Security, Identity, & Compliance > AWS Single Sign-On > Settings page.

Step 4: Set permissions or add the application to a set to deploy the application to users.

  1. On the Permissions page, click Add.

    The Select User, Group, or Role window appears.

  2. Select the user(s), group(s), or role(s) that you want to give permissions to, then click Add.

    The added object appears on the Permissions page with View, Run, and Automatically Deploy permissions selected by default.

  3. Select the desired permissions, then click Save.

    Default permissions automatically deploy the application to the User Portal if the Show in user app list option is selected on the Settings page. Change the permissions if you want to add additional control or you prefer not to automatically deploy the application.

    Refer to the following table for more information about applications-specific permissions.

    Permission

    Description

    Manage

    Users can modify application settings and application sets. Selecting this option also selects the View permission.

    Additionally, a user in a role with the Application Management administrative right can enable this permission to allow other users or roles (without the Application Management right) to administer the application. See Delegate application management for more information.

    Note that you cannot delete applications from the Admin Portal > Web Apps and Mobile Apps pages with just this permission. Add the Delete permission if you want a delegated application administrator to have the ability to delete applications.

    Delete

    Users with this permission can delete applications from the Admin Portal > Web Apps and Mobile Apps pages. Selecting this option also selects the View permission.

    Run

    Allows users to launch the application from the User Portal.

    Automatically Deploy

    Automatically deploys the application to the User Portal. If Automatically Deploy is not selected, users can find the application in the Recommended tab when adding applications to the User Portal.

    The Show in user app list option takes priority over the Automatically Deploy permission. For example, if Show in user app list is not selected, applications do not appear in the User Portal or in the Recommended tab even if you select the Automatically Deploy permission.

    The following video contains more information about deploying apps as Recommended.

Watch the video!

Step 5: On the Policy page, specify MFA policies you want to enforce before users can access this application.

  1. (Optional) Click Add Rule to specify conditional access.

    The Authentication Rule window appears.

  2. Click Add Filter on the Authentication Rule window.

  3. Define the filter and condition using the drop-down menus.

    Filter Description Conditions available

    IP Address

    The computer’s IP address when the user logs in. You can create rules based on:

    • Whether the IP address is inside or outside the corporate network.

      Use either the inside secure zone or outside secure zone condition. Secure Zones are defined in Settings > Network > Secure Zones.

    • Whether the IP address is inside a subset of your corporate network.

      Use the inside secure zone... condition. If you select this condition, you also need to indicate the specific Secure Zone (IP range configured in the IP table in Settings > Network > Secure Zones).

    To configure the IP address condition, you first need to configure the IP address range in Settings > Network > Secure Zones. See Define Secure Zones. The specified authentication profile is then applied to users whose IP address matches the specified IP address value, or falls within the specified IP address range.

    Also see Disable Secure Zones to exempt certain IP addresses or ranges from policy rules.

    • inside secure zones
    • outside secure zones
    • inside secure zone...
    Identity Cookie

    The cookie that is embedded in the current browser by CyberArk Identity after the user has successfully logged in

    • Is present
    • Is not present

    Day of Week

    Specific days of the week (Sunday through Saturday). You can select one or more, based on either User Local Time or UTC.

    Authentication filters for RADIUS connections only use UTC.

    Checkboxes for each day of the week and radio buttons to select either User Local Time or UTC

    Date

    A date before or after which the user logs in that triggers the specified authentication requirement, based on either User Local Time or UTC.

    Authentication filters for RADIUS connections only use UTC.
    • Less than <selected date>
    • Greater than <selected date>

    User Local Time or UTC

    Date Range

    A specific date range, based on either User Local Time or UTC.

    Authentication filters for RADIUS connections only use UTC.

    Date pickers and radio buttons for User Local Time or UTC

    Time Range

    A specific time range in hours and minutes, based on either User Local Time or UTC .

    Authentication filters for RADIUS connections only use UTC.

    Strings representing time ranges in the format hh:mm, with radio buttons for User Local Time or UTC

    Network Level Authentication

    This filter is used to apply authentication profiles based on whether an RDP client has completed Network Level Authenticaton ("NLA").

    • is done

    • is not done

    Browser

    The browser used for opening the CyberArk Identity portal.

    • equal to
    • not equal to

    Role

    CyberArk Identity roles that a user belongs to. If a user belongs to multiple roles, the authentication rule that comes first (highest priority on top) is honored.

    If a role is renamed following the creation of an authentication rule using Role as a filter, the authentication rule will automatically update with the new role name. If a role is deleted, the portion of the any authentication rule using that role as a filter will also be deleted.

    This filter is only applicable to managing web application access.

    • equal to
    • not equal to

    Country

    The country based on the IP address of the user computer.

    • equal to
    • not equal to

    Risk Level

    Risk Level: The authentication factor is the risk level of the user logging on to user portal. For example, a user attempting to log in to CyberArk Identity from an unfamiliar location can be prompted to enter a password and text message (SMS) confirmation code because the external firewall condition correlates with a medium risk level. This Risk Level filter, requires additional licenses. If you do not see this filter, contact CyberArk support. The supported risk level are:

    • Non Detected -- No unexpected activities are detected.
    • Low -- Some aspects of the requested identity activity are unexpected. Remediation action or simple warning notification can be raised depending on the policy setup.
    • Medium -- Many aspects of the requested identity activity are unexpected. Remediation action or simple warning notification can be raised depending on the policy setup.
    • High -- Strong indicators that the requested identity activity is anomaly and the user's identity has been compromised. Immediate remediation action, such as MFA, should be enforced.
    • Undetermined -- Not enough user behavior activities (frequency of system use by the user and length of time user has been in the system) have been collected.

    The following video illustrates how to create an authentication rule based on risk level.

    • equal to
    • not equal to

    Managed Devices

    A device is considered “managed” if it is enrolled in CyberArk Identity and you use CyberArk Identity for device management. A device that is enrolled for only single sign-on or endpoint authentication is not considered a managed device. For more information about the difference, refer to Mobile Device Management or single sign-on only.

    The Windows Cloud Agent does not include device management features. Enrolled Windows machines are not considered managed devices.

    This filter is only applicable to managing web application access.

    • True
    • False

    Certificate Authentication

    Whether or not you use a digital certificate issued by your organization’s trusted certificate authority. You can upload a certificate using the Admin Portal > Settings > Authentication > Certificate Authorities. Users can also individually use CyberArk as their trusted certificate authority and automatically install the digital certificate by enrolling their devices.

    For example, if you configure an authentication rule to use the Certificate Authentication condition, then CyberArk Identity checks for a digital certificate issued by a trusted certificate authority and enforces the specified authentication profile before allowing access to this application.

    CyberArk support must enable the Certificate Authentication filter for your company.
    • is used
    • is not used
  4. Click the Add button associated with the filter and condition.

  5. Select the profile that you want applied if all filters/conditions are met in the Authentication Profile drop-down, then click OK.

    The authentication profile is where you define the authentication mechanisms. If you have not created the necessary authentication profile, select the Add New Profile option. See Create authentication profiles.

  6. (Optional) In the Default Profile (used if no conditions matched) drop-down, you can select a default profile to be applied if a user does not match any of the configured conditions.

  7. If you have no authentication rules configured and you select Not Allowed in the Default Profile drop-down, users will not be able to log in to the service.

  8. (Optional) If you have more than one authentication rule, you can drag and drop the rules to a new position in the list to control the order they are applied.

Step 6: The required configuration to deploy the application is complete. See the following to configure optional settings:

Reduce excessive cloud IAM permissions

Implement CyberArk Cloud Entitlements Manager to detect excessive permissions and generate recommendations to remediate risky access on your cloud platform. Only risky permissions are removed, resulting in least privilege for all human and machine identities while maintaining valid access for Cloud and DevOps teams.

AWS Single Sign-On provisioning

SCIM (System for Cross-domain Identity Management) is an open standard for automating the exchange of user identity information between identity domains, or IT systems. It can be used to automatically provision and deprovision accounts for users in external systems such as your custom SAML app. For more information about SCIM, see www.simplecloud.info.

To initiate SCIM provisioning for your AWS Single Sign-On application, copy the following from the AWS Management Console > AWS Single Sign-On > Settings > Provisioning page and paste the data into fields in the Admin Portal > Provisioning page.

AWS Management Console data

the Admin Portal

SCIM endpoint SCIM Service URL
Access token Bearer token

For more information about provisioning your app, see the following:

Provisioning to AWS SSO requires the SCIM payload to include mandatory attributes and also has certain restrictions. For instance, AWS SSO only supports one phone number, and a SCIM payload with more than one phone number will result in a provisioning error. The provisioning script available in the AWS SSO template is certified by AWS and is recommended to use as-is. Refer to Provision accounts with SCIM for more information.

Provision all Active Directory groups to AWS

If you already organized your users into AD groups, it might be more efficient to provision AD groups to the application rather than creating the groups individually in the application.

  • If an AD group has the same name as an existing group , CyberArk Identity recognizes the same name in the existing group during provisioning and updates it with the AD group’s attributes.

  • If you use the option to provision AD groups, the CyberArk Identity ignores the Destination Group setting in Role Mappings. Provisioning AD groups and provisioning users to existing groups using role mapping are mutually exclusive.

  • You can not deprovision the groups by disabling or deleting them in Active Directory.

  • If you want to provision AD groups, you need to deploy a new application in the Admin Portal; the feature is not backwards compatible with previously deployed applications.

To provision AD groups

  1. Open the SAML application in the Admin Portal.

  2. Click the Provisioning tab.

  3. Select Sync groups from local directory to target application, then click Save.

    When you start the provisioning job, CyberArk Identity provisions all AD groups to the application.

    This option overrides the Destination Group setting in Role Mappings.
  4. Add roles to Role Mappings as necessary, then click Save.

    There is no need to specify Destination Groups, since this settings is ignored in favor of AD groups when Sync groups from local directory to target application is selected.

    All users that belong to your AD groups should also belong to a role in Role Mappings. In addition, an email address is required for all users that you want to provision.

  5. (Optional) Filter any AD groups that you do not want to provision using the provisioning script reject() method.

    Directions and an example script are provided in the Provisioning Script box. Uncomment and modify the script as necessary.

  6. Manually sync the AD objects.

    Refer to Provisioned account synchronization options for more detail.

    The CyberArk Identity provisions all AD groups not filtered by the reject() method to the application. Any user objects in a mapped role are synced to a destination group in the application that matches the object’s AD group (the Destination Group setting in Role Mappings is ignored).

To skip provisioning for specific groups

If you want to provision seven out of the 10 groups and skip provisioning for three groups, use the following script:

 
#//Rejecting distribution groups
var groupTypes = getSourcePropertyByName("groupType");
if (groupTypes && groupTypes.Length) {
var groupType = String(groupTypes[0])
if (groupType>0)
{ reject(destination.DisplayName+"groupType=distribution, is rejected"); }
}
//Rejecting a specific ou group
var dnArray = getSourcePropertyByName("distinguishedname");
if (dnArray && dnArray.Length) {
var dn = String(dnArray[0]).toLowerCase();
if (dn.indexOf("test_reject") >= 0)
{ reject("ou=test_reject, is rejected"); }

Integrate AWS CLI with AWS Single Sign-On

For information on how to configure the AWS CLI to use AWS Single Sign-on, see the following:

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html