Skip to main content
Code42 Support

Introduction To Single Sign-On

Applies to:
  • CrashPlan PROe
Implementing single sign-on (SSO) with your Code42 environment provides security benefits and simplifies the user experience. This article provides the following: Conceptual framework for understanding how the Code42 environment implements SSO Technical requirements for integrating a Code42 environment with a SAML-based identity provider Step-by-step procedures for configuring your master server and CrashPlan app to work with SSO External resources

Considerations

SSO Support
  • Support for single sign-on (SSO) for user authentication is included in versions 3.4.1 and later.
  • SSO is supported for all server components and for the CrashPlan app.
SSO Configuration
Network Access

  • 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.

What is SSO?

SSO is an authentication method that allows a user to log in once and then access multiple applications. The main components of an SSO system are:

  • Identity provider: The system that performs the authentication.
  • Service provider: A system acting as a gatekeeper for one or more resources (i.e. applications).
  • Resource: A protected application (may or may not be web-based). The resource and the service provider are often integrated, as is the case here.
  • User agent: A software application that acts on behalf of the user who wishes to access resources. The user agent is often a web browser, although it can also be a desktop application, mobile app, etc.

When a user attempts to access an SSO-enabled protected resource (e.g. the administration console), the user is redirected to the identity provider. If the user still has an active session with the identity provider, the user is automatically redirected to the desired resource. If the user does not have an active session, the user is forced to enter credentials. Once authenticated, the user has access to all applications or resources protected by the identity provider, for a configurable period of time.

Advantages and disadvantages of SSO

SSO has a number of security and convenience advantages:

  • Reduces user password fatigue from different username and password combinations
  • Reduces time spent re-entering passwords
  • Reduces IT costs due to lower number of IT help desk calls about passwords
  • Minimizes phishing opportunities
  • Provides detailed reporting on user access
  • All authentication is delegated to the identity provider. Therefore, the Code42 environment never proxies the user credentials.
  • Where customers do not have homogeneous Active Directory or LDAP implementation across the org (e.g. the Macs have local logins and are not tied to Active Directory), it is possible to authenticate through the use of SSO. This is sometimes the case in decentralized organizations, such as schools.

Disadvantages:

  • If the identity provider is unavailable, access to all associated service providers is lost. SSO can thus be undesirable for systems requiring guaranteed access at all times, such as security or plant-floor systems.
  • If a user's credentials are compromised, an unauthorized user may gain access to all of the resources that are protected by the compromised identity provider. Ensure that credentials are stored securely, and consider implementing strong authentication methods such as smart-cards and one-time password tokens.

SSO vs LDAP

  • SSO may be preferable to LDAP for organizations that wish to centrally control all authentication and authorization.
  • When using either local accounts or LDAP, the master server must accept or store user credentials. When using SSO, the user never enters the password into the CrashPlan app during authentication. Authentication and authorization are delegated to an identity provider.
  • The Code42 environment supports the use of multiple authentication methods on a per-organization basis. An example scenario:
    • The sales department uses LDAP
    • The finance department uses SSO
    • The IT department uses local accounts
  • With LDAP integration, more user management features are available. For example, LDAP can be used to automatically deactivate users and move users between organizations based on changes to users' LDAP attributes. These features are not available for SSO.
  • In cases where an organization has LDAP or AD set up for all devices, LDAP/AD is preferable to SSO due to the larger number of features and flexibility, and the greater maturity and speed of LDAP/AD.
 

How the Code42 environment works with SSO

The master server:

The following schematic diagram describes how the master server, the user agent (either the CrashPlan app or web browser), and the SSO identity provider interact.

Server configuration

The server configuration procedures described below assume that the identity provider has the name “Shibboleth.” Replace Shibboleth with the name assigned to your identity provider as described in the next section.

Adding identity provider

To configure your master server to use SSO authentication, go to Settings>Security>Single Sign-On, then:

  • Click the enable check box
  • Enter a name for the identity provider in the text field labeled Identity provider name
  • Enter the URL for the identity provider's metadata file in the text field labelled Identity provider metadata (URL). Your SSO identity provider administrator can provide you with this URL.
  • Click the Save button.

Once you save the configuration, the master server requests the metadata file from the identity provider.

The URL to the service provider (i.e. the master server) metadata file also appears on the page, as shown in the screenshot below:

SSO settings

This URL is used to configure the identity provider (e.g. Shibboleth) so that it accepts authentication requests from the Code42 service provider. The following example uses Shibboleth to illustrate the configuration of an identity provider:

  • You can configure Shibboleth to poll the service provider metadata file, or you can upload the actual metadata file to the Shibboleth server. In either case, you must edit the following file to point to the URL or the path to the service provider metadata file:
  • Edit the file '${Shibboleth}/conf/relying-party.xml', adding or modifying the MetadataProvider element for your service provider. The actual entry will vary depending on whether the metadata file is copied to the identity provider, or fetched via the http or https protocol. Example:
<metadata:MetadataProvider id="MyCrashPlanServerID" xsi:type="metadata:FilesystemMetadataProvider"
                metadataFile="/home/shibboleth/shib/idp/metadata/crashplan-metadata.xml"
                maxRefreshDelay="P1D" />
  • Change the id attribute to something unique and informative, e.g. “MyCrashPlanServerID.”
  • Add the path or URL to the metadata file.

