Summary

The Connect-2-Everything Security Assertion Markup Language (SAML) Single Sign On (SSO) allows secure web domains to exchange authentication and authorize information between a client’s identity provider (or other identity providers) and Refined Data’s service provider to authenticate users.

Using SAML, Refined Data acts as the service provider providing access to Adobe Connect meeting rooms. The identity providers control usernames and passwords.

The SAML SSO needs to be enabled on the “clients” database table and authorization method credentials need to be added to “clients_saml” database table.

In some instances, the metadata files need to be added to the C2E application and on the authorization method.

The Connect-2-Everything SSO service is based on SAML v2.0 specifications.

User creation

The SAML SSO addresses three scenarios: 

1). If the user doesn't exist, the application creates the user by email and adds the user to the correct group for access to the designated Adobe Connect meeting room.

2). If the user already exists on Adobe Connect (created with an API call), the user’s password is updated and the user is logged into the Adobe Connect meeting room. 

3). If the user exists on Adobe Connect (created manually and directly on Adobe Connect), the application will ask for a password and then log the user into the Adobe Connect meeting.

SAML transactions

The process outlined here explains how a user logs into an Adobe Connect meeting room through the Refined Services SAML-based SSO service.

NOTE: The identity provider must provide Refined Data with the URL for its SSO service and the public key to verify SAML responses.

1. The user reaches the landing page and attempts to access an Adobe Connect meeting room.
2. Refined Data generates a SAML authentication request encoded and embedded into the URL.
3. Refined Data sends a redirect to the user’s browser that includes the SAML authentication request.
4. The identity provider decodes the SAML request and authenticates the user by asking for valid login credentials or checking for valid cookie sessions.
5. The identity provider generates a SAML response containing the user’s authenticated username.
6. The identity provider encodes the SAML response and returns that information to the user’s browser which is forwarded to Refined Services.
7. Refined Services verifies the SAML response and if successful, redirects the user to the destination URL.
8. The user is redirected to the destination URL and logged in.

Google account authentication naming

To change the Google account authentication name, log into the google developers console and create a project. In the project, create credentials and assign a name, which will appear in the authentication to the end user. To do so:

GO here: https://console.developers.google.com (Log in with a Google account, if not already logged in).

Click Create Project and fill out the designated fields.

The left-hand menu will display heading APIs & authorization and select credentials.

Create a new client ID and fill in the form as follows:

Application type: web application

AUTHORIZED JAVASCRIPT ORIGINS: http://idp.refineddata.com

AUTHORIZED REDIRECT URIS: http://google.idp.refineddata.com/module.php/authgoogle/linkback.php

NOTE: The authorized redirect URIS will vary slightly per client as it is configured in the identity provider.

Once created, send the CLIENT ID and CLIENT SECRET to Refined Data along with the URL mentioned above to add to our system.

To set what appears on the permissions page, go to consent screen (in the left-side menu, below credentials). Product Name is what appears.