Skip to main content
Code42 Support

Setting Up Single Sign-On With The Okta CrashPlan PROe App

Applies to:
  • CrashPlan PROe
This tutorial explains how to integrate your Code42 environment to work with Okta, an identity management provider. Okta provides centralized user access control using Single Sign-On (SSO) technologies such as SAML and supports integration with an existing directory service, such as Google Apps or Active Directory. This tutorial uses Okta's customized application for CrashPlan PROe, which simplifies the integration and setup process. For greater control over integrating your Code42 environment with Okta, please see our general Okta integration article.

Considerations

  • SSO is supported for all server components and for the CrashPlan app.
  • You must deploy a customized CrashPlan app installer to your users to use SSO for authentication
  • If your firewall rules preclude two-way communication between your master server and Okta on ports 80 and 443 as detailed below, instead use the template-based SAML solution.
Identity Provider
Network Considerations

  • You may need to modify your firewall rules to allow the use of SSO:
    • 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.
    • Two-way communication on TCP ports 80 and 443 between the Identity Provider and and your master server is required. The Service Provider (your master server) and Identity Provider need to be able to communicate with each other to perform metadata exchange.
    • Confirm the required ports with your SSO provider, in the unlikely event that custom ports are being used
  • Your master server needs to be able to access the Identity Provider metadata file, which may be stored in one of two locations:
    • Locally, on your enterprise server's file system
    • On a web server in your LAN, or via WAN
      • In this case, your enterprise server must be able to access the web server hosting the Identity Provider metadata on the port and protocol you have chosen (either http or https)

External authentication systems
Our Customer Champions can 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.
For assistance with external authentication systems, contact your authentication vendor.

Before you begin

Configure your Okta account and dashboard

Steps

Step 1: Sign in to your Okta dashboard

  1. Sign in to your Okta dashboard at your custom Okta URL
    Example: https://yourcompany-admin.okta.com

Step 2: Add the CrashPlan PROe app

  1. Click on the Applications tab
  2. Click the Assign Applications button
  3. Enter "CrashPlan" in the search field
    The CrashPlanPROe app appears in the search resultsSearch in Okta for CrashPlanPROe
  4. Click the Add button to add the CrashPlanPROe app to your Okta dashboard.

Step 3: Fill in general settings

  1. (Optional) Modify the Application label field, if you wish. The default is CrashPlanPROe.
  2. Enter the value for your master server's URL:
    • The server URL may be found in the administration console of your master server:
      • Sign in to your administration console
      • Go to Settings > Server
      • Copy the value of the field Website protocol, host and port
    • You must use the https protocol and port 4285, rather than the http protocol and port 4280
    • Example value:
      https://master-server.example.com:4285
  3. Leave the LoginURL field blank
  4. Leave all other settings at their default values
  5. Click Next

General settings complete

Step 4: Configure sign-on options

The Sign-On Options configuration page will now be visible.

  1. Choose SAML 2.0:Sign On Methods: choose SAML 2.0
  2. Leave other options at default settings
  3. Click Identity Provider metadata to download the metadata text file to your workstation or server IdP metadata file link
    • This metadata file will be required for the configuration of your master server as described below.
    • Save the file in a plain text editor.
  4. Click Next

Step 5: Assign CrashPlanproe Okta app to users

Assign Okta users to the CrashPlanPROe Okta app. If you have not created Okta users, see Okta's documentation on adding new users.

  1. Select the users to add:Add users select
  2. Click Next
  3. Confirm that the assigned usernames are correct
  4. Click Done
    A confirmation message and list of assigned users is displayed

Users assigned complete

Configure your Enterprise Server

Before you begin

You must have an Okta account, and have added the CrashPlanPROe app to your Okta dashboard, as described above. You should also have a saved copy of the Identity Provider metadata file, as described above.

Steps

Step 1: Make identity provider metadata file available

