Conviva SSO Federation

 

Conviva single sign-on (SSO) federation enables users to securely authenticate with Conviva's applications using a corporate email and password.

Use Conviva SSO federation to:

  • Easily access Conviva applications with a corporate email and password

  • Re-direct to the corporate identity provider (IdP) before accessing Conviva applications

  • Navigate to Conviva applications from your IdP

  • Enable or disable a user's access to Conviva applications through the IdP using administrator privileges

Scope of Support

Conviva SSO federation supports several authentication protocols, login scenarios, and IdPs.

Supported Authentication Protocols

  • Security Assertion Markup Language (SAML 2.0)

  • OpenID Connect (OIDC)

Supported Login Scenarios

  • IdP initiated - Access Conviva applications using an icon in the IdP

  • Conviva initiated - Access Conviva applications directly by re-directing to the IdP and then back to Conviva applications

Supported IdPs

  • Okta

  • Active Directory

    • Note: Conviva engineering team can explore integration with additional IdPs if you use a supported authentication protocol and provide advance notification. Contact your Conviva representative in advance and submit a request.

High-Level Process

  • Conviva Okta connects with the IdP using either SAML 2.0 or OIDC.

  • The connection is created using an email domain based routing rule i.e., anyone using that email domain is redirected to the IdP for authentication.

  • Application specific permissions are still handled within the Conviva user interface. For example, association with multiple c3 accounts.

  • Test using the test email domain.

  • Prepare the go-live timeline.

Integration Tips

User Impact

  • After integrating Conviva SSO federation, provide a corporate email and password for the users. If a user used a corporate email before the integration, then use the same corporate email. The password is changed from Conviva or Pulse password to a corporate password. If a user did not use a corporate email before integration, then create new corporate login credentials for the user. This email and password are not associated with the old login credentials (personal email and password) and the user may lose access to some filters, etc. For example, ownership of filters that they created in the past.

  • All users including vendors must be authenticated through the customer's IdP. Also, enable Pulse access for the users that must be authenticated through your IdP.

  • When you enable Conviva SSO federation, the cookie expiration time for a user that is currently logged in is the expiration time set in IdP or 6 hours as set in Pulse, whichever is shorter.

User Management

  • Set a default user permission as per your requirements. By default, new users get this user permission. Use Pulse to administer roles and manage user groups.

  • c3.account association is managed by Conviva. If you own multiple c3.accounts, then let Conviva know the default c3.account that a user must access when they log in for the first time. Also, an account administrator can invite a user to use a c3.account using Conviva's user management interface through Pulse.

  • To disable a user's access to Pulse immediately, disable that user's access to Pulse in the IdP. Some ownership information of the user may still be stored in Conviva's database. To delete this information, request Conviva for a data clean up.

Testing

  • Conviva SSO federation is enabled at the email domain level. Conviva recommends that you create a test user with a different domain. Then, integrate Conviva SSO federation for that test user's domain and assign that test user to a c3.account. This enables Conviva to test the integration properly using the test user's domain.

  • After Conviva's verification, set up the application again with new settings and enable the federation for the production domain.

Customer SSO Federation Questionnaire

The following questions help Conviva Support you and make sure that the Conviva SSO federation integration process is smooth. Please answer these questions when you submit the request for Conviva SSO federation integration.

  1. Which identity provider (IdP) solution do you use? Do you use multiple IdP solutions?

  2. Does the preferred IdP support Security Assertion Markup Language (SAML 2.0)?

  3. Does the preferred IdP support OpenID Connect (OIDC)?

  4. Can we get the public certificate to validate SAML 2.0 assertion signatures?

  5. Will all users be managed through your identity management solution or do you expect a hybrid approach?

  6. How do you manage access for users not within your company? (For example, providing access to third parties.)

  7. How do you plan to handle existing users who are using emails not from your domain?

  8. What login scenarios are you expecting to support?

    1. User comes directly to Pulse and then through Pulse, Okta checks your identity management system for access.

    2. User logs into your identity management system and connects to Pulse from the identity management system.

  9. How do you manage application level permissions for applications similar to Conviva's? For example, access to modules, dashboards, read-only vs read-write, staff vs administrator, etc.

  10. Can we get an IdP metadata file as this file will help when we are building out the solution? We will have to eventually confirm the IdP metadata file as final before we go live.

Implementation Notes

First, note that Conviva routes to different IDPs based on domains, not C3 accounts. For example, the C3.ABC123 account may have users from multiple domains accessing this account, such as abc.com and 123.com. If a routing rule is set for abc.com that applies to only that domain, 123.com would be able to log in to C3.ABC123 with their Pulse local login.

It is recommended to test with an alternative domain that no other user is currently using to access Conviva products. For example, @test.abc123.com is a valid test domain based on the above example. After a successful federation, it can then be enabled for the default domain (abc123.com).

Once federated, JIT provisioning will be enabled and it is recommended that a default C3 account and role is chosen for these new users.

NOTE: All new users in your IDP will have access to these C3 accounts.

Federation Process

  1. Open a ticket with support@conviva.com.

    Conviva will provide you with a metadata file that will contain IdP ID, ACS URL, and Audience URI.

    In return, Conviva needs:

    • Identity Provider Single Sign-On URL

    • Identity Provider Issuer

    • X.509 Certificate

  2. Define the following SAML attributes:

    • firstName Unspecified user.firstName

    • lastName Unspecified user.lastName

    • email Unspecified user.email

  3. For Default Relay State, please use: https://pulse.conviva.com/login

Example of SAML Assertion

Copy 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:unspecified">mpfeiffer@conviva.com</saml2:NameID>
            <saml2:SubjectConfirmation 
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData 
InResponseTo="id160769838581675811469152348"
                NotOnOrAfter="2021-04-26T19:49:59.249Z"
                Recipient="https://auth.conviva.com/sso/saml2/0oa4d6sgehWz5j7Ku0i7"/></
saml2:SubjectConfirmation>
        </saml2:Subject>
        <saml2:Conditions NotBefore="2021-04-26T19:39:59.249Z" NotOnOrAfter="2021-
04-26T19:49:59.249Z"
            xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml2:AudienceRestriction>
<saml2:Audience>https://www.okta.com/saml2/service-provider/spazdwyjebkatrcmdeyy
</saml2:Audience>
            </saml2:AudienceRestriction>
        </saml2:Conditions>
        <saml2:AuthnStatement AuthnInstant="2021-04-26T19:44:58.753Z"
            SessionIndex="id160769838581675811469152348" 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProt
ectedTransport</saml2:AuthnContextClassRef>
            </saml2:AuthnContext>
        </saml2:AuthnStatement>
        <saml2:AttributeStatement 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml2:Attribute Name="firstName"
                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
                <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="xs:string">Michael</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="lastName"
                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
                <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                    xmlns:xsi="http://www.