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 you are using WS-Federation Services, please contact our Support Staff so they can create a configuration file.

To set up WS-Federation Services on Plutora, once the configuration file is created:

  1. Go to Settings > Customization.
  2. Click Login Settings.
  3. Click to select the Enable SSO Login checkbox.
  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 access that depends on the Requestor User Role. 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.

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.

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 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.

 

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]
</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>

 

How to update your Plutora Login Settings for SSO

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 log in.

For the other settings on the Login Settings page, see Login Settings.

Login Settings SSO Sept 1 2017 smeared

  1. Go to Settings > Customization.
  2. Click Login Settings.
  3. Click to select the Enable SSO Login checkbox.
  4. Click to select the following as required:
    Do not select the Auto redirect to SSO login page checkbox until you have confirmed that the connection is working. Otherwise, users will be unable to log into Plutora.

    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.
    2. Use SAML Request: Click to select the checkbox.
      • If the Auto redirect to SSO login page checkbox is not selected, but Use SAML Request checkbox is selected, users will be directed to the Plutora login page, where they can click the SSO Login button.
        Plutora login page red arrow
    3. Sign SSO Request: Click to select the checkbox. (Optional.)
      • Unsigned requests use a GET and signed requests use a POST.
      • Download the public certificate for signature verification on your SSO server: Plutora now has a full certificate embedded to be used for signing SSO authentification requests. Download and load the public certificate and load it into your SSO system so you can validate the signature of the authentification requests.
    4. Validate SSO response: To be used with the certificate uploaded below.  
    5. Upload certificate for validating response signatures:
      1. To obtain a certificate or install Plutora’s public certificate:
      2. To upload a certificate:
        1. Click Upload certificate for validating response signatures.
          This button replaces the previous Upload SSO Certificate button.  
        2. Click to select the certificate file.
        3. Click Open.
        4. Type the password that was used when generating the certificate.
          If the certificate is public and doesn’t require a password, click OK without typing a password.
        5. Click OK.
          Once the certificate is uploaded, the message under Validate SSO response will change from There has not been a certificate uploaded yet to Certificate has been uploaded.
    6. SSO Login URL: Type the URL.
      • The user must be in the correct internal network for the URL to work.
    7. 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
  5. 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 access that depends on the Requestor User Role. 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.