Skip to main content

Who is this article for?

Incydr
Code42 for Enterprise
CrashPlan for Enterprise

Incydr, no.

CrashPlan for Enterprise, yes.

Code42 for Enterprise, yes.

CrashPlan for Small Business, no.

This article applies to on-premises authority servers.

Other available versions:

Cloud

HOME
GETTING STARTED
RELEASE NOTES
FAQs
APIs
SYSTEM STATUS
Code42 Support

Introduction to single sign-on

Who is this article for?

Incydr
Code42 for Enterprise
CrashPlan for Enterprise

Incydr, no.

CrashPlan for Enterprise, yes.

Code42 for Enterprise, yes.

CrashPlan for Small Business, no.

This article applies to on-premises authority servers.

Other available versions:

Cloud

Overview

Implementing single sign-on (SSO) as the authentication method in your Code42 environment provides security benefits and simplifies the sign-in experience. This article provides:

Considerations

  • Code42 usernames must match SSO usernames. How you accomplish this depends on how you deploy Code42 apps.
  • Users cannot sign in to your Code42 environment from an identity provider's website or application. The Code42 console supports service provider-initiated SSO but does not support identity provider-initiated SSO.
  • SSO provides user authentication but does not provide user management. Set up SCIM provisioning or use the Code42 console to manage users. 
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.

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:
    SignatureConstants.ALGO_ID_SIGNATURE_NOT_RECOMMENDED_RSA_MD5
  • MD5 for HMAC:
    SignatureConstants.ALGO_ID_MAC_HMAC_NOT_RECOMMENDED_MD5

If your identity provider is up to date and configured appropriately, these deprecated methods are not provided. However, these deprecated algorithms are permitted to allow the authority server to be backward compatible if your identity provider still provides these methods for signing its tokens.

SSO configuration articles

You can integrate Code42 with any provider that uses SAML 2.0. For general directions, see How to configure SSO in your Code42 environment.

The following articles provide instructions for specific providers. The following identity providers have been tested on Code42 environments with an on-premises authority server. However, Code42 can integrate with any provider that uses SAML 2.0. 

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 Code42 with any provider that uses SAML 2.0. 

Definitions

SSO authentication process

When a user attempts to access an SSO-enabled protected resource, such as a Code42 application or Code42 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 Code42 platform components and the SSO identity provider interact.

  • Service provider: Code42 for Enterprise authority server
  • User agent: Code42 for Enterprise applications or web browser
  • Identity provider: A SAML 2.0 identity provider that supports HTTP POST binding

SSO authentication diagram

Item Description
1

When a user attempts to sign in, the user agent sends a sign-in request to the service provider.
 

Note: An API call is made to your authority server's Website protocol, host and port, so that port must be open to the user agent. 

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

Advantages
  • 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
Disadvantages
  • 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 Code42 directory, or LDAP.
Code42 limitations
  • Code42 does not handle single sign-off. If a user logs out of the Code42 environment, the authority server 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 Code42 for Enterprise applications. There are two ways the user can be signed out of the Code42 for Enterprise applications:
    • An administrator can deauthorize the user's devices from the Code42 console.
    • The user can sign out of the Code42 for Enterprise applications.

External resources