The master server polls the the identity provider every six hours. The refresh interval is a configurable as described in the Properties section below.

Enabling SSO per oganization

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 Shibboleth for authentication option (the name of your SSO would replace the name Shibboleth in this example)
  • Click Save

System properties affecting SSO

A number of system properties on the master server can be configured. They are:

System Property Function Default
b42.ssoAuth.field.username Maps the SSO assertion attribute username field to a CrashPlan user field uid
b42.ssoAuth.field.firstname Maps the SSO assertion attribute firstname field to a CrashPlan user field givenName
b42.ssoAuth.field.lastname Maps the SSO assertion attribute lastname field to a CrashPlan user field sn
b42.ssoAuth.field.email Maps the SSO assertion attribute email field to a CrashPlan user field mail
b42.ssoAuth.identityProvider.metadataSyncHours Sets the polling interval for refreshing the identity provider metadata file 6 (units=hours)

Example scenario

You want the the master server to refresh the identity provider metadata file every 2 hours instead of every 6 hours:

  1. Enter the administration console CLI by double-clicking the logo in the upper-left corner.
  2. Enter the command: prop.set b42.ssoAuth.identityProvider.metadataSyncHours 2
    • You should see the following result displayed below the CLI:
The system property has been set.
Some system properties require a restart before they are recognized.
b42.ssoAuth.identityProvider.metadataSyncHours=2

The only SSO-related system property that requires a restart after you change it is b42.ssoAuth.identityProvider.metadataSyncHours.

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.

Server log messages

To find SSO-related activity in the server logs, search for “SsoAuth”. The example below shows connection and user errors:

[10.19.12 13:34:56.640 INFO GuiceCoreRuntime 9 om.code42.ssoauth.SsoAuthMetadataSyncCmd] SsoAuth:: Attempting to update 0 SSO servers. [10.19.12 13:39:59.556 ERROR jetty-web-366 m.code42.ssoauth.SsoAuthFetchMetadataCmd] SsoAuth:: Error opening a connection to the server http://idp.c42:8080/idp/shibboleth, java.net.UnknownHostException: idp.c42 [10.19.12 13:41:18.337 INFO jetty-web-365 com.backup42.history.CpcHistoryLogger ] HISTORY:: Subject[1/admin, orgId:1] SsoAuth:: create SsoAuth: SsoAuth[id=1, name=Shibboleth, idpMetadata.length()=4706] [10.19.12 13:59:44.557 INFO jetty-web-586 com.code42.ssoauth.UserLoginBySsoAuthCmd] AUTH:: SsoAuth:: User not found in local database: jshimek [10.19.12 13:59:44.562 INFO jetty-web-586 com.code42.core.ws.lib.RESTResource ] SsoAuthLoginResponseResource null Authentication/Authorization failure: AUTH:: SsoAuth:: User not found in local database: {}

You can see more detail by increasing the logging level for SSO errors. In the CrashPlan PROe CLI, enter the command:

log com.code42.ssoauth TRACE
  • The complete list of debugging levels is: ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF
  • The default level is INFO. After debugging is complete, either restart the service or reset the debugging level to 'info' with the command:
log com.code42.ssoauth INFO

Further considerations

  • SSO currently does not handle logout (single sign-off). Thus, if a user logs out of the Code42 environment, the master server does not notify other service providers, and vice-versa.
  • There is no control available in the administration console or the CrashPlan app to sign out of the SSO system. To force a user to sign out of the SSO identity provider, clear the ldp.c42 cookie from the web browser used to log in.
  • LDAP supports automated user management with the "Active Script", "Org Name Script" and "Role Name Script." However, SSO does not support custom scripts.
  • Multiple identity providers in the same environment are not supported.
  • SSO authentication may fail if the master server does not have a valid SSL certificate. If a self-signed certificate does not work, a certificate from an official Certificate Authority (CA) is required.
  • Your master server validates the SSL certificate of your SSO identity provider. If your identity provider's digital certificate does not contain the signature of a trusted Certificate Authority, validation may fail. To resolve this, install a CA-signed digital certificate on the identity provider.
  • The CrashPlan mobile apps on all platforms do not support SSO at this time.
  • SSO supports the use of the “auto register” option during CrashPlan app installation, using the value '${deferred}' for the password property in the custom installer. However, unlike the case with LDAP, the Code42 environment is not able to verify the user at the time of installation. Instead, the new user is allowed to back up immediately, without authenticating. However, users are not able to sign in to the CrashPlan app or restore unless they have a valid SSO account. If the password property is not set to deferred, the user is prompted to sign in upon first usage, as with LDAP.
  • The following warning message (found in logs on your master server) is normal: “Not syncing SSO metadata at this moment due to rate limiting." Rate limiting prevents syncing with your identity provider more than once per minute.
  • The Code42 environment supports SP (service provider)-initiated SSO. The Code42 environment does not support IdP (identity provider)-initiated SSO at this time. The user agent (either the CrashPlan app or the CrashPlan web app) initiates a session by accessing the enterprise server (acting as the SP), which then issues a SAML 2.0 AuthnRequest for the user to be delivered to the IdP.
  • In the IdP metadata file, the Code42 environment supports HTTP-POST (but not HTTP-REDIRECT). You must enable HTTP POST bindings in the IdP metadata.

If any of the caveats above are not acceptable, we recommend using LDAP or Radius for authentication and authorization instead of SSO.