Google Cloud Platform

Google Cloud Platform is a single destination service for managing resources used for building and deploying applications. With CyberArk as your identity service, you can choose single-sign-on (SSO) access to the Google Cloud Platform web application with IdP-initiated SAML SSO (for SSO access through the CyberArk Identity User Portal) or SP-initiated SAML SSO (for SSO access directly through the Google Cloud Platform web application) or both. Providing both methods gives you and your users maximum flexibility.

If Google Cloud Platform is the first application you are configuring for SSO through CyberArk Identity, read these topics before you get started:

Google Cloud Platform requirements

Before you configure the Google Cloud Platform web application for SSO, you need the following:

  • Your own domain registered and verified with Google Cloud Platform.
  • An active Google Cloud Platform business account with administrative privileges in Google Cloud Platform.
  • A signed certificate. You can either download one from the Admin Portal or use your organization’s trusted certificate.

Configure Google Cloud Platform 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 Optional configuration settings.

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

Step 1: Add the Google Cloud Platform 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 the partial or full application name in the Search field and click the search icon.

  3. Next to the application, click Add.
  4. In the Add Web App screen, click Yes to confirm.
  5. Click Close to exit the Application Catalog.

    The application that you just added opens to the Settings page.

Step 2: Enter the Google Cloud Platform primary domain into the Admin Portal Settings page.

  1. In your web browser, log in to the Google Admin Console using your admin account.

  2. Click Domains > Manage Domains, copy the Primary Domain and paste it into the field (Your Primary Domain in Google Cloud Platform) on the Admin Portal > Settings page.

  3. Click Save.

For additional configuration information for fields on the Settings page, see Optional configuration settings.