The Identity Provider metadata file copied and stored in Step 4 above must be made available to your master server. This may be accomplished by:

  1. Making the metadata file available on your corporate web server
  2. Installing a web server on your enterprise server or other server and placing the metadata file in the root directory of the web server (e.g. /var/www)
    • This option is not available for our managed appliances

This tutorial assumes that you decided to install the Apache web server (or another web server) on your enterprise server. Modify the steps as necessary for your environment, or contact sales for SSO configuration assistance options.

Setting Up An Apache Web Server
  1. Install the Apache http server on your enterprise server or other server
    • Follow the specific directions for your platform and configuration
  2. Start the http daemon (Linux/Unix) or service (Windows/Mac)
  3. Copy the Identity Provider metadata file to the a text file named "idp.xml"
    • On a standard Linux installation, the root directory for the http server is /var/www
  4. Set the permissions on the metadata file to be readable by the web server daemon or service
  5. Test access to the metadata file
    1. Navigate to the URL of the metadata file and confirm that you can view the file: Metadata URL test

Step 2: Configure your Master server SSO settings

  1. Go to Settings>Security>Single Sign-On
  2. Enable SSO by clicking the Enable checkbox
  3. Enter "\ Okta" as the Identity Provider Name (the slash+space provides "padding" so that the label is displayed properly on the administration console sign-in screen )
  4. Enter the URL to the Identity Provider metadata file as tested above in Step 1.
    1. After tabbing out of the Identity Provider metadata URL field, you should see a green checkmark, confirming that the URL was reachable:Metadata URL verified
  5. Click Save
  6. You will see the message "Your changes have been saved" at the lower left of the administration console: Config saved

Configure your Code42 environment to accept SSO login

You must enable SSO on a per organization basis as described here:

  • If the parent org already uses SSO, make sure that the option Inherit security settings from parent is enabled.
  • If the parent org does not use SSO, disable the Inherit security settings from parent option
  • Enable the Use Your_SSO_Provider for authentication option (the name of your SSO provider would replace the name "Your_SSO_Provider" in this example)
  • Click Save

Test your Okta configuration

Step 1: Sign out of the Administration console

If you are still signed in to your Code42 administration console as an administrator, sign out.

Step 2: Confirm Okta option is available

You should see the SSO option on the administration console sign-in screen:
SSO console

Step 3: Sign in using SSO

  1. Click Sign in using Okta
    You are redirected to the Okta Sign In screen:
    Okta sign in screen
  2. Sign in using the credentials of a user in an SSO-enabled organization

You are signed in to your administration console, confirming that your device was able to communicate with the Okta service, authorize, and sign in to your master server. If you have any problems signing in, check your Okta configuration and the SSO settings in your administration console.

Client configuration

In order to enable SSO on the CrashPlan app, a custom installer must be used during installation. Complete instructions on the creation of a customized CrashPlan app can be found in the article Customizing The CrashPlan app. Read and understand the process of creating a customized CrashPlan app before proceeding with the steps outlined below, which are specific to SSO.

During the creation of a custom installer, the 'custom.sh' script is run, or the file 'custom.properties' is edited, in order to set the value of a number of customizable properties. The following properties pertain to SSO:

Property Name Values Notes
ssoAuth.enabled true or false SsoAuth will not be available unless this is true. Default is false.
ssoAuth.required true or false If set to true, SSO authentication is enforced, and the standard login fields are hidden. Default is false.
ssoAuth.provider Display name of your SSO provider (label). Name of the SsoAuth identity provider. Only used if ssoAuth.enable=true. Default is Shibboleth. This value is user-facing.

Set the properties in the table above to the desired values:

  • ssoAuth.enabled must be set to 'true'.
  • ssoAuth.required may be set to either 'false' (the default) or 'true'. Set to 'true' if you want to force users to use SSO for authentication.
  • ssoAuth.provider should be set to the name you wish to be displayed to users as the name of the identity provider upon successful login.

Once you have set these properties, and the other properties as described in Customizing The CrashPlan app, continue with the standard process to create the custom installers.

External resources