Implementing single sign-on (SSO) in your CrashPlan environment provides security benefits and simplifies the sign-in experience. This article provides:
- A list of configuration articles that describe how to set up SSO with third-party SAML 2.0 identity providers (IdPs)
- An overview of SSO
External authentication systems
Our Customer Champions can help with authentication issues caused by interaction with CrashPlan products. However, troubleshooting authentication issues outside your CrashPlan environment is beyond the scope of our Customer Champions. For assistance with external authentication systems, contact your authentication vendor.
- To use this functionality, you must be assigned the Identity Management Administrator role.
- CrashPlan usernames must match SSO usernames. How you accomplish this depends on how you deploy CrashPlan apps.
- CrashPlan supports service provider-initiated SSO but does not support identity provider-initiated SSO. Therefore, users cannot sign in to your CrashPlan 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 CrashPlan console to manage users.
- CrashPlan does not support Single Logout (SLO). Users must sign out of the identity provider to end their single sign-on session.
- The CrashPlan console expects SAML assertions to be signed. To configure CrashPlan to support advanced SAML request configurations, see Set SAML attributes for SSO in CrashPlan.
SAML 2.0 algorithms
The following SAML 2.0 algorithms are still allowed only when used in properties of the identity provider:
- RSA/MD5 for digital signatures:
- MD5 for HMAC:
If your identity provider is up to date and configured appropriately, these deprecated methods are not provided. However, these deprecated algorithms are permitted if your identity provider still provides these methods for signing its tokens.
SSO configuration articles
You can configure SSO for CrashPlan with any provider that uses SAML 2.0. For general directions, see How to configure SSO in your CrashPlan environment.
The following articles provide instructions for specific providers.
- Configure Azure for SSO in your CrashPlan environment
- Configure Google for SSO in your CrashPlan environment
- Configure InCommon for SSO in your CrashPlan environment
- Configure Microsoft AD FS for SSO in your CrashPlan cloud environment
- Configure Okta for SSO in your CrashPlan cloud environment
- Configure OneLogin for SSO in your CrashPlan cloud environment
- Configure PingOne for SSO in your CrashPlan cloud environment
- Configure Shibboleth for SSO in your CrashPlan cloud environment
Before you begin SSO configuration
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 CrashPlan 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 CrashPlan.
- Confirm the required ports with your identity provider to determine if custom ports are being used.
What is SSO?
Single sign-on SSO is an authentication method that allows a user to use the same credentials to sign in to multiple applications. You can integrate CrashPlan with any provider that uses SAML 2.0.
SSO authentication process
When a user attempts to access an SSO-enabled protected resource, such as a CrashPlan application or CrashPlan 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 prompted to enter credentials. Once authenticated, the user has access for a configurable period of time to all resources protected by the identity provider.
The following diagram describes how the CrashPlan platform components and the SSO identity provider interact.
- Service provider: CrashPlan cloud instance
- User agent: CrashPlan applications or web browser
- Identity provider: A SAML 2.0 identity provider that supports HTTP POST binding
When a user attempts to sign in, the user agent sends a sign-in request to the service provider.
|2||The service provider refers the user agent to the identity provider's SSO URL.|
|3||The user agent sends an authentication request to the identity provider.|
|4||The identity provider authenticates the user and provides the user agent with a SAML authentication token.|
|5||The user agent sends the authentication token to the service provider.|
|6||The service provider accepts the authentication token and grants the user access to the user agent.|
SSO advantages, disadvantages, and limitations
- Delegates all authentication to the identity provider
- Allows for centralized authentication in organizations that do not implement Active Directory or LDAP (for example, computers that are not tied to a directory)
- Minimizes phishing opportunities
- Provides detailed reporting on user access
- 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
- Prevents access to service providers if the identity provider is unavailable
For this reason, SSO can be undesirable for systems requiring guaranteed access at all times, such as security or plant-floor systems.
- Allows an unauthorized user to gain access to all protected resources if a user's credentials are compromised
To reduce risk, ensure that credentials are stored securely, and consider implementing strong authentication methods such as smart-cards and one-time password tokens.
- Provides user authentication but does not provide user management
User management is provided by the local CrashPlan directory, SCIM provisioning, or CrashPlan User Directory Sync.
- CrashPlan does not handle single sign-off. If a user logs out of the CrashPlan environment, the CrashPlan cloud does not notify other service providers, and vice-versa.
- When a user signs out of the SSO identity provider, he or she is not automatically signed out of the CrashPlan applications. There are two ways the user can be signed out of the CrashPlan applications:
- An administrator can deauthorize the user's devices from the CrashPlan console.
- The user can sign out of the CrashPlan applications.