Step 3: Select the Trust page in the Admin Portal to access Identity Provider Configuration information.

  1. Select either Metadata or Manual Configuration to access the configuration content required in the Google Admin 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 Google Admin Console, click Security > Set up single sign-on (SSO) with a third-party IdP.`
  4. Select Set up SSO with third-party identity provider.
  5. Specify the following and then save your changes.

    Option

    Configuration

    Sign-in page URL

    If you want to do SP-initiated SSO, copy the URL from the Admin Portal Trust page into the corresponding field in the Google Admin Console. If you want IdP-initiated SSO, leave this field as is. (The CyberArk Identity automatically generates the content of this field.)

    Note: When a user goes to the Google Cloud Platform login URL, Google Cloud Platform 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 Google Cloud Platform.

    Sign-out page URL

    If you want the user to be logged out of the User Portal when they log out of Google Cloud Platform, copy the URL from the Admin Portal Trust page into the corresponding field in the Google Admin Console. Otherwise, leave this field as is. (The CyberArk Identity automatically generates the content of this field.)

    Verification certificate

    In the Google Admin Console > Security > Set up single sign-on (SSO) with a third-party IdP page, select REPLACE CERTIFICATE and then select the certificate file you downloaded from the Admin Portal Trust page.

    Use a domain specific issuer

    Do not configure this option; the CyberArk Identity doesn’t use this field.

    Network masks

    (Optional) Specify IP addresses if you want only those IP addresses to be affected by these settings.

    Change Password URL

    Enter your User Portal URL.

    Configure the Change Password URL in the Google Admin Console with the CyberArkUser Portal URL so users can change their password.

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 will automatically deploy the application to the User Portal. 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.

 

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.

    FilterDescriptionConditions available

    IP Address

    The computer’s IP address when the user logs in.

    Creating a rule based on whether the IP address is inside or outside the corporate network requires you to configure the IP address range in Settings > Network > Corporate IP Range.

    • Inside corporate IP range
    • Outside corporate IP range
    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

    Device OS

    The operating system of the device a user is logging in from.

    • equal to
    • not equal to

    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.
    • 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 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 methods. If you have not created the necessary authentication profile, select the Add New Profile option. See 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:

Google Cloud Platform provisioning

Before you configure your Google SAML application for provisioning:

  • You must install, configure, and deploy the application from the CyberArk App Catalog.

  • You need to make sure the Google application is enabled to allow API access.

    If it is the first time you are configuring the Google Cloud Platform application for provisioning, you need to enable API access, create credentials (client_id), and add those credentials to your Google application project before you can enable provisioning. For information on enabling API access, see the following documentation: https://support.google.com/cloud/answer/6158849?hl=en

To configure Google Cloud Platform in Admin Portal for automatic user provisioning

  1. Open your application and click the Provisioning page.
  2. Select Enable provisioning for this application.
  3. Select either Preview Mode or Live Mode.

    • Preview Mode: Use Preview Mode when you’re initially testing the application provisioning or making configuration changes. The identity platform does a test run to show you what changes it would make but the changes aren’t saved.
    • Live Mode: Use Live mode when you want to use application provisioning in your production system. The identity platform does the provisioning run and saves the changes to both the identity platform and the application’s account information.
  4. Click Authorize to authorize the Admin Portal to provision users to your application.

    The authorization window appears.

  5. Authorize the Admin Portal to provision users to your application.

    Once successful, the Authorization Success screen is displayed in the authorization window. The window closes automatically in a few seconds and the Provisioning page displays the Role Mappings section. The Authorize button changes to Re-authorize, indicating that users have already been provisioned to the application account or that the access token has expired and requires you to re-authorize to continue provisioning users.

Provision users for Google Cloud Platform based on roles

You can provision users to Google Cloud Platform by mapping CyberArk Identity roles to existing or new accounts in Google Cloud Platform. If you use the option to provision AD groups to Google Cloud Platform, the CyberArk Identity ignores the Destination Group setting in Role Mappings. Provisioning users into existing groups based on roles is mutually exclusive from provisioning AD groups. Refer to Provision Active Directory Groups to Google Cloud Platform for more information.

If the user accounts in the CyberArk Identity and the target application match the fields that make a Google Cloud Platform 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 provisioning script to see the fields that the CyberArk Identity uses to match user accounts.

When you change any role mappings, the CyberArk Identity synchronizes any user account or role mapping changes automatically.

To automatically provision users with Google Cloud Platform accounts

  1. In the Provisioning page, go to the Sync Options section.

  2. Specify how the CyberArk Identity handles situations when it determines that the user already has an account in the target application.

    Sync OptionDescription
    Sync (overwrite) users to target application when existing users are found with the same principal name

    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) users to target application when existing users are found with the same principal name

    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) users in target application when the users are removed from mapped role

    If this option is selected, the user account in the target application is not de-provisioned when a role membership change that triggers a de-provisioning event occurs. If this option is not selected, the user account in the target application is de-provisioned (deleted or disabled as configured in User Deprovisioning Options).

    Sync groups from local directory to target application (this option overrides any destination group selection in Role Mappings)

    Select this to synchronize local directory groups to Google application groups. Groups may be filtered via the provisioning script using the reject function (see the script example for more details). Note that if you enable this option, any specification of a destination group under role mapping is ignored. For more information, see Provision Active Directory Groups to Google Cloud Platform.

  3. In the Sync AD Groups to Google Domains list, select the Google Domains to sync to.

    Provisioned users are entered into all selected groups, and those groups are provisioned for the corresponding domains.
  4. Enable Sync user's local directory password to Google if you want users to use their local directory password to access Google applications.

    You must enable Securely capture users passwords at login in the Admin Portal > Settings > Authentication > Security Settings prior to enabling this option. Once a user is provisioned and logs in to the CyberArk User Portal, the local directory password is saved to Google. Also, see Sync local directory passwords to Google Cloud Platform.

  5. See Deprovision users in Google Cloud Platform for information on user deprovisioning options (Delete user and Disable user).

  6. Click Add, to add role mappings and specify which users get provisioned to this application.

    The Role Mapping dialog box opens.

  7. To map user accounts in Admin Portal to Google Cloud Platform user accounts, select an Admin Portal Role and (optionally) a Google Destination Organizational Unit, and then click Add.

    A destination organizational unit (OU) is used to grant access to various resources within Google Cloud Platform. A user can only be assigned to one OU at one time.

  8. Click Add to display the list of existing Destination Domains and Destination Groups (Google Groups) that you’ve already created in Google Cloud Platform.

  9. Select a Destination Domain and a Destination Group, click Add and then Done to save the role mapping and return to the Provisioning page.

    A Destination Group named for the selected CyberArk role automatically populates in the list of groups available from the drop-down list. If that Destination Group is selected, a group with that name is created in the target application. If you select a Destination Group that already exists in the application, provisioned users that are members of the selected role are added as members of the existing Destination Group.

    Alternatively, you can type in a new group name to map to the selected role; the newly created Destination Group is also created in the application.

    If the role is removed from the role mapping after a provisioning job runs, the Destination Group remains in the target application without any membership changes. Changing the role or role name does not affect Destination Group creation or membership, unless the Destination Group name in the role mapping is also changed.

    For best results, assign roles where users are only in one role.
  10. Continue adding role mappings, as desired.

    • To change a mapping, select the role mapping and click Modify.

    • To remove a mapping, select the role mapping and click Delete.

    • To change the order of the role mappings, select the role mapping that you want to move higher in the list and click Move Up.

      Provisioning assigns users access and assignments based on the top-most role mapping. The order in which the roles display in the Role Mappings section matters. The role at the top of the list has priority when provisioning users. For instance, if a user is in multiple roles that you’ve mapped for provisioning, the CyberArk Identity provisions the user based on the role nearer the top of the list.
      For best results, assign roles where users are only in one role. If users are in multiple roles, rearrange the order of role mappings as desired.
      For more details, see Set up app-specific provisioning.
      The provisioning script is intended for advanced users who are familiar with editing server-side JavaScript code. The Google Cloud Platform provisioning script supports the system attributes that are listed in the Destination folder in the Script Help section of the Provisioning Script Editor.
  11. Click Save to save the provisioning details.

    Any time you make changes to the provisioning role mapping, the CyberArk Identity runs a synchronization automatically. You can also run a preview synchronization or a real synchronization, if desired.

Provision Active Directory Groups to Google Cloud Platform

If your users are already organized into AD groups, it might be more efficient to provision AD groups to Google Cloud Platform rather than creating the groups individually in the application. You can then update Google Cloud Platform group using Role Mappings to provision the group members. Provisioning an AD group and its members to Google Cloud Platform consists of the following steps, which can be performed in any order.

  • Provision AD groups to Google Cloud Platform using the Sync groups from local directory to target application option.

    If there are any AD groups you wish to exclude from provisioning, you can do so with the Provisioning Script. Any members of the group that have not already been provisioned through role mapping are listed in the dirsync report.

  • Provision members of the AD group to Google Cloud Platform using Role Mapping. Refer to Provision users for Google Cloud Platform based on roles for more information.

If you have Sync groups from local directory to target application enabled, the Destination Group setting in Role Mappings is ignored and users are provisioned into the synced AD groups.

Note the following about provisioning AD groups to Google Cloud Platform:

  • Provisioning nested groups is supported.

  • If an AD group has the same email address as an existing Google Cloud Platform group, the CyberArk Identity recognizes the same email address in the existing group during provisioning and updates it with the AD group attributes.

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

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

    To provision AD groups to Google Cloud Platform, you need to deploy a new application in Admin Portal; the feature is not backwards compatible with previously deployed applications.

Provision additional user and group attributes to Google Cloud Platform

You can use the following destination attributes to better define users and groups that are provisioned to Google Cloud Platform. You can use these attributes to set the group owner, alias, and manager.

Destination AttributeDescription
destination.HomeEmaildestination.HomeEmail = source.Email;

destination.CustomEmail

destination.CustomEmail = source.CanonicalizeName;

destination.WorkEmail

destination.WorkEmail = source.Get("sAMAccountName") + "@example.com";
destination.Aliasesdestination.Aliases = [ name + '@' + GoogleDomain ];
destination.Members
destination.Members = [ 'user1@example.com', 'user2@example.com' ]; // members as MEMBER role

or

destination.Members =  [

{ Email: 'user1@example.com', Role: 'MEMBER }
,

{ Email: 'user2@example.com', Role: 'OWNER' }
,

{ Email: 'user3@example.com', Role: 'MANAGER' }
];

Sync local directory passwords to Google Cloud Platform

You can sync local directory user passwords to Google Cloud Platform as an alternative to SSO. For example, you might want desktop users to use SSO, while mobile users use their local directory passwords to access Google Cloud Platform.

To sync Active Directory passwords to Google Cloud Platform

  1. Enable Securely capture users passwords at login in Admin Portal > Settings > Security Settings, then click Save.

    Users must log in to the CyberArk Identity User Portal after this setting is enabled for the CyberArk Identity to capture the password. This is necessary to sync the password to Google Cloud Platform. In addition, if the user’s password changes, the user must log in to the CyberArk Identity User Portal once for the CyberArk Identity to capture the new password.

  2. Open the Google Cloud Platform SAML application in Admin Portal.

  3. Click the Provisioning tab.

  4. Enable Sync user's local directory password to Google, then click Save.

  5. Verify that all users that you want to sync local directory passwords for are members of a role listed in the Role Mapping table.

    Refer to Provision users for Google Cloud Platform based on roles for more detail.

  6. Start a sync job for the Google Cloud Platform appliction. Refer to Provisioned account synchronization options for more detail.

    Remember that users have to log in to the CyberArk Identity User Portal once before you can successfully sync local directory passwords. In addition, if the user’s password changes, the user must log in to the CyberArk Identity User Portal once for the CyberArk Identity to capture the new password. New or changed passwords are synced to Google Cloud Platform during the daily sync or a manual sync; passwords are not automatically synced the first time a user logs in.
  7. (Optional) In the Google Admin console, go to Security > Set up single sign-on (SSO) to configure Network masks if you only want certain users to continue using SSO.

    Users with an IP address in the range specified for the Network masks can continue using SSO, while users with IP addresses not in the range of the Network masks must use a password-based login. For example, you can use the Network masks to allow desktop users to use SSO and mobile users to use a password-based login.

Deprovision users in Google Cloud Platform

There are two options available on how to handle deprovisioned user accounts in Google Cloud Platform:

  • Disable user (deactivates the user)

  • Delete user (removes the user account)

These settings determine how deprovisioned users are handled in the Google Cloud Platform application when they are removed from a role mapping in the Admin Portal or deprovisioned in asource directory, such as Active Directory.

Deprovisioning groups is not supported.

Google Cloud Platform users removed from a role mapping

Users removed from CyberArk Identity roles that are mapped to Google Organizational Units or Groups, can be disabled or deleted in Google Cloud Platform.

Make sure Do not de-provision (deactivate or delete) users in target application when the users are removed from mapped role is not selected in the Sync options.

To disable or delete Google Cloud Platform user accounts removed from a role mapping

  1. Update the role membership for Google Cloud Platform mapped roles.

  2. Open the Google Cloud Platform SAML application in the Admin Portal.

  3. Click the Provisioning tab.

  4. Select Disable user or Delete user from User Deprovisioning Options.

  5. Click Save.

If Do not de-provision (deactivate or delete) users in target application when the users are removed from mapped role is selected in the Sync options, users removed from a mapped role are not deprovisioned in the Google Cloud Platform application.

Google Cloud Platform users deprovisioned in source directory

When a user is disabled in a source directory, such as Active Directory, a deprovisioning job is activated to disable or delete the user in the application.

To disable or delete Google Cloud Platform user accounts deprovisioned in the source directory

  1. Open the Google Cloud Platform SAML application in the Admin Portal.

  2. Click the Provisioning tab.

  3. Select Deprovision (deactivate or delete) users in this application when they are disabled in the source directory.

  4. Select Disable user or Delete user from User Deprovisioning Options.

  5. Click Save.