Chat Participant Single Sign-On

In order to maintain a smooth participant experience when integrating Meet & Engage chat into your existing workflow, there are currently two methods that can be used to allow users into a chat without prompting for credentials.

If you are leveraging the Plugin API to embed chat, the programmaticLogon() function details within the Plugin API should be used. This allows you to pass user information into the M&E plugin outside of the normal Logon process, and does not invoke a browser navigation away from your page.

If you are using a hosted Landing Page, you can use the URI Auth mechanism to pass users details programmatically.

URI Auth Process Flow

Here is an example scenario in which you can leverage the URI Auth to allow SSO

• You maintain a CRM/CMS that hosts pages containing tailored content specific to logged-on users
• You include a link on your CRM/CMS to an upcoming chat event
• Sue Doe is logged onto your CRM (with a session cookie, or any other method) and you show the 'Join this chat!' link to her
• Sue clicks on the link, and is taken to your page on the www.meetandengage.com domain
• Sue isn't prompted to provide her name or email address, but instead the page shows 'Hello, Sue!'
• Sue joins the chat on the Meet & Engage page and her name appears as "Sue"

and as a clean tail-end to this process...

• After the chat event, you use the M&E REST API to obtain information about the number of chat messages Sue sent, an average sentiment score and so-on.

For more information about the latter part of this process, and how other elements of the REST API can be used, for instance to schedule events programmatically, please see the corresponding sections of our website.

URI Auth mechanism

The URI Auth is so named as it sits alongside the other Authentication methods within the M&E platform, namely Nickname, Nickname and Email, Guest and Social Network oAuth. The last option requires that the user joins using their preferred social network of LinkedIn, Facebook or Google, where the other allow the participant to enter their name/email manually (and arbitrarily).

The moderator scheduling the event can choose the level of authentication required on an event-by-event basis, so if a certain level of assurance is needed as to someone's identity, the oAuth method alone can be chosen, or any permutations of the other options as desired.

Once the chosen authentication method has been passed, the user's browser holds a session cookie, allowing them to rejoin events with the same identity, or indeed the same event, without re-authenticating.

Events to which URI Auth authenticated users are admitted must be set to allow 'Nickname Only' authentication in the event scheduler.

The URI Auth mechanism allows user cookies to be generated by passing identity credentials to us as part of the querystring. The endpoint is https://www.meetandengage.com/auth/uri, which accepts the following parameters:

When a browser arrives at this endpoint, the included parameters are used to generate a logon cookie and then the user is 302 redirected to either the landing page, or the specific event within it. This is done without rendering a page in between, so the interstitial stage is not included in the user's browser history under the back button. The user sees the normal https://www.meetandengage.com/accountname in their URL bar.

Implementation

The simplest approach is be to concatenate a link with the required parameters as the target of a button or link within the CRM/CMS page, e.g.

<a href="https://www.meetandengage.com/auth/uri?account=accountname&uid=12345&givenName=Sue&familyName=Doe">Click here to join this chat event!</a>

The pertinent bits of the link would be written server-side based on your current logged-on user.

The drawbacks to this approach are that the link looks pretty ugly, it contains user info, and copying/sharing the link with friends or colleagues will allow immediate logon as Sue.

Our recommendation is to construct the full URL server-side and carry out a 302 redirect to the /auth/uri endpoint from there. This code can then be held behind a more innocuous link that can be shared with anyone.

GET vs POST

Using a GET (albeit against an HTTPS endpoint) will leave the identity information visible in the user's browser history. If this is of concern, you can choose to POST to the /auth/uri endpoint instead. The parameters and function is unchanged.