Login Settings Customization (SSO)


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


To be able to access the ‘Customization’ feature, you must have ‘Access Customizations’ User Permission.

Settings  > Customization

Advantages of SSO 

  • You use and store their username and password for many websites with a single, secure and trusted identity provider.
  • It takes less time for you to log into a new website. The identity provider’s username and password are all you need, instead of having to sign up with your name and contact details from scratch and verify your email.
  • You know what information is being shared.
  • You only have to remember one username and password to access many websites.

Setting Up SAML

  1. Go to Settings  > Customization > Site Settings.
  2. Click Login Settings.
  3. Click to select the Enable SSO Login checkbox:

Enable SSO Login makes the SSO Login button appear under the Plutora login form.

Select the following as required:

Auto redirect to SSO login page

Do not select the Auto redirect to SSO login page checkbox until you have confirmed that the connection is working. If the connection is not working, go directly https://YourCompanyName.plutora.com/login to login.

Click to select the checkbox to bypass the Plutora login page and always redirect the user to the SSO Login URL.

If Auto redirect to SSO login page is selected but the Logout URL is not set, when users log out of Plutora or Plutora Test, they will be immediately logged back in again.

Use SAML Request

Click to select the checkbox to use the SAML settings on this page:

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.

If the Use SAML Request checkbox is unselected, the system will attempt to log in via a pre-configured WS-Federation module and will fail.

Combined Issuer

Click to select the checkbox to enable SSO credentials for both Plutora and Plutora Test:

When enabled: The authentication request Issuer will be https://idp-{region}.plutora.com and the AssertionConsumerServiceUrl will be https://idp-{region}.plutora.com/api/Login/ExternalLoginResponse. This will allow customers to use SSO with Plutora and Plutora Test, provided they have updated their SSO server settings.

When disabled: The authentication request Issuer will be the site making the request – either https://{subdomain}.plutora.com or https://{subdomain}.plutoratest.com and the AssertionConsumerServiceUrl will also be the site making the request – either https://{subdomain}.plutora.com or https://{subdomain}.plutoratest.com. This will allow customers to continue to use SSO with Plutora without changing their SSO server settings.

If they add https://{subdomain}.plutoratest.com with the right settings to their SSO server, they will also be able to use Plutora Test (however this isn’t the intention. the intention is that they should enable the option and update their SSO server settings to handle the new Issuer above).

Login URL

Type the URL that the user will be sent to when they log in via SSO.

Sign Login Request

Click to select the checkbox:

If selected, the authentication request to the SSO server will be signed with Plutora’s private key.

Customers should download the public certificate and use it on their SSO server to validate the signature in the login request.

If selected, the authentication request will be made using a POST method, otherwise, it will be made using a GET method.

Validate Login Response

Click to select the checkbox:

  • If selected, upon receiving an authentication response from the customer’s SSO server, the Plutora authentication system will check the signature in the response and validate it using the “Response Validation Certificate” setting below.
  • If the response is not signed, the authentication will fail. If the response is signed but the signature is invalid, the authentication will fail.
  • Validate Login Response checkbox should be selected. If left unselected, an unauthorized user could forge an authentication response and gain access

Click to save your changes.
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.

User Role SAML Assertion Examples

User Roles can be set via SSO. Plutora will attempt to match User Roles to the ones on file. If no match is found, new users will be given the SSO Requestor Role and existing users will keep the roles that they already have.

Any of the following Name values can be used:

  • UserRoles.
  • Roles.
  • UserGroups.
  • Groups.

Single Attribute with Single AttributeValue

The AttributeValue can be comma-separated to add multiple roles to a user.

         <saml:Attribute Name="Roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue>Role Name</saml:AttributeValue>

Multiple Attribute with Single AttributeValue

         <saml:Attribute Name="Roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue>Role Name #1</saml:AttributeValue>
         <saml:Attribute Name="Roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue>Role Name #2</saml:AttributeValue>

Single Attribute with Multiple AttributeValue

         <saml:Attribute Name="Roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue>Role Name #1</saml:AttributeValue>
            <saml:AttributeValue>Role Name #2</saml:AttributeValue>

Portfolio Association for SSO Users Examples

You can set the user Portfolio Associations via SSO. Plutora will attempt to match Portfolio Association to the ones listed in the SAML response. 

If the Portfolio Association attribute in the SAML response is left empty or if the Portfolio Association listed in the SAML response does not match any existing Portfolio Association in Plutora, Plutora will assign the top-level Portfolio Association to the new users but will not make any updates to existing users so this can be managed within Plutora’s user management.

Any of the following Name values can be used:

  • Organization
  • Organisation
  • PortfolioAssociation
  • Portfolio Association
  • Portfolio

Single Attribute with Single AttributeValue

Only one AttributeValue can be used to set Organization for user.

         <saml:Attribute Name="Organizations" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
         <saml:AttributeValue>Organization Name</saml:AttributeValue>

Enable Two-Factor Authentication

See Enable Two-Factor Authentication in Setting Up Two-Factor Authentication.

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://<>.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 <>) 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 Request Assertion

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


SAML Response Assertion

The SAML Response Assertion should look like this:

[email address]

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

User Roles can now be set via SSO.

The following attribute Names (case insensitive) can be used to set User Roles:

  • UserRoles.
  • Roles.
  • UserGroups.
  • Groups. 

Plutora will attempt to match User Roles to the ones on file. If no match is found, new users will be given the SSO Requestor Role and existing users will keep the roles that they already have

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: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:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <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="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 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>

Related Articles


Be the first to find out about new features. Subscribe to the Release Notes email.

Was this article helpful?

Thanks for your answer!