How can we help?

We think these articles could help:

    See More
    Home > Administrator Resources > 4.1 > Configuring > Single Sign-On

    MindTouch
    Copyright (c) 2006-2014 MindTouch Inc.
    http://mindtouch.com

    This file and accompanying files are licensed under the MindTouch Master Subscription Agreement (MSA).

    At any time, you shall not, directly or indirectly: (i) sublicense, resell, rent, lease, distribute, market, commercialize or otherwise transfer rights or usage to: (a) the Software, (b) any modified version or derivative work of the Software created by you or for you, or (c) MindTouch Open Source (which includes all non-supported versions of MindTouch-developed software), for any purpose including timesharing or service bureau purposes; (ii) remove or alter any copyright, trademark or proprietary notice in the Software; (iii) transfer, use or export the Software in violation of any applicable laws or regulations of any government or governmental agency; (iv) use or run on any of your hardware, or have deployed for use, any production version of MindTouch Open Source; (v) use any of the Support Services, Error corrections, Updates or Upgrades, for the MindTouch Open Source software or for any Server for which Support Services are not then purchased as provided hereunder; or (vi) reverse engineer, decompile or modify any encrypted or encoded portion of the Software.

    A complete copy of the MSA is available at http://www.mindtouch.com/msa

    Single Sign-On

    Applies to:
    • CrashPlan PROe
    • SharePlan for Enterprise

    Overview

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

    • An overview of SSO
    • A comparison of the SSO functionality available in Code42 EDGE Platform versions 4.1.4, 4.1.5, and 4.1.6
    • A list of compatible Code42 EDGE Platform components and third-party SAML 2.0 identity providers (IdPs)

    For SSO configuration instructions, see our setup articles for version 4.1.6 and versions 4.1.4 and 4.1.5.

    What Is SSO?

    SSO is an authentication method that allows a user to use the same credentials to sign in to multiple applications.

    Definitions

    The main components of an SSO system are:

    identity provider
    The system that performs the authentication. Often abbreviated as IdP.
    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.

    SSO Authentication Process

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

    The following diagram describes how the Code42 EDGE Platform components and the SSO identity provider interact. 

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

    Code42 SSO process diagram

    Advantages And Disadvantages Of SSO

    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
    • Delegates all authentication to the identity provider; the Code42 environment never proxies user credentials
    • Allows for centralized authentication in organizations that do not implement Active Directory or LDAP (for example, computers that are not tied to a directory) 
    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
      Ensure that credentials are stored securely, and consider implementing strong authentication methods such as smart-cards and one-time password tokens.

    SSO Versus LDAP

    • SSO may be preferable to LDAP for organizations that wish to centrally control all authentication and authorization.
    • In cases where an organization has LDAP or AD set up for all devices, LDAP/AD may be preferable to SSO due to the larger number of features and flexibility.
    • 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.
    • 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.
    • 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 legal department uses SSO with LDAP (Code42 EDGE Platform version 4.1.6 and later)
      • The IT department uses local accounts

    Code42 EDGE Platform SSO Functionality By Version

    Code42 EDGE Platform version 4.1.6 supports more SSO features than versions 4.1.4 and 4.1.5.

    Feature Version 4.1.6 Version 4.1.4 & 4.1.5
    SAML 2.0 Yes Yes
    Single identity provider Yes Yes
    Multiple identity providers Yes No
    Identity federation Yes No
    SSO with LDAP Yes No

    SSO Compatibility

    Version 4.1.6 of the Code42 EDGE Platform introduced additional SSO-compatible components and is compatible with more identity providers than versions 4.1.4 or 4.1.5.

    Code42 EDGE Platform Version 4.1.6

    SAML 2.0 Identity Providers

    Code42 EDGE Platform version 4.1.6 has been tested with the following identity providers:

    Other SAML 2.0 identity providers that support HTTP POST binding may be compatible; however, Code42’s testing has been performed only with the above identity providers. 

    Code42 EDGE Platform Components

    For version 4.1.6, most Code42 EDGE Platform components bundled with the enterprise server support SSO.

    Compatible With SSO Incompatible With SSO
    • CrashPlan app for Windows, OS X, and Linux
    • SharePlan app for Windows and OS X
    • SharePlan app for iOS and Android
    • SharePlan web app
    • Administration console

    CrashPlan apps for iOS, Android, and Windows Phone

    Code42 EDGE Platform Version 4.1.4 & 4.1.5

    SAML 2.0 Identity Providers

    Code42 EDGE Platform version 4.1.4 and 4.1.5 has been tested with the following identity providers:

    Other SAML 2.0 identity providers that support HTTP POST binding may be compatible; however, Code42’s testing has been performed only with the above identity providers. 

    Code42 EDGE Platform Components

    For versions 4.1.4 and 4.1.5, the following components support SSO.

    Compatible With SSO Incompatible With SSO
    • CrashPlan app for Windows, OS X, and Linux
    • Administration console
    • SharePlan app for Windows and OS X
    • SharePlan app for iOS and Android
    • SharePlan web app
    • CrashPlan apps for iOS, Android, and Windows Phone

    Considerations

    Code42 Master Server
    • You must have an on-premises master server to use SSO.
    • 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 service provider-initiated SSO. The Code42 environment does not support 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 service provider), which then issues a SAML 2.0 AuthnRequest for the user to be delivered to the identity provider.
    • Your master server must be able to access the Identity Provider metadata file, which may be stored in one of the following locations:
      • On the identity provider
      • Locally on your enterprise server's file system
      • On a web server in your LAN
    • The master server's SSO entityID is generated based on the administration console Website protocol, host and port and Require SSL to access console fields. Do not modify these settings after configuring SSO.
    Authentication And User Management
    • Users that sign in with SSO must exist in your Code42 environment, and their usernames must match SSO. There are two ways to add users:
    • SSO provides user authentication but does not provide user management. A directory service provides user management.
    • Code42 EDGE Platform version 4.1.6 supports the following directory services for organizations that use SSO:
      • Local Code42 EDGE Platform directory
      • LDAP
    • Code42 EDGE Platform versions 4.1.4 and 4.1.5 support the local Code42 EDGE Platform directory for organizations that use SSO.
    Sign Off
    • The Code42 EDGE Platform does not handle 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.
    • When a user signs out of the SSO identity provider, he or she is not automatically signed out of the Code42 applications. There are two ways the user can be signed out of the Code42 applications:
      • An administrator can deauthorize the user's devices from the administration console.
      • The user can sign out of the Code42 applications.
    CrashPlan App
    • To use SSO for CrashPlan, you must deploy a customized CrashPlan app installer to your users.
    • 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.
    • The CrashPlan mobile apps on all platforms do not support SSO.
    Assistance With Single Sign-On
    Troubleshooting your authentication system is beyond the scope of our Customer Champions. For assistance with setting up single sign-on in your Code42 environment, contact sales about engaging our PRO Services team.

    System Properties Affecting SSO

    A number of system properties on the master server can be configured to control SSO behaviors. Version 4.1.6 has fewer SSO properties because username attribute mapping is configured in the administration console.

    Code42 EDGE Platform Version 4.1.6

    System Property Function Default
    b42.ssoAuth.identityProvider.metadataSyncHours Sets the polling interval for refreshing the identity provider metadata file (the enterprise server must be restarted after setting this property) 6 (units=hours)

    Code42 EDGE Platform Version 4.1.4 & 4.1.5

    System Property Function Default
    b42.ssoAuth.field.username Maps the SSO assertion attribute username field to a Code42 EDGE Platform user field uid
    b42.ssoAuth.field.firstname Maps the SSO assertion attribute firstname field to a Code42 EDGE Platform user field givenName
    b42.ssoAuth.field.lastname Maps the SSO assertion attribute lastname field to a Code42 EDGE Platform 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 (the enterprise server must be restarted after setting this property) 6 (units=hours)

    Setting A System Property Example Scenario

    To configure 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 following command:
      prop.set b42.ssoAuth.identityProvider.metadataSyncHours 2
      The following text appears:
      The system property has been set.
      Some system properties require a restart before they are recognized.
      b42.ssoAuth.identityProvider.metadataSyncHours=2
    3. If you modified the property b42.ssoAuth.identityProvider.metadataSyncHours, restart the enterprise server.

    Enterprise Server Log Messages

    Finding SSO 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: {}

    Increasing SSO Log Detail

    You can see more detail by increasing the logging level for SSO errors.

    1. Enter the administration console CLI by double-clicking the logo in the upper-left corner.
    2. Enter the following command:
      log com.code42.ssoauth TRACE
      • The complete list of debugging levels is: ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and OFF.
      • The default level is INFO.
    3. After debugging is complete, restart the enterprise server or reset the debugging level to INFO with the command:
      log com.code42.ssoauth INFO

    SSO Configuration Instructions

    Refer to the instructions for your Code42 EDGE Platform version to configure SSO:

    External Resources

    You must to post a comment.
    Last Modified
    10:10, 19 Dec 2014

    Tags

    Classifications

    Administrator Guide