Support Center

Single Sign-On (SAML 2.0)

In this article you will learn :

  • What is Single Sign-on (SSO) based on SAML
  • Benefits of SSO
  • SAML terminology
  • SSO configuration details

Preface

Single sign-on (SSO) lets users access authorized network resources with one login. You validate usernames and passwords against your corporate user database or other client apps rather than Sherpany managing separate passwords for each resource.

The information provided in this document allows partners to set up their federation servers to initiate federated identity management with Sherpany. 

REQUIRED Package: Enterprise


Benefits of SSO

Implementing SSO brings several advantages to your org.

  • Reduced administrative costs - With SSO, users memorize a single password to access network resources and external apps and Sherpany. When accessing Sherpany from inside the corporate network, users log in seamlessly and aren’t prompted for a username or password. When accessing Sherpany from outside the corporate network, the users’ corporate network login works to log them in. With fewer passwords to manage, system admins receive fewer requests to reset forgotten passwords.
  • Leverage existing investment - Many companies use a central LDAP database to manage user identities. You can delegate Sherpany authentication to this system. Then when users are removed from the LDAP system, they can no longer access Sherpany. Users who leave the company automatically lose access to company data after their departure.
  • Time savings - On average, users take 5–20 seconds to log in to an online app. It can take longer if they mistype their username or password and are prompted to reenter them. With SSO in place, manually logging in to Sherpany is avoided. These saved seconds reduce frustration and add up to increased productivity.
  • Increased user adoption - Due to the convenience of not having to log in, users are more likely to use Sherpany regularly. For example, users can send email messages that contain links to information in Sherpany, such as records and reports. When the recipient of the email message clicks the links, the corresponding Sherpany page opens.
  • Increased security - All password policies that you’ve established for your corporate network are in effect for Sherpany. Sending an authentication credential that’s only valid for a single time also increases security for users who have access to sensitive data.


Federation Summary

Federated identity management (or “identity federation”) enables enterprises to securely exchange identity information across Internet domains. Federation also enables secure SSO between distinct business units within a single organization. As organizations grow through acquisitions, or when business units maintain their own user repositories and authentication mechanisms, a federated solution to secure SSO is desirable.

Security Assertion Markup Language (SAML) is an XML-based solution for exchanging user security information between a SAML identity provider and a SAML service provider. SAML 2.0 supports W3C XML encryption and service provider-initiated web browser single sign-on exchanges. A user wielding a user agent (usually a web browser) is called the subject in SAML-based single sign-on. The user requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the user, issues an authentication request to a SAML identity provider through the user agent. The identity provider is the one that provides the user credentials. The service provider trusts the user information from the identity provider to provide access to its services or resources.


Federation Terminology

Term
Description

Single Sign-On (SSO)

Single Sign-On (SSO) is a method of leveraging security tokens to indicate authentication between multiple domains, rather than requiring each member of a security domain to re-verify authentication credentials. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

Identity Provider (IdP)

An entity that makes various claims about an entity (ex. End User) to SPs. SPs take these claims and make a decision about whether to act on them as true. With SSO, these claims are meant to provide the service with enough information to consider a user authenticated.

Your organization provides the IdP.

Service Provider (SP)

An SP is a consumer of claims from an Identity Provider. Based on the evaluation of the claims as well as any pre-existing relationship between the service and the Identity Provider, the information conveyed can be used for authentication, authorization, and to provide the claims as additional data into other business processes. Within the definitions of SAML, an SP is merely an entity providing a service to others, while an Identity Provider is the “SAML authority,” is a system entity that authenticates a user, or “SAML subject,” and transmits referential identity information based on that authentication. 

Sherpany is the SP.

Assertion/Token

Assertions are XML documents sent from an IdP to an SP. Each assertion contains identifying information about a user who has initiated a SSO request. 
Bindings

A SAML binding describes the way messages are exchanged using transport protocols.

Some common SAML 2.0 bindings are:

  • HTTP POST – Describes how SAML messages are transported in HTML form-control content, which uses a base-64 format.
  • HTTP Artifact – Describes how to use an artifact to represent a SAML message. The artifact can be transported via an HTML form control or a query string in the URL.
  • HTTP Redirect – Describes how SAML messages are transported using HTTP 302 status-code response messages.
  • SOAP – Describes how SAML messages are to be transferred across the back channel.


