Preparing for SaaS application data protection

Before you start protecting your Okta WIC data, complete the following steps:

Getting familiar with your SaaS application specifics

Before you start protecting your Okta WIC data, you must get familiar with all prerequisites, limitations, considerations, and/or recommendations in this topic to make sure that your environment is prepared and configured correctly.

Prerequisites

  • Okta user or service account must be granted admin privileges.

  • The API token for the Okta account is required.

  • The organization URL of your Okta tenant is required.

    Example  Organization URLs:
    https://companyname.okta.com
    https://companyname.oktapreview.com
    https://companyname.okta-emea.com

Limitations

  • The created or modified timestamps are not preserved during the restore. The timestamps are recreated.

  • The object IDs are changed during the restore since they are recreated.

  • Setting up automatic policy assignment with labels or tags is not supported.

  • For the Okta Classic engine subscription: The Okta application sign-on policy rules are not preserved during the restore.

  • The application visibility options are not restored if the OIDC is used as the Single Sign-On and Authentication (SSO) option.

  • You can restore Okta WIC data to a different source only at the Organization level.

  • For the OIDC applications, the following cannot be restored:

    • The customized Application Rate Limits value

    • The Groups claim type and Groups claim filter fields

    • The Callback URI field

  • The Provisioning checkbox and Assertion Encryption fields of the SAML_2.0 type applications cannot be restored.

  • Okta allows deleting a group even if the group is linked to the global session policy. If the global session policy is not linked to any of the backed-up groups, the restore of such global session policy will fail.

  • Due to the Okta API limitation, if the SAML 2.0 Identity Provider (IdP) settings have the IdP Usage parameter set as Factor only, the parameter will be restored as SSO Only. The SSO Only value must be updated to Factor only after the restore. All the other SAML 2.0 IdP parameters will be restored as they are.

  • For the application restore (due to the Okta API limitations and/or design):

    • The Okta admin console session values cannot be protected.

    • The SAML signing certificates cannot be restored. Okta generates these certificates by default when an application is created.

    • While creating and updating an application with a shared username and password, the password will be updated to defaultPassword.

    • The application settings cannot be restored if an application is inactive.

    • The custom admin roles will not be restored during the Application Granular restore. They will be restored only if you perform the Organization or Resource Set/Role Granular restore.

    • For the SAML 2.0 applications created via the Create App Integration:

      • The applications that have the signature certificate uploaded, but do not have the SP Issuer property set, will be restored with the default value for the SP Issuer property (Hycu-R-Cloud).

      • To enable the restore, at least one of the SAML assertions or responses must be signed.

    • While backing up certain OIN applications that are created by using the browse app catalog, Okta does not provide the parameters that are required for a successful restore. These applications cannot be restored.

    • Okta does not provide certain required properties when responding to the GET calls for the OIN applications. To ensure a successful restore, the following is done by the module during the restore procedure:

      • For the SGNL applications: The clientName property is set to Hycu-R-Cloud.

      • For the Axiad applications: The tenantName, tenantPlatform, acsUrl, and audienceUri properties are set to Hycu-R-Cloud.

  • For the role restore:

    • Due to the Okta API limitation, the standard admin roles including their assignments cannot be protected.

    • The permissions for the roles will only be added and not replaced during the update.

  • For the policy and the policy rule restore (due to the Okta API limitations and/or design):

    • If the authenticators are not configured, the restore of the policy and the policy rule will be completed with the following error:

    This rule uses authenticators that have not been set up for your org. Please add at least one of the following authenticators in order to activate this rule: Custom App Authenticator, Email, Google Authenticator, IdP Authenticator, Okta Verify, On-Prem MFA, Phone, RSA SecurID, Security Key or Biometric, Symantec VIP, YubiKey Authenticator.

  • The policies and the policy rules that were deleted after the backup will not be inserted according to their backup priority but will be created towards the end of the priority list--just before the default policy or the default policy rule.

  • During the restore, the authenticators for the MFA_ENROLL policies that were not configured in the restore account will be skipped. If these authenticators are not skipped, Okta will report the following error: Not one of the allowed values.

  • If the policy or the policy rule is deleted after the backup and recreated with same name, it will not be updated during the restore.

  • For applications like Microsoft 365, for which application-specific authentication policies get added with the same name during application integration, the following error can be expected during the Organization/Policy restore:

      Policy name already in use.

  • For the group restore:

    • The inactive applications cannot be assigned to the groups. As a result, the restore will be completed as DONE_WITH_WARNINGS due to Okta design.

    • The users assigned by using the group rules will not get mapped at the group level restore. These users will be mapped during the Group Rule restore.

    • If the associated groups that are linked to the policies are deleted after the backup, the policies remain valid. However, without the association with the groups, the module will not be able to update or create such policies.

    • If the custom attributes are not present in the destination account, they will not be updated or created during the restore.

  • For the group rule restore: Okta does not support updating the assignUserToGroups.groupIds section of the actions object in a group rule.

  • For the resource set restore:

    • The module does not support protecting the auth-server. As a result, only the existing auth-servers will be added as a resource during the restore.

    • The users, the apps, the groups or the auth-servers for a given resource set during the restore will be added. They will not be replaced.

  • For the network zone restore: The Legacy IP Zone is the default zone. If the gateways and the proxies are blank (default) during the backup, the restore will be completed as DONE_WITH_WARNINGS because of the Okta API limitation.

  • For the UI schema restore: The user attributes that are present in an Okta source during the UI schema restore will only be created or updated. The attributes that are present in backup but missing in Okta Source during the restore will be skipped.

  • For the user restore:

    • Linked objects is not currently supported

    • When a user is assigned several applications individually, and is then later assigned to a group which includes the same applications, the Okta user interface displays these application assignments as individual assignments. However, if the user is deleted and then restored, the applications will appear as group-assigned (and not individually assigned) because the restore process uses the following order: user, group, applications.

  • For the user type restore: If a User Type ID already exists during the granular User Type level restore, the users will not be restored.

  • For the authorization server restore:

    • If a trusted authorization server is associated after the backup, it will not be impacted during the restore.

    • If the authorization server and the policy rules are deleted after the backup, they will be added during the restore with least priority.

    • If a policy exists with a different ID but with the same name during the authorization server policy restore, a new policy with the epoch timestamp appended as a suffix will be created.

