Sign-On Options

An important responsibility of the IT Professional is to determine and set the sign-on options for the institution’s ConexED instance.

Three Ways Students Access Users and Services

The sign-on options available to students depend on how they access users through ConexED and whether or not the users they access are associated with a group.

1. External Access to Non-Group User

Each user in ConexED has a ConexED Card, and each Card has a URL and Webpage Embed Code. Users will find the URL and Embed Code in their Profile Settings. Even users who are not added to a Group will have these tools for sharing or publishing their ConexED Card externally. We call users who are not part of a Group “non-Group users.”

When a student interacts with a non-Group user’s Card, if the student is not already logged into ConexED, they will be prompted to sign on. By default, there is only one sign-on option when clicking a non-Group user’s Card: the Guest Registration button. In ConexED, the Guest Registration is a secure, delegated Open Authorization (OAuth) login that enables a student or guest to log in to the system with an email and password that they create. Figure 1 illustrates the OAuth Guest Registration button.

Figure 1

Guest Sign-On Button Associated With a User’s Card That Is Not Part of Any Group

Each user’s account settings provide additional sign-on options. These options can only be enabled by a ConexED Admin. Generally, it is more practical to add the user to a Group than it is to edit the sign-on options for a single user’s card; however, Figure 2 illustrates the section of a user’s account page where the non-Group user sign-on options are located. The checked Cranium Cafe OAuth option is the Guest Registration button.

Figure 2

Individual User’s Sign-On Options Available to Admins Only

2. External Access to Group Users

Each Group in ConexED has its own Group users. When a Group user shares or embeds their ConexED Card on an external webpage, interactions with the Card will prompt the Group’s sign-on options. Each Group also has its own Group Embed Card Widget for publishing the Cards on an external webpage, and interactions with any of the Cards in the Group will prompt the Group’s sign-on options. Accessing users via a Group’s Scheduler URL, Lobby URL, or Kiosk URL will also prompt the Group’s sign-on options.

Figure 3 shows an example of a Group’s sign-on options, which may or may not be the same as the sign-on options for the institution’s ConexED login page because a Group’s login types may be customized in the Group Settings as shown in Figure 4.

Figure 3

Group’s Custom Sign-On Options

Figure 4

Group Sign-On Options May Be Customized in the Group Settings on the Login Type Tab

3. ConexED Instance

Students who sign on by going to their institution’s ConexED login page or students who sign on in the process of opening a virtual meeting URL will have all of the sign-on options available that have been set for the instance. Group users such as faculty and staff will also log in from the institution’s ConexED homepage.

As shown in Figure 5, there are two sides to the sign-on options on the login page. The left side button is a SAML2 SSO login that is integrated with the Identity Provider (IdP) that the institution uses to manage its user accounts. Common IdPs are Microsoft Azure, Google, and Okta. The IdP sends SAML responses to ConexED to authenticate the end-users for Single Sign-On.

The right side displays the OAuth 2.0 options that allow students to authenticate with popular OAuth 2.0 providers such as Facebook and Google. These options allow for seamless authentication and require no setup work by the institution’s IT Professional. The only caveat of using an OAuth2 login is that a limited set of data about the student is sent to ConexED: email, first and last name, bio, and profile picture. 

Both the SAML2 and OAuth2 login options are set on the Settings tab of the Admin User Panel by checking the associated boxes as shown in Figure 6 and then clicking the Update button at the bottom of the page to save settings.

Figure 5

Sign-On Options for the Institution’s ConexED Instance Homepage

Figure 6

SSO Login Types Selected on the Settings Tab of the Admin User Panel

SAML2 SSO Self-Service

SAML2 is an open standard for providing a single sign-on for web-based applications that provides authentication and authorization for the login. A SAML2 SSO permits students, staff, and faculty to use their existing school credentials to securely sign on to ConexED.

ConexED offers a self-service SAML2 setup page. Setting up the SAML2 will require some back-and-forth between the institution’s IdP settings and the ConexED SAML2 settings as the IdP will require an activated ConexED Entity ID, and a ConexED Entity ID is only active after saving the SAML2 settings with the institution’s IdP data. Thus, the recommended setup steps are as follows:

