Single Sign On (SSO): Overview

Why Single Sign On?

Single sign-on (SSO) is a technology allowing simultaneous log on to multiple independent but related software systems. A trend in technology in recent years is for organizations to have a number of specialized systems performing diverse functions, each requiring a login with different standards of authentication. SSO allows a user to log in once and gain access to multiple systems without having to manually log on to each. SSO typically relies on a special protocol known as Lightweight Directory Access Protocol (LDAP), with corresponding databases stored on servers. Login credentials are usually stored on a central server and then, following successful login, forwarded to other entitled systems depending on the user’s access level.

Advantages

SSO has a number of advantages:

Lower maintenance and increase usability

SSO means fewer passwords to remember and maintain.

• Faster login time due to not having to log in to multiple systems.

• Fewer forgotten user IDs and passwords, since there are fewer to remember. Reduced burden on IT resources for password creation and reset requests.

• Reduced “password fatigue” from having to remember multiple usernames and multiple passwords due to different password requirements and conventions across different systems.

• Increased overall productivity and lower support costs due to easier password management.

Increase security

SSO is actually more secure than relying on multiple logins.

• A proper SSO setup involves storing passwords in a central, fortified location rather than distributed across multiple systems with varying methodologies and strengths. Centralization provides the following advantages:

  • Easier management of credentials, since they are in one location.

  • Fewer locations storing passwords. Since most users rely on the same password for multiple logins, a breach in one system can lead to a breach in others in multi-login configurations.

  • Better auditing with a built-in audit trail documenting credential use, including any breach.

Technology

The preferred methodology for implementing SSO is via the Security Assertion Markup Language (SAML) version 2.0 protocol. SAML uses eXtended Markup Language (XML) to exchange user security information between an enterprise and a service provider, relying on W3C XML encryption and service-provider initiated web browser single sign-on exchanges. This method has become the preferred choice in the industry after the introduction of SAML 2.0 in 2005.

How it works

SSO eliminates the need for multiple independent domains. The “primary” domain contains all necessary credentials for any subsidiary domain to which the user might require access. Secondary domains “trust” the primary domain. Once logged in to the primary domain, credentials are “passed on” to the subsidiary domains as needed.

Ripple Treasury and SSO

Ripple Treasury uses a SAML 2.0 SSO implementation using the Identity Provider (IDP) initiated model rather than the Service Provider (SP) model. SSO may be configured for login and approval functionality for payments and models. In SSO, the user authenticates against a portal page on the client-side. Upon successful login, the user’s credentials are redirected to a page on Ripple Treasury which verifies the SAML credentials and logs the user into the cloud-based application.

SAML includes techniques (NOT BEFORE, NOT AFTER timestamps, etc.) to verify the message is from the identity provider. Please note that Symantec VIP Two-Factor Authentication (2FA) may be combined with Ripple Treasury SSO. By providing an additional log in credential unique to each individual, 2FA provides much greater security than SSO or 2FA alone. For more information on Ripple Treasury 2FA, refer to Symantec VIP Multi-factor Authentication: Overview.

Shared responsibilities (Ripple Treasury and you):

• We’ll create one custom attribute in the SAML message set to a fixed string value identifying the client company (clientID in gold). This clientID value doesn't need to be changed by you. Please leave it as is, or SSO may not function properly.

• Please note that COMPANY_ID (in red) should be replaced with your Company ID value (also known as the clientID attribute value):

• We’ll need the public key for the certificate used to sign the SAML message (in order to verify the signature).

• We’ll provide, at implementation time, the destination URL to which the portal will connect.

Note: the OPERATOR_ID value (in red) is passed to Response\Assertion\Subject\NameID:

Client responsibilities:

• Set up the portal and user validation.

Copyright 2025 Ripple Labs Inc.