Considerations

  • The R-Cloud module for Okta WIC supports restoring SaaS application data to a different source (that is, a different SaaS module of the same type).

  • The following actions must be performed after restoring the IdP to the same source:

    • For the SAML 2.0 IdP: The Audience URI and ACS URL parameters must be updated at the IdP side.

    • For the OAuth2.0 and OpenID Connect IdPs: The ClientId (Okta App ID) parameter must be updated in the Authorize URL.

  • Okta may experience latency while updating the transaction data within its database. The delays range from a few minutes to extended periods of time. While the module uses a retry mechanism, the transaction delays may exceed the configured retry threshold. This issue becomes critical if the delays occur for the parent items, as the associated child item restores fail due to the missing or delayed parent transaction confirmation by Okta.

  • The following actions must be performed after restoring the IdP to a different source:

    • For the SAML 2.0 IdP: The Audience URI and ACS URL parameters must be updated at the IdP side.

    • For the OAuth2.0 and OpenID Connect IdPs:

      • The Redirect URI parameter must be updated at the IdP and at the Okta App (client) side.

      • The ClientId (Okta App ID) parameter must be updated in the Authorize URL.

Recommendations

To avoid throttling issues, make sure to assign between 95 and 100 percents of the API limits to the token created for R-Cloud. This can be configured by editing the token:

  1. Sign in your Okta Admin dashboard. Go to Security, then API, and then to Tokens. Click the Edit button for the token you're using.

  2. Click the Edit button of the Token rate limits section.

  3. Slide the pointer to 95 percent.

Configuring SaaS application data backup options

Before you start protecting SaaS applications, you can adjust SaaS application protection to the needs of your data protection environment by configuring backup options in R‑Cloud. You can configure backup options for a single SaaS application or for multiple SaaS applications at the same time.

Important  Configuring backup options is not supported for all types of SaaS applications. Additionally, the list of available backup options varies depending on the type of your SaaS application.

Backup options

Backup option Description
Exclude Resources

Enables you to specify one or more resources to be excluded from the backup.
Options

Enables you to use backup options specific to each SaaS application or SaaS application resource (for example, if you are protecting Google Cloud SQL, you can set the offload option that enables R‑Cloud to delegate the export operation to a separate data mover).
Data Movers

Enables you to specify the source, the region, and the subnet where you want R‑Cloud to create a data mover during the backup. If the specified source is an , you can also select a security group. If the specified source is an Azure resource group, you must select a network.

Important  For the SaaS applications that run in an , in an Azure resource group, or in a Google Cloud project: If you do not configure this backup option, R‑Cloud by default creates the data mover in your , Azure resource group, or Google Cloud project after you set up a target in R‑Cloud or add a source to R‑Cloud.

Prerequisites

  • For Google Cloud SaaS applications: Specifically for the HMSA, R‑Cloud requires additional permissions. For details, see Google Cloud permissions required by R‑Cloud.

  • Only if you plan to configure the data mover and select the Azure resource group as a source for the data mover. The network that you select must allow your Azure service principal or the HMSP to access the specified source and the targets that store the protected data.

  • The data movers must have access to the SaaS applications that you want to protect and to the targets that store the protected data. To ensure this, configure SaaS application backup options so that the data mover uses the appropriate subnet.

    Tip  You can check under which subnet the SaaS applications and the targets are accessible in your cloud provider management console.

Consideration

Only if you plan to store the protected SaaS application data on an Azure target. For security purposes, it is recommended that you configure SaaS application backup options so that R‑Cloud creates the data mover in the Azure resource group to keep the protected data in the same Azure environment during the backup.

Recommendation

If you plan to use targets for storing the protected data, optimize the egress data costs by configuring SaaS application backup options so that the data mover uses the same or the nearest available region as the target.

Note  R‑Cloud performs automatic synchronization of SaaS applications at periodic intervals. However, you can at any time update the list of SaaS applications also manually by clicking Synchronize Refresh.

To access the SaaS panel, in the navigation pane, click SaaS SaaS.

Procedure

  1. In the SaaS panel, select the SaaS application or the resource for which you want to configure backup options.

  2. Click Configuration Configuration. The SaaS Configuration dialog box opens.

  3. Depending on what you want to do, perform the required action:

    I want to... Instructions
    Exclude resources from the backup. On the Exclude Resources tab, select the resources that you want to exclude from the backup.
    Use a backup option specific to my SaaS application or resource. On the Options tab, specify which of the available backup options you want to use and provide the required information.
    Specify the source, the region, the subnet, the network, or the security group for a data mover.

    On the Data Movers tab, do the following:

    1. From the Compute drop-down menu, select the source for the data mover.

      Important  If the type of the source that you select for the data mover differs from the source where the target specified in the R‑Cloud policy resides, this may result in data egress charges.

    2. From the Region drop-down menu, select the preferred region.

    3. For Azure resource groups: From the Network drop-down menu, select the preferred network.

    4. From the Subnet drop-down menu, select the preferred subnet.

    5. For s: Optionally, from the Security Group drop-down menu, select the preferred security group. By default, the data mover is created in the default security group of the preferred subnet.

  4. Click Save.