1. Open the ConexED SAML2 Settings: Access the SAML2 Settings button by clicking the Edit SAML2 Settings on the Settings tab of the Admin User Panel.
2. Enter dummy data in the ConexED SAML2 Settings and Save. Saving the dummy settings will activate the ConexED Entity ID. An example of dummy data would be to type “email” in the required fields, which are shown in red font in Figure 7. The figure also illustrates the pop up warning to confirm you want to save. Go ahead and click OK. You’ll then get another pop up confirming that says SAML2 settings have been saved as Figure 8 illustrates.

Figure 7

Example of Dummy Settings and Save Action Pop Up

Figure 8

SAML2 Settings Saved

3. Open your Identity Provider Admin Console.
4. Create a SSO Application in the IdP. IdPs will typically have a wizard to take you through the steps for configuring the application to provide SAML2 identity authentication. See your respective IdP for details. When creating the application, you will be prompted for the Service Provider’s Entity ID.
5. Enter the ConexED Entity ID. The format for the ConexED Entity ID is https://subdomain.craniumcafe.com/saml2. Simply replace the word subdomain with your institution’s ConexED subdomain–the part of the URL that identifies your institution. In Figure 9, stmarysca is the subdomain, so the Entity ID would be https://stmarysca.craniumcafe.com/saml2.

Figure 9

Where to Locate Your Subdomain

6. Continue the IdP settings wizard until you arrive on the Identity Provider Details page.
7. Copy the required data and paste it into the required fields of the ConexED SAML2 Settings or download the Metadata from the IdP and copy and paste it into the IdP Metadata URI field of the ConexED SAML2 Settings. Loading the Metadata will auto-populate the required fields.
8. Test the settings by clicking the Test button. Your IdP login form should pop up.
9. Save the settings by clicking the Save button. The form will close.
10. Check box for SAML2/Shiboleth on the Login Types list.
11. Update the settings by clicking the Update button at the bottom of the Settings page.

SAML2 Settings Details

Red font identifies the fields for the required data from the IdP that needs to be entered into the ConexED SAML2 Settings. As shown in Figure 10, there are four required fields.

Figure 10

SAML2 Settings Showing Required Fields in Red

Required Fields

1. IdP Entity ID: The IdP Entity ID will be a URL.
2. Log On URL: The Log On URL is also called an SSO URL. This is the same URL used at the school for logging into the IdP system.
3. Certificate Fingerprint: The Certificate Fingerprint is also called the “Certificate” or the “x509 Certificate.”
4. Login Attribute: The Login Attribute will map to the user’s ConexED username with special characters such as the @ symbol and dot removed. The username is unique systemwide and is normally the user’s email address, but it can be whatever the IdP uses to login a user, which may be email, first name, or last name. This login attribute without special characters will also be the slug in the permalink of the user’s ConexED card, which is why using an SIS ID as a login attribute is not recommended.

Figure 8 shows where the Log On URL, IdP Entity ID, and Certificate data are obtained from a Google IdP on the Google Admin Authentication settings page.

Figure 8

Google Identity Provider Details

Federated Attributes

The bottom half of the SAML2 Settings in ConexED are for the Federated Attributes. Federated Attributes are information sent from your IdP that can be used to automatically update corresponding information for users in ConexED each time they log in. There are three self-service fields for Federated Attribute mapping. The self-service fields have red labels as shown in Figure 8.

Figure 8

Federated Attributes: Provider Attributes

Required Federated Attributes

There are three required Federated Attributes in the ConexED settings for mapping the data sent from the IdP. The attribute labels may or may not match the attribute labels in your IdP. What you enter in the field will be what maps to the data associated with that attribute in your IdP settings.

1. partner_username is normally mapped to the eduPersonPrincipalName attribute as it is called in Azure, but it could be email or nameofperson or whatever is defined for the attribute in the IdP.
2. email is normally mapped to the mail attribute.
3. fullname is normally mapped to the displayName attribute.

About the fields that are not required: The fields that are not required are used in custom integrations only, so they may be left blank.

CAS SSO

CAS integrations require code changes by ConexED, so they are not self-service. CAS integrations require contacting a ConexED Implementation Manager or Customer Success Manager and then meeting with a ConexED Software Engineer to discuss the details.

Sign-On Options Quiz

You need to be registered and logged in to take this quiz. Log in or Register