How Do The Three Flavors Of SSO Work?

How do the following flavors of SSO work?:

  1. SAML.
  2. WS-Federation Services.
  3. WS-Federation Services with SAML.

How Plutora AD (SAML) Integration SSO works

If your company is set up for SSO, you will be directed to your company’s SSO page and back to Plutora when you log in.

Plutora supports the SAML 2.0 protocol and works with major SAML providers such as ADFS and Ping Federate.

See this industry standard example of a SAML AuthNRequest here.

Logging into Plutora with SAML 2.0 Assertion SSO involves the following steps:

Plutora AD (SAML) Integration Overview

  1. A user (who is not logged into Plutora) makes a request to https://<<Yourdomain>> 
    The user might be following a bookmark, clicking on a page link in an email or allowing their browser to autocomplete the URL.
  2. redirects the user to their SAML Identity Provider.
    To redirect the user,

    1. Detects that user lacks a session cookie and needs to authenticate.
    2. Detects the user’s organization from their subdomain. For example, Home is the organization in
    3. Sends a SAML Request and HTTP parameter (called RelayState and containing the user’s requested resource location, for example, a particular page in <<YourURL>>) to the Identity Provider over SAML Protocol.
  3. The user authenticates (logs in) using their Identity Provider:
    1. The Identity Provider performs the authentication, giving the customer complete control over the authentication process.
    2. A variety of popular techniques may be used, such as LDAP, a web access management system, Integrated Windows Authentication, or a 2­factor system such as SecurID.
  4. Once authenticated, the Identity Provider sends a SAML assertion response back to through the user’s browser.
  5. processes the SAML assertion and logs the user in.
    The digital signature applied to the SAML Response verifies that the message is from the customer, at which point the user is authenticated. The user is granted a session cookie and redirected to their originally requested page.


What Plutora needs from the customer

SAML Assertion Set Up

SAML Request Assertion

An example SAML Request Assertion that will come from Plutora will look like this:

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" 
Destination="[SSOloginUrl]" ID="af24910b2-a6b2-4f00-bf40-22b9e893697d" 
IsPassive="false" IssueInstant="2017-02-03T17:26:12.497Z" Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">[PlutoraDomain]
SAML Response Assertion

The SAML Response Assertion should look like this:

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid- format:unspecified">
[email address]</saml:NameID>

The NameID must be an email address. Preferably, the NameID format should be: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Additional Attributes

Customers should send their exact given name and surname as Attributes with the attribute names being ‘Given-name’ and ‘Surname’. These are not standard SAML attributes and will need to be added as custom attributes on the IdP system (see your IdP support documentation for how to address this).

Example SAML Response
<samlp:Response Version="2.0" ID="dp8VEO2YEGI4_Su.e2nBaOAa63R" IssueInstant="[IssueDate]" Destination="[destinationUrl]" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">[issuer url]</saml:Issuer>
<ds:Signature xmlns:ds="">
<ds:CanonicalizationMethod Algorithm=""/>
<ds:SignatureMethod Algorithm=""/>
<ds:Reference URI="#dp8VEO2YEGI4_Su.e2nBaOAa63R">
<ds:Transform Algorithm=""/>
<ds:Transform Algorithm=""/>
<ds:DigestMethod Algorithm=""/>
<ds:SignatureValue>AoiHDNAkcWGKh4aPPW+krGLXgFXQ7MH9OJ/cPbDhyS6RAHyGWn7XTZBNXgNSMu84ICjawQ6EqG93 IHxMlG2j45BGw26pju1gAn5F7v/ZWUCbAldsUnm06Nu5nMdJSb4GbnfiCpp44DJ8KQTwrFPrst6E mvHqAx+FZfLcSxPyFhp9UlVMX+aV8mZNr9emsE4OngPMXjAlgbCHC+r9dfxDLQ1N2JMmdTAVJLha 0hA0+dHcwt+jCbId+h2ahlbqXKztzfvfxMIZjAUxdJSMgWf7H1ExEqLx4J12olD1nSMlq5Hk2M7/ zpGz/RCeOFUeaF0SgfxBO1v3rlB7PMk41AYb6Q==</ds:SignatureValue>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<saml:Assertion ID="ksP56rcU32YDrCwm9pCCnEUVm06" IssueInstant="[IssueDate]" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer>[issuer url]</saml:Issuer>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[EmailAddress]</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Recipient="[destinationUrl]" NotOnOrAfter="[NotOnOrAfterDate]"/>
<saml:Conditions NotBefore="[NotBeforeDate]" NotOnOrAfter="[NotOnOrAfterDate]">
<saml:AuthnStatement SessionIndex="ksP56rcU32YDrCwm9pCCnEUVm06" AuthnInstant="[IssueDate]">
<saml:Attribute Name="Given-name" NameFormat="">
<saml:AttributeValue xsi:type="xs:string" xmlns:xs="" xmlns:xsi="">[FirstName]</saml:AttributeValue>
<saml:Attribute Name="Surname" NameFormat="">
<saml:AttributeValue xsi:type="xs:string" xmlns:xs="" xmlns:xsi="">[Surname]</saml:AttributeValue>


WS-Federation has the following authentication steps:

  1. The user goes to the login page of the site.
  2. The site sends query parameters in a Request Security Token (RST) to the identity provider.
  3. The identity provider verifies the user’s identity and sends a signed Request Security Token Response (RSTR) back to the website.

WS-Federation with SAML has the following authentication steps:

  1. The user goes to the login page of the site.
  2. The site generates a SAML request, then redirects the user to the SSO Login URL.
  3. The SAML request goes to the identity provider, which verifies the user’s identity.
  4. The identity provider sends a SAML request inside a Request Security Token Response (RSTR) to the website.
  5. The website receives the response and logs the user in.

Was this article helpful?

0 found this helpful.