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:
Most common SAML bindings are:
|
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
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
- User A clicks on Platform URL.
- User A lands at Sherpany’s site (Protected Page).
- 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
- User A gets authenticated at IdP site.
- 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.
- Sherpany’s Federation system decrypts and validates assertion.
- Sherpany’s Federation system sends user A to Sherpany Platform URL based on RelayState.
- User A gets logged into Sherpany’s Platform.
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 URL | Optional. 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 Certificate | x509cert | A .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 | |
| Y | Must 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.