Who is this article for?
Incydr
Code42 for Enterprise
CrashPlan for Enterprise
Incydr, yes.
CrashPlan for Enterprise, yes.
Code42 for Enterprise, yes.
CrashPlan for Small Business, no.
This article applies to Code42 cloud environments.
Other available versions:
On-premises
Overview
This tutorial explains how to configure your Code42 cloud environment to use single sign-on (SSO) with Shibboleth. If you have an on-premises authority server, see the instructions for configuring Shibboleth.
This article assumes you are already familiar with SSO and the SAML standard. For more information about how the Code42 platform implements SSO, see our Introduction to single sign-on.
Compatible Code42 platform components
Compatible with SSO
- Code42 app for Windows, Mac, and Linux
- Code42 console
Incompatible with SSO
- Code42 apps for iOS, Android, and Windows Phone
Considerations
- Code42 usernames must match SSO usernames. How you accomplish this depends on how you deploy Code42 apps.
- Code42 supports service provider-initiated SSO but does not support identity provider-initiated SSO. Therefore, users cannot sign in to your Code42 environment from the identity provider's website or application, but instead must log in using a browser bookmark.
- SSO provides user authentication but does not provide user management. Set up SCIM provisioning or use the Code42 console to manage users.
- Code42 does not support Single Logout (SLO). Users must sign out of the identity provider to end their single sign-on session.
- To configure Code42 to support advanced SAML request configurations using the Code42 API, see Use the Code42 API to set SAML attributes.
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
Verify identity provider configuration
- Make sure the SSL certificate of your SSO identity provider has been signed by a trusted Certificate Authority (CA).
- Make sure you have administrative access to the identity provider or have contact with an identity provider administrator.
Verify network configuration
- Configure your private network, Internet, and VPN settings to allow client devices to communicate with your identity provider on port 443. Test client connectivity to the identity provider before you proceed.
- If you want to use URL-based metadata exchange to configure Code42 and the identity provider to work together, make sure two-way communication is available between them on TCP port 443. If two-way communication is not available or not allowed, you must download the identity provider's metadata file and make it accessible to Code42.
- Confirm the required ports with your identity provider to determine if custom ports are being used.
Step 1: Add an authentication provider
Follow the steps below for adding the authentication provider's metadata URL to the Code42 console. If your organization is part of the InCommon federation, you can add the InCommon metadata, and select your organization's metadata URL from the list. Follow the steps under Shibboleth if you are not part of the InCommon federation.
InCommon
Step 1: Enter the InCommon metadata
- Sign in to the Code42 console.
- Navigate to Administration > Integrations > Identity Management.

- Click Add Authentication Provider.

- In Display Name, enter the federation name.
- In Provider's Metadata, ensure that Enter URL is selected and paste the URL. For the InCommon federation, we recommend using the IdP-only aggregate: https://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml
Use metadata URL for federations
Code42 cloud environments do not support uploading an XML file for federations. Use the metadata URL to configure the federation instead.
Custom domains are not supported
When entering the URL for the XML metadata file, custom domains are not supported. You must use the standard domain of your identity provider.
- Click Create Provider.
Code42 automatically detects that the provider's metadata URL belongs to a federation, and details for the federation appear.

Step 2: Select your identity provider
- From federation settings, Click Add an identity provider to this federation.

