To make it easier to manage users and security for organizations who have already implemented Single Sign On (SSO), we now support SAML 2.0 for SSO with Pipeliner Cloud.

SAML Web Browser Single-Sign-On (SSO) enables web applications to delegate user authentication to a SAML identity provider instead of a configured user registry.

NOTE: Once enabled, SSO applies to an entire subscription, not an individual Pipeliner space.

NOTE: This article is intended only for Pipeliner/IT Administrators who have network/domain admin access.

Single Sign-On (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The service authenticates the end-user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session. On the back end, SSO is helpful for logging user activities as well as monitoring user accounts.

Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information.

An Identity Provider (abbreviated IdP) is a system entity that creates, maintains, and manages identity information for principals (users) while providing authentication services to relying applications within a federation or distributed network.

Identity providers offer user authentication as a service. Relying party applications, such as web applications, outsource the user authentication step to a trusted identity provider. Such a relying party application is said to be federated, that is, it consumes federated identity.

An identity provider is “a trusted provider that lets you use single sign-on (SSO) to access other websites”. SSO enhances usability by reducing password fatigue. It also provides better security by decreasing the potential attack surface.

Active Directory Federation Services (ADFS), a software component developed by Microsoft, can run on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries. It uses a claims-based access control authorization model to maintain application security and to implement federated identity.

Claims-based authentication involves authenticating a user based on a set of claims about that user's identity contained in a trusted token. Such a token is often issued and signed by an entity that is able to authenticate the user by other means, and that is trusted by the entity doing the claims-based authentication It is part of the Active Directory Services.

A Relying Party (RP) is a computer term used to refer to a server providing access to a secure software application.

LDAP (Lightweight Directory Access Protocol) is a software protocol for enabling anyone to locate organizations, individuals, and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet. LDAP is a "lightweight" (smaller amount of code) version of Directory Access Protocol (DAP).

Sign-in into your Customer Portal and then click on the Single Sign-On (SSO) tab.
​

Click on the Sign In menu and then the "Single Sign On" tab and enable "Custom SSO SAML IDP" and click on "+ Add SAML" ⤵

Name your “IDP” and then select from one of the metadata options to import ⤵

If you select from “ADFS URL”, input the link to your ADFS site ⤵

OR browse to an existing “XML” file ⤵

To create a dedicated XML file for your organization use this link:

NOTE: replace "{{domain.name}}" with your ADFS domain and paste into the from ADFS URL option.

NOTE: you will only be able to generate the file using the URL if your domain is public.

If you only have access to the domain when authenticated inside your network, paste the URL above into a new browser window instead. This will generate the "FederationMetadata.xml" file in your Downloads folder. Select the From File option and browse to the file ⤵

NOTE: If you already have a file, you can paste into "as a plain XML" ⤵

Click on “Next” and this will generate a URL that you need to enter into your ADFS (Active Directory Federation Services) ⤵

Follow the process and finish setting up “Relying Party Trust” as detailed in the next section and then come back to your Workspace and click Next.

Open your ADFS Manager.

Select “Trust Relationships” › “Relying Party Trusts” › “Add Relying Party Trust” ⤵

Click on “Start” ⤵

Paste in the URL of the dedicated XML file that you created for your domain ⤵

Click “Next” and then name the new “Relying Party Trust” — this name is used for you to be able to recognise the party so it makes sense to name it “Pipeliner” ⤵

Click on “Next”, leaving the following sections on their default settings ⤵

Once finished, click “Next” to “Edit Claim Rules”.
Click on “Add Rule” ⤵

Keep the “Claim Rule Template” settings as the default “Send LDAP Attributes as Claims” ⤵

Click on “Next” and make sure you select “Active Directory” from the “Attribute Store” dropdown and then select “Email Addresses” in LDAP Attribute and in “Email Address” in “Outgoing Claim Type”.

NOTE: the AD email address used by the user has to be an exact match to the email address used for the Pipeliner login in order for SSO to work ⤵

Click on “Finish” to complete the “ADFS Server” configuration.

Go back to your Pipeliner workspace and click on “Next” to generate a URL that you can use to test your login ⤵

Copy the link and paste into a new browser session or an Incognito window.

You’ll be prompted to sign in again but now using your Active Directory Domain Credentials ⤵

Once you can sign in, the SSO configuration is complete and all your Pipeliner users will now be authenticated against ADFS.

Click on "Apply and Finish" ⤵

Q › What credentials do they use if my user's log in to Pipeliner outside of our network (e.g. from home or from an Internet cafe)?
​A › This depends on whether your users are able to authenticate outside of your network. If you’re using Azure (for example), then all users will log in to Pipeliner from any location using the same AD login (email address) and password but if your AD requires users to be authenticated within your network, users will need to use a VPN connection to first authenticate before being able to login to Pipeliner.

Q › What SSO applications do you support?
​A › Microsoft or Google active directory applications supporting SAML 2.0.