Configuring SAML Single Sign On

Note: Single Sign-on may not be available in your plan. Please contact your CSM to learn more.


Introduction

Using SAML, you own the entire login process, and your advocate will never see the Influitive login screen when trying to access your AdvocateHub. Attempts to access the AdvocateHub sign-in page are redirected to your company website where advocates sign in. If they've previously signed into your website and a cookie exists on their browser, then the AdvocateHub will verify their login with your website behind the scenes. In that case the advocate will be automatically verified and directed into your AdvocateHub. It is important to understand that once this is setup, anybody in your system can access and sign up to the hub.

Note: For corporate users, you will need to create their accounts in the hub first with a matching email address under Settings > System > User Management. Once the administrator account is created through the hub, that administrator should be able to login through your SSO page.


Authentication Flow

Influitive offers SSO SAML 2.0. Let's have a look at the general flow of how we expect this to work;
  1. The user requests access to Influitive. The request is redirected to the Identity Provider to handle authentication.
  2. If the user is not already logged on to the IdP site or if reauthentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.
  3. Information about the user may be retrieved from the user profile in the Identity Provider for inclusion in the SAML exchange. (These attributes are predetermined as part of the federation agreement between the IdP and the SP)
  4. The IdP’s SSO service returns a SAML response containing the authentication assertion and any additional attributes to Influitive and Influitive logs the user in.
An example;
An example in our case would be the following: The advocate attempts to access a resource on the SP (<yourhub>.influitive.com or Influitive custom domain). However, they do not have a current login session on this site and their federated identity is managed by their IdP. So, now they are sent to the IdP to log on (Endpoint URL) and the IdP provides a SAML web SSO assertion for the user's federated identity back to the SP.
For this specific use case, the HTTP Redirect Binding is used to deliver the SAML <AuthnRequest> message to the IdP and the HTTP POST Binding is used to return the SAML <Response> message containing the assertion to the SP.

Note: Influitive does support SP-Initiated SAML SSO

Note: Influitive cannot act as the IdP


Configuring your IdP (Identity Provider)

You must send the following attributes to us in order for us to identify the user who is trying to login:
  • First Name
  • Last Name
  • Email Address (Unique Identifier by default. If you would like to use a different value to identify users please see the SSO Identifier Field section below)
  • Company (Optional)
  • Title (Optional)
Although not an attribute it is important to note if you are using the optional "Audience" tags, you must include Influitive-AdvocateHub as a valid audience
The attributes should be located in the assertion and be in the following format:

<saml:AttributeStatement>

<saml:Attribute Name="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xsi:type="xs:string">John</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xsi:type="xs:string">Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name="Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xsi:type="xs:string">johndoe@example.com</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

Direct the user this URL
  • https://yourhub.influitive.com/saml/consume

Note: If you have a custom domain in your Hub, please direct users to your custom domain URL

  • https://customdomain/saml/consume

Configuring your AdvocateHub

Navigate to Settings > System > Login/Security and scroll down to the Single Sign-On Section. Here you will need to select the Single Sign-On radio button, you will also select the SAML radio button for SSO Type and then fill out 3 fields
  • SSO Endpoint URL or IdP Endpoint URL - This is the URL of the login screen of your portal.
  • SSO Sign out URL - The is the URL where you would like the advocate to sign out (optional).
  • IdP SLO Target Url (Identity Provider Single-logout Target URL) - This will allow the end-user to logout from a single session and be automatically logged out of all related sessions that were established during SSO.
  • SSO Fingerprint/Thumbprint - You need to create a SSL certificate to sign your login page and then get your SHA1 or SHA256 fingerprint/thumbprint for that certificate.


Metadata & Response

You can access your metadata by navigating to "<yourhub>.influitive.com/saml/metadata" or "<customdomain>/saml/metadata". It should look something like the below:

<?xml version='1.0' encoding='UTF-8'?><md:EntityDescriptor ID='_3414ef40-e3c3-0133-63bb-22000b76a0ca' entityID='Influitive-AdvocateHub' xmlns:md='urn:oasis:names:tc:SAML:2.0:metadata'><md:SPSSODescriptor AuthnRequestsSigned='false' WantAssertionsSigned='true' protocolSupportEnumeration='urn:oasis:names:tc:SAML:2.0:protocol'><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:AssertionConsumerService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://<hub-name.influitive.com/saml/consume' index='0' isDefault='true'/></md:SPSSODescriptor></md:EntityDescriptor><br>

Influitive expects a SAML assertion that looks like this

<?xml version="1.0" encoding="UTF-8"?>

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Destination="https://YOURHUB.influitive.com/saml/consume" ID="A GUID" IssueInstant="CURRENT UTC TIME" Version="2.0" InResponseTo="ID of Influitive SAMLRequest">

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />

<Reference URI="#_f44dfe01e93143d7b1e1b9e826ace708">

<Transforms>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

<DigestValue>The DigestValue</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>The SignatureValue</SignatureValue>

<KeyInfo>

<X509Data>

<X509Certificate>The X509Cert</X509Certificate>

</X509Data>

</KeyInfo>

</Signature>

<samlp:Status>

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />

</samlp:Status>

<saml:Assertion ID="A SECOND GUID" IssueInstant="CURRENT UTC TIME" Version="2.0">

<saml:Issuer>{Name of the Issuer. Shouldn't really matter}</saml:Issuer>

<saml:Subject>

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="Influitive-AdvocateHub">example@gmail.com</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml:SubjectConfirmationData NotOnOrAfter="CURRENT UTC TIME + 1 MINUTE" Recipient="https://{YOURHUB}.influitive.com/saml/consume" InResponseTo="ID of Influitive SAMLRequest" />

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Conditions NotBefore="CURRENT UTC TIME" NotOnOrAfter="CURRENT UTC TIME + 1 MINUTE">

<saml:AudienceRestriction>

<saml:Audience>Influitive-AdvocateHub</saml:Audience>

</saml:AudienceRestriction>

</saml:Conditions>

<saml:AuthnStatement AuthnInstant="CURRENT UTC TIME">

<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="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xsi:type="xs:string">John</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xsi:type="xs:string">Doe</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name="Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xsi:type="xs:string">johndoe@example.com</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

</samlp:Response><br>


SAML SP Issuer Suffix

The SAML SP Issuer Suffix field will come into play for you if you have multiple AdvocateHub's. Typically it is set to 'Influitive-AdvocateHub' however this needs to be unique so if you are configuring SSO on your second hub you cannot re-use 'Influitive-AdvocateHub'. When you are configuring your second hub you can add a suffix to the end of this to make it unique, this can be anything you like. You then just need to enter the Suffix you have chosen into this field and you should be all set.

SSO Identifier Field

Note: If you want to enable this feature for your AdvocateHub please reach out to support@influitive.com.

The SSO Identifier Field allows you to enter a different attribute you can send us other than 'Email' (default) to identify the user. This would be useful if you have a certain ID on the SSO provider side and you would rather use that as the unique identifier as you know this won't change whereas it may be possible for the user to update their email address with the SSO provide which will lead to a duplicate account in Influitive being created.


Profile Field Mapping

You can now sync data from their SAML Provider into Influitive’s Profile Fields.

Details that are entrusted to a SAML provider like Job Title, Company, and other identity-related information will be sent on every login through the SSO provider.

Customers have two options for the sync:

  • One-time import - The field syncs when the member first joins
  • Continuous pull - The field syncs each time the member logs in

Similar to how Salesforce or Challenge profile field mapping, using the SAML field sync will overwrite any manually-entered values and restrict them from other mappings.

Note: The SSO Parameter mappings are only possible for SAML type of Single Sign On.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us