This tutorial explains how to integrate your Code42 environment to work with the Okta identity management provider. Okta provides a standards-based service to enable centralized user access control using Single Sign-On (SSO) technologies such as SAML. Okta's cloud-based SSO service also supports integration with an existing directory service, such as Google Apps or Active Directory.
The integration of Okta with the Code42 environment requires the configuration of two systems:
The following steps take you through the setup process.
First, you must set up your Okta account to provide appropriate information for your Code42 environment.
4280. For example, the "Post Back URL" in the example above would now be:
The IdP (Identity Provider) metadata must be available on your web server to all your devices running the CrashPlan app.
idp.xmlwithin the root directory of your web server, or in the directory that you plan to make accessible to CrashPlan apps.
Add a test user to your company's Okta account in order to test authentication.
Okta requires you to assign to each SSO user the application that you created in Step 1: Create A Custom SAML Template On Okta.
From the People screen, click the user's full name, then assign the newly configured application to the user:
prop.set b42.ssoAuth.nameId.enable true save
The system property has been set.
Some system properties require a restart before they are recognized.
Your Code42 environment must be configured to use Okta's SSO authentication instead of the native user authentication system. This example will configure a single organization to authenticate with Okta, but you can also apply these steps with the top-level organization in order to use Okta with your entire Code42 environment.
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 articleRead 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:
| || || |
| || ||If set to true, SSO authentication is enforced, and the standard login fields are hidden. Default is |
| ||Display name of your SSO provider (label).||Name of the SsoAuth identity provider. Only used if |
Set the properties in the table above to the desired values:
ssoAuth.enabledmust be set to 'true'.
ssoAuth.requiredmay be set to either 'false' (the default) or 'true'. Set to 'true' if you want to force users to use SSO for authentication.
ssoAuth.providershould be set to the name you wish to be displayed to users as the name of the identity provider upon successful login.
ldp.c42cookie from the web browser used to log in.
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.othercompany.org/idp/s...SSOService.php”/>
If any of the caveats above are not acceptable, we recommend using LDAP or Radius for authentication and authorization instead of SSO.
A number of Code42 environment system properties affect SSO behavior.
For other questions relating to Okta's identity management products, please see Okta's support site.