- Select a provider from the list.
Begin typing to search the list.
- Enter a display name for the provider to display to users who sign in.
If your Code42 environment provides more than one SSO identity provider, users see a list of providers to choose from.
- Click Add Identity Provider.
The provider appears under the federation.
Shibboleth
Enter Shibboleth metadata
Use the Shibboleth metadata URL provided by your institution.
Step 2: Prepare Shibboleth
There are two ways to exchange metadata between your Code42 environment and the Shibboleth identity provider:
- If two-way communication is possible between Shibboleth and your {{c42cloud}} instance, use URL-based metadata exchange. This method periodically retrieves metadata from a given URL and stores the metadata file locally, so it can be used if the remote source is unavailable.
- If two-way communication is not available, use file-based metadata exchange.
For more information about adding a service provider to Shibboleth, see the Shibboleth documentation.
Shibboleth option A: URL-based metadata exchange
Configure your Code42 environment as a file-backed HTTP metadata provider.
- Make sure the Shibboleth identity provider can access the Code42 service provider metadata URL.
Find your Code42 environment's metadata URL under Administration > Integrations > Identity Management on the Authentication Providers tab.
- Configure your Shibboleth identity provider to accept authentication requests from your Code42 environment.
- Edit the file
${Shibboleth}/conf/relying-party.xml
.
- Add or modify the
MetadataProvider
element for your Code42 environment.
<MetadataProvider xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
id="Code42_Environment"
metadataURL="https://www.crashplan.com/api/SsoAuthSpMetadata?registrationkey=xxxxxxxxxxxxxxxx"
backingFile="/tmp/idp-metadata.xml" />
Set the following values by modifying the text between the quotes:
id
: A name for your Code42 environment.
metadataURL
: Your Code42 environment's service provider metadata URL.
backingFile
: The path to the backup copy of the service provider metadata file on the identity provider.
Shibboleth option B: File-based metadata exchange
Configure Code42 as a filesystem metadata provider.
- Download the Code42 service provider metadata file, and upload it to the identity provider.
The service provider metadata file is located in the Code42 console in the authentication provider details.
- Configure your Shibboleth identity provider to accept authentication requests from Code42.
- Edit the file
${Shibboleth}/conf/relying-party.xml
.
- Add or modify the
MetadataProvider
element.
<MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
id="Code42_Environment"
metadataFile="/path/to/my/metadata.xml" />
Set the following values by modifying the text between the quotes:
id
: A name for your Code42 environment.
metadataFile
: The path to the Code42 service provider metadata file on the Shibboleth identity provider.
Configure your Shibboleth identity provider to sign assertions
The Code42 console expects assertions to be signed. See Shibboleth's documentation for more information.
- Edit the file
${Shibboleth}/conf/relying-party.xml.
- Add or modify the
ProfileConfiguration
element, for example:
<RelyingParty id="urn:example.org" provider="https://idp.example.org" defaultSigningCredentialRef="ExampleOrgCred">
<ProfileConfiguration xsi:type="saml:SAML2SSOProfile" signAssertions="always"/>
</RelyingParty>
- Set the
signAssertions
attribute to always.
Step 4: Test SSO authentication
- Create a test user in your identity provider.
- Sign in to the Code42 console.
- Create a test organization.
- Configure the test organization to use SSO.
- Navigate to Administration > Integrations > Organizations, then select the organization.
- From the action menu in the upper-right, select Edit.
- Click Security.
.png?revision=1&size=bestfit&width=1093&height=717)
- Deselect Inherit security settings from parent.
- From Select an authentication method, choose SSO.
The configured SSO identity providers appear.
- Select the identity providers that you want to offer for the organization.
- From Select a directory service, select Local.
- Click Save.
- Type ENABLE in the field provided and click ENABLE.
- Create a user in the test organization who matches the identity provider test user.
- In the upper-right of the Code42 console, select Account
> Sign Out.
- Sign back in to the Code42 console as the test user to verify that SSO is working.
Step 5: Configure organizations to use SSO
Enable SSO for one or more organizations in your Code42 environment. If two or more authentication providers are offered in your Code42 environment, tell the users in each organization which authentication provider they should choose when they sign in.
Option A: Enable SSO for a specific organization
- Sign in to the Code42 console.
- Navigate to Administration > Environment > Organizations, then select the organization.
- From the action menu, select Edit.
- Click Security.
.png?revision=1&size=bestfit&width=1093&height=717)
- Deselect Inherit security settings from parent.
Disabled inheritance
If you
disable inheritance for an organization, that organization is not affected by changes to its parent organization.
- From Select an authentication method, choose SSO.
The configured authentication providers appear.
- Select the identity providers that you want to offer for the organization.
- From Select a directory service, select Local.
- Click Save.
Option B: Enable SSO for all organizations
Modify the system-wide organization settings to enable SSO for all organizations.
- Sign in to the Code42 console.
- Go to Administration > Environment > Organizations.
- Click on the top-level organization.
The organization details appear.
- From the action menu, select Edit.
- Click Security.

- From Select an authentication method, choose SSO.
The configured authentication providers appear.
- Select the identity providers that you want to offer to your organizations.
- From Select a directory service, select Local.
- Click Save.
- Under each child organization, make sure that Inherit security settings from parent is enabled.
- Click the child organization.
- From the action menu, select Edit.
- Click Security.
- Enable Inherit security settings from parent.
Step 6: Add new users that sign in with SSO
Option A: Add users in the Code42 console
Use the Code42 console to add users to an organization that uses SSO.
- Verify that the users in the organization exist in the SSO identity provider used by the organization.
- Make sure that the Code42 environment usernames match the SSO usernames.
Option B: Deploy the Code42 app
New users can register accounts in your Code42 environment:
- Distribute the Code42 app installer to new users.
- Choose Sign up for an account when you open the Code42 app.
- Create an account using the SSO credentials. The Code42 app username must match the SSO username.
What to expect
Reduced authentication prompts
When a user signs in with SSO, the user does not need to re-enter 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 authenticate the Code42 console because one is an app on the device and the other is accessed via a web browser.
Losing access to an identity provider
If a user loses access to the identity provider, the Code42 app continues to back up, uninterrupted.