Single Sign On (SSO)

Plutora supports Single Sign On (SSO), a session/user authentication process that allows users to enter one name and password to access multiple applications.

See this industry standard example of a SAML AuthNRequest here.

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.

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>>.plutora.com. 
    The user might be following a bookmark, clicking on a page link in an email or allowing their browser to autocomplete the URL.
  2. Plutora.com redirects the user to their SAML Identity Provider.
    To redirect the user, Plutora.com:

    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 http://home.plutora.com.
    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 an 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 plutora.com through the user’s browser.
  5. Plutora.com 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.

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]
</saml2:Issuer></saml2p:AuthnRequest>
SAML Response Assertion

The SAML Response Assertion should look like this. Note: the Claimstype Identifier must be an email address:

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid- format:unspecified">
[email address]</saml:NameID>
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="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#dp8VEO2YEGI4_Su.e2nBaOAa63R">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>aB9QdcKpwowV7/fwK+/iZDcOfh4enzccUSvBs0mFtcs=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>AoiHDNAkcWGKh4aPPW+krGLXgFXQ7MH9OJ/cPbDhyS6RAHyGWn7XTZBNXgNSMu84ICjawQ6EqG93 IHxMlG2j45BGw26pju1gAn5F7v/ZWUCbAldsUnm06Nu5nMdJSb4GbnfiCpp44DJ8KQTwrFPrst6E mvHqAx+FZfLcSxPyFhp9UlVMX+aV8mZNr9emsE4OngPMXjAlgbCHC+r9dfxDLQ1N2JMmdTAVJLha 0hA0+dHcwt+jCbId+h2ahlbqXKztzfvfxMIZjAUxdJSMgWf7H1ExEqLx4J12olD1nSMlq5Hk2M7/ zpGz/RCeOFUeaF0SgfxBO1v3rlB7PMk41AYb6Q==</ds:SignatureValue>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<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:Subject>
<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:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="[NotBeforeDate]" NotOnOrAfter="[NotOnOrAfterDate]">
<saml:AudienceRestriction>
<saml:Audience>Plutora</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement SessionIndex="ksP56rcU32YDrCwm9pCCnEUVm06" AuthnInstant="[IssueDate]">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="Given-name" NameFormat="http://schemas.microsoft.com/LiveID/Federation/2008/05">
<saml:AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">[FirstName]</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="Surname" NameFormat="http://schemas.microsoft.com/LiveID/Federation/2008/05">
<saml:AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">[Surname]</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

The minimum requirements to activate SSO are the Use SAML Request checkbox and the SSO Login URL.

Administrators should use the Login Settings Customization to redirect users to the SSO login page every time they login.

SSO customization March 2017

  1. Go to Settings > Customization.
  2. Click Login Settings.
  3. Click to select the following as required:
    Before selecting the Auto redirect to SSO login page checkbox, make sure that the connection is working.

    1. Auto redirect to SSO login page: Click to select the checkbox to bypass the Plutora login page and always redirect the user to the SSO Login URL.
      • If this checkbox is not selected, but Use SAML Request checkbox is, users will be directed to the Plutora login page, where they can click the SSO Login button.
        Plutora login page red arrow
    2. Use SAML Request: Click to select the checkbox.
      The minimum requirements to activate SSO are the Use SAML Request checkbox and the SSO Login URL.
    3. Sign SSO Request: Click to select the checkbox. (Optional.) Unsigned requests use a GET and signed requests use a POST.
      1. To upload an SSO certificate:
        1. Click Upload SSO Certificate.
        2. Click to select the certificate file.
        3. Click Open.
    4. SSO Login URL: Type the URL.
      • The user must be in the correct internal network for the URL to work.
    5. SSO Logout URL: Type the URL. (Optional.)
      • Users will be directed to this URL after they log out.
      • If no URL is entered, users will be logged back into Plutora.
      • The default Plutora log out page can be used:
        • https://[YOUR-DOMAIN].plutora.com/User/Logoff
  4. Click Submit.
    The yellow Your changes have been saved pop up opens and closes.
    If you click away from the Customization page without clicking Submit, your changes will not save.
    Users who log into Plutora for the first time using SSO are granted read-only access. Administrators must update their account to give them the access they need. The new User Management entity in Email Template Wizard Customization can send administrators notifications when a new SSO account is created.

 

Back to the top arrow

Was this article helpful?

0 found this helpful.