Most common SAML bindings are:

  • HTTP POST – Describes how SAML messages are transported in HTML form-control content, which uses a base-64 format.
  • HTTP Artifact – Describes how to use an artifact to represent a SAML message. The artifact can be transported via an HTML form control or a query string in the URL.


SAML

MyDomain

MyDomain is required for setting up a single sign-on.

Using MyDomain, Sherpany defines a subdomain for enterprise customers. The subdomain name appears in all org URLs and replaces the general domain app.sherpany.com. For example, you can brand your URL by naming the subdomain with your company name, https://customdomain.my.sherpany.com/.

In SAML 2.0, the start page is the page the user attempted to access before they were authenticated. The SAML 2.0 start page must support Sp-init single sign-on.

If you are using SAML 2.0, you can also use the RelayState parameter to control where users get redirected after a successful login.

Methods

IdP Initiated SSO: Post
In this scenario, a user is logged on to the IdP and attempts to access a resource on a remote SP server. The SAML assertion is transported to the SP via HTTP POST.

Tip

If a user attempts to access Protected Resources without being first authenticated at the IdP site, Sherpany will simply redirect the user (http code 302 - NOT truly SP-Initiated SSO) to the IdP’s external SSO page for authentication purposes

DataFlow
  1. User A clicks on Platform URL.
  2. User A lands at Sherpany’s site (Protected Page).
  3. Sherpany’s application redirects user A (http code 302 – NOT SP-Initiated SSO), back to IdP’s external SSO login page.

    Important

    Sherpany’s application appends RelayState parameter to the client’s redirect connection URL

  4. User A gets authenticated at IdP site.
  5. IdP’s SSO system constructs SAML assertion and sends user A to Sherpany’s ACS (Assertion Consumer Service), along with RelayState parameter appended to the assertion.
  6. Sherpany’s Federation system decrypts and validates assertion.
  7. Sherpany’s Federation system sends user A to Sherpany Platform URL based on RelayState.
  8. User A gets logged into Sherpany’s Platform.
SP Initiated SSO: Post / Post
In this scenario a user attempts to access a protected resource directly on an SP Web site without being logged on. The user does not have an account on the SP site, but does have a federated account managed by a third-party IdP. The SP sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user’s browser via HTTP POST. 


Example SAML Assertions

Share the example SAML assertions with your identity provider so they can determine the format of the information Sherpany requires for successful single-sign on. The assertion must be signed according to the XML Signature specification, using RSA and either SHA-1 or SHA-256.

SAML 2.0:

<saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">user101@sherpany.com</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2008-06-26T02:44:24.173Z" Recipient="http://localhost:9000"/>
    </saml:SubjectConfirmation>
</saml:Subject>


Configuration Details

Configuration on IdP

Depending on the type of the idP application you're working with, more or less configuration needs to be done. These is an overview of configurations that need to be done on your IdP with values provided by the Sherpany SP.


Name
Description
Example value
Assertion Consumer Service URL

Also known as Post-back URL or Callback URL.

This is where the IdP will be POSTing assertions.

https://customdomain.my.sherpany.com/auth/sso/saml/?acs&provider=customerx
Application Callback URLOptional. Endpoint where information about the SP can be queried.https://customdomain.my.sherpany.com/auth/sso/saml/metadata/?provider=customerx
Single Logout Service URL
https://customdomain.my.sherpany.com/auth/sso/saml/?sls 


Configuration on SP

These are configurations that need to be set by Sherpany on our SP and need to be provided by your IdP.


Preferred configuration method

Ideally a metadata.xml file (or the metadata url where the configuration xml can be downloaded) is provided to sherpany which contains all the needed configuration. Most IdP allow exporting such a file.

Name
Description
Example value
entityID
https://idp.example.com/saml/sherpany 
IdP Certificatex509certA .pem file.
IdP Login URL and Binding

https://idp.example.com/saml/sherpany 

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect


IdP Logout URL and Binding

https://idp.example.com/saml/sherpany/logout 

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect



Attributes

Field Label

Field Code

Required

Client Attribute Name (alphanumeric)



NameID



Y

Must be unique per IdP. 

A unique identifier that does not change over time. 

Used to identify a user.

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified



EmailemailYMust be globally unique on sherpany.

First Name

firstName

Y

firstName

Last Name

lastName

Y

lastName


Just-in-Time Provisioning for SAML

With Just-in-Time provisioning, you can use a SAML assertion to create users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. For example, if you recently added an employee to your organization, you don't need to manually create the user in Sherpany. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort with on-boarding the account.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.