NOTE: The information and procedures in this article are intended as GUIDELINES for your SSO configuration change. Every institution’s setup is different and we are not going to pretend to be experts in PingOne or SSO network configurations. Work with your network and PingOne administrators to ensure proper changes are made, and if necessary, contact Echo360 support for additional assistance.
Other links and articles to refer to as needed:
For ADFS: https://ping.force.com/Support/PingIdentityArticle?id=kA3400000008SJuCAM
For SAML: https://documentation.pingidentity.com/pingfederate/pf81/index.shtml#concept_attributeContracts.html
For Shibboleth:
 - Shib2: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute
 - IDP3: https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration

The purpose of the PingOne configuration changes is to allow for automatic user provisioning (creation) in Echo360 through SSO login and section access links.

Section Access Links are instructor-generated URLs that allow users to access an Echo360 section. They can be configured with various levels of access (public, private, open registration). Currently, the section access links page looks like this:

Once the PingOne configuration changes are made, and Echo360 support is notified of the changes, the Section Access Links options are set for your institution to be more appropriate to the SSO authentication flow. After the change is made for your institution, the Section Access Links page will look like this:

The Private option replaces the Registered Users Only and Open Registration options. When a user clicks a Private section access link, they are sent through the institution's SSO Login. If the SSO authentication is successful, the user is taken directly to the class list of the Echo360 section. If the user is NOT already an Echo360 user, the configuration changes requested to your PingOne setup allow Echo360 to receive all the information we need to create a new user account in the background, providing seamless access to the section via the link.

All users must already reside in the SSO/IDP system. If the email they enter is not recognized by the SSO, they logically cannot log in and therefore cannot be passed into Echo360.

To allow us to provision new users automatically, there are new attribute requirements for your PingOne configuration which include:

• Email
• First Name
• Last Name
• Phone Number
  The phone number attribute is optional but suggested. Echo360 uses the mobile phone number to identify students who may respond to activity slides via text message (SMS). Having this attribute passed through with the user upon first entry means the student will not have to manually add their mobile phone number for this purpose. 

Understand that these additional attributes only apply to new Echo360 users being passed in through the SSO login. Existing users already have these attributes in Echo360 (First and Last Name and of course Email address; phone number if the user completed that field in their Account Settings).

Echo360 uses email addresses to uniquely identify each user; some SSO configurations don’t. So while reviewing and making necessary changes to your PingOne configuration, customers should also take the time to do the following, to avoid creating duplicate user accounts:

• If you use a learning management system (LMS) review your LMS configuration and user entries to ensure that each user’s LMS address will match something (either subject or email) in the SSO record for them. See the procedure section below for more information on subject and email attributes.
• Compare your existing Echo360 users with those in your SSO IDP. Investigate any users that exist in Echo360 but do not exist in the SSO IDP. Determine whether the same user is actually resident in both but has an Echo360 email address that does not match their SSO IDP assertion (either subject or email). See the procedure section below for more information on subject and email attributes.

If you find LMS and/or Echo360 users that also exist in your IDP with mismatched email addresses, edit the user in Echo360 to populate the SSO ID field to match the Subject attribute value passed from the SSO. This should ensure you do not create a duplicate user via SSO user provisioning.

ADFS Configuration

The following attributes must be mapped in the Outgoing claim type of your ADFS configuration. For Shibboleth or SAML changes, refer to the links provided at the top of this article.

1. Open your ADFS configuration and find the Echo360 claim created for PingOne.
2. Add the following LDAP attributes: Surname, Given-Name, Email, Phone Number (optional)
3. In the Outgoing Claim Type, map the added attributes to the same values by selecting or typing the values into the field.
   The below figure provides an example of two of the mapped attributes.
   
4. When finished, save the configuration.

PingOne Configuration

As stated above, the below changes to your PingOne configuration are to ensure that your IDP is passing Echo360 all the necessary information to create new Echo360 users in the background when needed, for seamless entry into sections via access links. These changes will not affect existing Echo360 users.

1. Log into to your PingOne Admin Portal (https://admin.pingone.com)
2. Select Applications from the main toolbar.
3. Find the Echo360 application listed, and click the triangle (show application details) button located on the right side of the application entry.
   
4. Scroll to the bottom of the Echo360 Application details page, and click Edit.
   
5. Page through the configuration wizard to the Attribute Mapping page, shown in the below figure.
6. Complete the values fields based on the attribute information passed from your IDP to PingOne. CHECK with your IDP administrators or vendor to confirm the values to put per attribute.
   Do not check As Literal; this would send the provided attribute name as the actual value passed through to Echo360.
   
   Some guidance, especially as it relates to how Echo360 uses these fields:
   • Subject is sometimes the same as email address. It isn’t always. It is required, however, and must uniquely identify the user.
     Echo360 first tries to match up the Subject value from the SSO to an SSO ID field in Echo360. If there is no match, Echo then tries to match Subject to an email address in Echo360. If it finds no match for either, it moves on to the Email attribute value.
   • Email might be email, or emailAddress, or may not be any of these.
     Echo360 uses the Email value if it cannot match the Subject value to a user. First, we try to match Email from the SSO to an SSO ID field in Echo360. If there is no match, we try to match Email from the SSO to an email address in Echo360.
     If NEITHER of these values from the SSO finds a match in Echo360, we create a new user with the email address provided from the SSO and populate the First Name, Last Name, and Phone Number (if given) fields in Echo360.
7. Enter the firstName, lastName, and phone IDP attributes as provided by your IDP administrator.
8. When finished, click Continue to Next Step, then click Save and Publish to save your changes.

After you have completed this configuration change, contact support@echo360.com and let us know. We will activate the SSO Access Links feature for your institution. After this happens, all new Section Access Links created for your institution will have only Private and Public options, and users new to Echo360 will have their accounts created without requiring any action on their part.

See SSO-Enabled Section Access Links for additional details on what happens on the user side once a section link is clicked.

NOTE that any existing section access links will not change; the options set for those under the original system will remain in place until those links are deleted.