Skip to main content
Code42 Support

Configure Okta for SSO in your Code42 cloud environment

Available in:

StandardPremiumEnterprise
Small Business
Applies to:

Overview

This tutorial explains how to configure your Code42 cloud environment to use single sign-on (SSO) with Okta. This article applies to environments in the Code42 cloud only. If you have an on-premises authority server, see Configure Okta for SSO in your Code42 on-premises environment.

This article assumes you are already familiar with SSO and the SAML standard. For more information about how Code42 implements SSO, see our Introduction To Single Sign-On.

Compatible Code42 components

Compatible With SSO
  • Code42 app for Windows, Mac, and Linux
  • Administration console
Incompatible With SSO
  • Code42 apps for iOS, Android, and Windows Phone

Considerations

  • To enable Okta's provisioning in Code42, your Okta environment must be licensed for the Lifecycle Management feature. If you are not licensed for the feature, you can still use Okta for single sign-on. 
  • Code42 supports service provider-initiated SSO but does not support identity provider-initiated SSO. This means that users cannot log in to your Code42 environment from an identity provider website or application.
Contact support
Contact Code42 support for help with authentication issues caused by interaction with Code42 products. However, troubleshooting authentication issues outside your Code42 environment is beyond the scope of our Customer Champions.

User provisioning

The following user provisioning features are available in the Code42 Okta app in the cloud. For more information on these provisioning features, see Okta's documentation.

Supported

  • Push New Users
  • Push Profile Updates
  • Push User Deactivation
    Note: For the Code42 app, deactivating a user means removing the user's account and placing the user's data into cold storage. Learn more about deactivating a user.
  • Import New Users

Not Supported

  • Push groups
    Note: Code42's professional services team can help you customize a solution for provisioning groups. Contact your Customer Success Manager (CSM) for enterprise support at csmsupport@code42.com for more information. 
  • Password sync
  • Okta cannot update user attributes for Admin users.
Okta suspended state
You can suspend a user via Okta. A suspended user will not be able to sign in to the Code42 administration console or Code42 app. However, suspending a user does not sign them out of the Code42 app if they are currently signed in. This means that if you suspend a user in Okta, you must go to the Code42 administration console and manually block the user. Blocking a user signs them out, and prevents them from signing back in to the Code42 app. 

Before you begin

Configure your private network, Internet, and VPN settings to allow client devices to communicate with your identity provider on ports 80 and 443. Test client connectivity to the identity provider before you proceed.

Step 1: Add the Okta application for Code42

  1. Sign in to your Okta dashboard.
  2. Add the Code42 application.
    Note: There are two Code42 apps on Okta's website. Add the Code42 app, which is used for cloud Code42 environments. The Code42 Single Tenant app is used in Code42 environments with on-premises authority server and in single-tenant cloud environments.
    Add the Code42 app for Okta
  3. Configure the general settings, and click Next
  4. Do not enable provisioning features yet. You will configure this in Step 5
Wait to assign people to the Code42 app
Do not assign people to the Code42 app yet. Wait until after you have enabled Okta's provisioning feature (Step 5). If you assign people to the Code42 app before you enable Okta's provisioning feature, the users are not automatically added to Code42. 

Step 2: Configure Okta's sign on tab

  1. In the Okta Dashboard, go to Applications and select the Code42 app.
  2. On the Sign On tab of the Code42 app, click Edit.
  3. Next to Server URL, enter https://www.crashplan.com
  4. Copy the Identity Provider metadata link. You will need it in the next step. 
    Okta sign on tab configuration
  5. Click Save.

Step 3: Add Okta to your Code42 administration console

  1. Sign in to the administration console.
  2. Navigate to Settings > Security.Single sign-on settings
  1. Click Add Identity Provider or Federation.
  2. In Identity Provider metadata URL, paste the URL for the identity provider metadata XML file you copied in Step 2.
  3. Click Continue.
    Additional identity provider settings appear.
    Identity provider settings
  4. In Display name, enter an identity provider name to display to users that sign in with SSO.
    If more than one SSO identity provider is offered by your Code42 environment, users are presented with a list of identity providers to choose from. The list includes all identity providers offered throughout your Code42 environment because the users' organizations are not known until they sign in.
  5. (Optional) Code42 recommends using the default settings, but you can customize mappings between Code42 platform user attributes and identity provider SSO assertion attributes.
    1. Deselect Use default mapping.
    2. Configure mapping settings for each Code42 platform user attribute:
      • Username: Specify the SSO identifier or attribute that maps to the Code42 platform username.
        • Select Use nameId to use the SSO name identifier.
        • Select Use Attribute tag to enter a custom SSO attribute.
      • Email: Enter the SSO attribute that contains user email addresses.
      • First name: Enter the SSO attribute that contains user first names.
      • Last name: Enter the SSO attribute that contains user last names.
  6. Click Save.

Step 4: Create a SCIM user account

This account performs directory sync with Okta.

  1. Sign in to the administration console.
  2. Navigate to Settings > Security.
    Single sign-on
  3. Click Create New User.
    Create New SCIM user
  4. Enter a username. 
  5. Select an SSO provider. 
  6. Click Create.
  7. Copy the generated password to the clipboard. You will add this password to the Okta application in Step 5.
    Note: This password only appears once. You will need to generate a new password if you lose or forget this one.
  8. Click Done.
SCIM users
SCIM users appear in your administration console, but they should not be used to back up data. SCIM users should only be used for directory syncing.

Step 5: Enable Okta's provisioning features

To enable Okta's provisioning in Code42, your Okta environment must be licensed for the Lifecycle Management feature. Contact Okta support for more information. 

  1. Return to the Okta dashboard, and configure the general settings. 
  2. Click Next to go to the Provisioning screen. 
  3. Select Enable Provisioning features.Enable Okta's provisioning features
  4. Complete the API Credentials section:
  5. Click Test API Credentials.
  6. Configure User Import:
    • (Optional) Schedule Import: Choose either never or a time interval.
      This schedules syncing from the Code42 for Enterprise to Okta.
    • (Required) Okta username format: Choose email address.
Email address required
The Code42 app requires the Okta username format to be email address.
  • (Optional) Max Import Unassignment: Choose a limit.
    For more information on importing users, see Okta's documentation.

  1. Next to Create Users, select Enable.
  2. Next to Update User Attributes, select Enable.
  3. Next to Deactivate Users, select Enable.
    Note: Deactivating a user means removing the user's account and placing the user's data into cold storage. Learn more about deactivating a user.

Update Users

  1. Click Next.

Step 6: Assign people to the Code42 app

Assign users to the Code42 app. See Okta's documentation for more information on assigning users to apps.

These users are automatically added to the Code42 administration console. If these users do not appear in the administration console, unassign and reassign the Code42 app.  

(Optional) Step 7: Add additional SSO override users

You can add additional SSO override users to only use local authentication—they do not use SSO. Adding more SSO override users ensures that you are still able to sign in to your administration console if you are experiencing problems with your SSO provider.

First user automatically added to SSO Override
The SSO Override list automatically includes your environment's first user. Adding additional users is optional. 
  • Users in the override list can never use SSO. They must sign in with a passwords defined in the administration console.
  • We recommend you always have at least one user in the SSO Overrride list
  1. Under SSO Override, enter a username into the box.
    We recommend adding users with either the Org Admin or Customer Cloud Admin role.
  2. Click + to add the admin to the list.
    SSO Override
  3. Add the password for the SSO Override user:
    1. Go to Users, and select the SSO Override user. 
    2. Click on the action menu, and choose Edit
    3. Add the password for the user. 

Step 8: Test SSO authentication

To avoid impacting your production environment, use a test organization to verify that SSO is working properly.

  1. In the administration console, create a test organization.
  2. Configure the test organization to use SSO.
    1. Navigate to Organizations, then select the organization.
    2. From the action menu, select Edit.
    3. Click Security.
      Enable SSO For Organization
    4. Deselect Inherit security settings from parent.
    5. From Select an authentication method, choose SSO.
      The configured SSO identity providers appear.
    6. Select the identity providers you want to offer for the organization.
    7. From Select a directory service, select Local.
    8. Click Save.
  3. In the Okta dashboard, add a test user to the Code42 app. See Okta's documentation for more information.
  4. Go to the Code42 administration console, and sign in as the test user to verify that SSO is working.
    The Okta sign on screen appears.Okta Sign In

Step 9: Configure organizations to use SSO

Enable SSO for one or more organizations in your Code42 environment. If two or more identity providers are offered in your Code42 environment, tell the users in each organization which identity provider they should choose when they sign in.

Disabled inheritance
If you disable inheritance for an organization, that organization is not affected by changes to its parent organization.

Option A: Enable SSO for a specific organization

  1. Sign in to the administration console on your authority server.
  2. Navigate to Organizations, then select the organization.
  3. From the action menu, select Edit.
  4. Click Security.
    Organization settings
  5. Deselect Inherit security settings from parent.
  6. From Select an authentication method, choose SSO.
    The configured SSO identity providers appear.
  7. Select the identity providers that you want to offer for the organization.
  8. From Select a directory service, select Local.
  9. Click Save.

Option B: Enable SSO for all organizations

Modify the system-wide organization settings to enable SSO for all organizations.

  1. Sign in to the administration console on your authority server.
  2. Go to Organization.
    Organizations
  3. Click the top-level organization.
    The organization details appear.
  4. Go to the action menu, and choose Edit.
  5. Click Security.
    Organization settings
  6. From Select an authentication method, choose SSO.
    The configured SSO identity providers appear.
  7. Select the identity providers you want to offer to your organizations.
  8. From Select a directory service, select Local.
  9. Click Save.
  10. Under each child organization, make sure that Inherit security settings from parent is enabled.
    1. Click the child organization.
    2. Go to the action menu, and choose Edit.
    3. Click Security.
    4. Select Inherit security settings from parent.

Step 10: Add new users that sign in with SSO

  1. Assign the Code42 app to users or groups in the Okta dashboard. See Okta's documentation for more information.
  2. Distribute the Code42 app installer to new users.
  3. New users can sign in with their SSO credentials.

What to expect

Reduced authentication prompts

When a user signs in with SSO, the user does not need to reenter credentials for subsequent authentication attempts until the SAML authentication token expires. A SAML token applies to an application rather than a device, which means that a user might need to enter credentials again when signing into a different app. Signing in to the Code42 app does not also authenticate the administration console because one is an app on the device and the other is accessed via a web browser.

Updates to users 

Okta synchronizes with the Code42 administration console each time you update a user, and it determines if any changes need to be made based on the user's current attributes in Okta. If you make changes to a user in the Code42 administration console, the next time Okta syncs, your changes will be overwritten with the user attributes that are currently in Okta's system. For example, if you deactivate a user in the Code42 administration console, and they are still active in Okta, the user is automatically reactivated during synchronization. To update users, make your changes in Okta—not in the Code42 administration console.

Lost access to an identity provider

If a user loses access to the identity provider, the Code42 app continues to back up, uninterrupted.

External resources