In Global System Settings (which you'll find under the "System Configuration" section of the Welcome menu), you can define a variety of system-wide settings and controls. At the top of Global System Settings, you'll find links to a variety of tools that also enable global changes throughout your WCONLINE site. The third tool, "Authentication Options," allows you to set up single-sign-on with WCONLINE so that individuals can sign in to WCONLINE using their institutional credentials. As with all control panels, be sure to hover over the blue question marks within the control panel in order to find suggestions and more information about each configuration option.
By default, everyone who uses your WCONLINE site first fills out your registration form in order to create an account on the system. After entering their email address and creating a password on that form, they log in to WCONLINE by entering that email address and password on each visit. While the bulk of our clients use WCONLINE by handling registrations in this way, WCONLINE does support two types of single-sign-on solutions:
The "Authentication Options" control panel also gives access to LOGIN CODE that you can use to allow clients to log in to WCONLINE (using their WCONLINE-specific email addresses and passwords) from your center's website. This code is simply HTML code that can be copied from "Authentication Options" and pasted into the web code on your website to automatically add the working login form to your center's website.
Unlike nearly every other area of WCONLINE, you will most likely need IT support in order to configure any of the available single-sign-on options. The options require settings that are typically only available to institutional IT departments; however, WCONLINE is designed to allow your IT department to set up, test, and implement single-sign-on without any involvement from us (although we are still certainly happy to help). In order to get started, we recommend creating a full administrative account for your IT department and then pointing them to this manual page and to the "System Authentication" options in Global System Settings. Also keep in mind that both options take away the authentication process from WCONLINE. This means that if you or if students are suddenly unable to log in to WCONLINE, you'll need to reach out to your IT department as we have no way to know why or to correct the issue that is preventing logins.
The first step in setting up non-LDAP/S Single-Sign-On through WCONLINE is to figure out what form or portal within your existing infrastructure you want students to log in to and whether that form exists or has to be created. Then, the next step is to create the program (using the complete sample provided through WCONLINE) that creates the hash and sends the clients to WCONLINE. Next, you will enter the shared key in WCONLINE (as below) and test the system using the WCONLINE-provided test information. Finally, you'll make the option live. Because this option offloads authentication to a system that we do not control, only non-administrators (typically students) will be able to log in to WCONLINE through the SSO form. Administrators will continue to log in to WCONLINE directly.
In order to begin setting up WCONLINE for Single-Sign-On, choose "SINGLE SIGN-ON" from the SELECTED OPTION drop-down and then click the "Save" button. Next, carefully read the extensive on-screen information. That information provides a process overview, directions for setup and installation, a complete, sample program that can be used to generate the security token, and a form that lets you enter the following variables:
LOGIN URL: This is the URL where non-administrators enter their credentials within your institution's infrastructure. This is used by WCONLINE to tell non-administrators where to log in. Enter the full URL including http:// or https://. WCONLINE uses this to provide a link to your login form from the WCONLINE login page (in order to ensure that clients can easily get to the correct place where they log in).
LOGOUT URL: This is the URL where non-administrators should be directed when logging out of WCONLINE. Enter the full URL including http:// or https://. This can be simply a website that provides information about your center or that gives them access to other institutional services, or it can be a much more complex program within your infrastructure that destroys the client's session and redirects them to a "logout" message.
SECURITY KEY: The security key is a case-sensitive alphanumeric string (without spaces, quotation marks, amphersands, or apostrophes) that is used by WCONLINE and by the institution to construct the hashed security token. This key should be kept secure, complex, and not guessable.
APPOINTMENT FORM FIELD FOR DATA MAP: By default, WCONLINE only receives a client's email address from the institution (along with the passed token that enables the client to be logged in). If you would like (and if supported by your institution's IT department), you can pass a set of data from your institution to WCONLINE and have students select from the passed options when making an appointment.
To implement this option, first create a fill-in question on the appointment form (via Form Setup: Appointments) that will collect the client's choice. Then, select that question from the list of questions in APPOINTMENT FORM FIELD FOR DATA MAP. Then, when passing a client to WCONLINE, including a variable in the URL (as discussed in the sample programming at the top of "Authentication Options" that contains the data set with each option separated by a pipe character. Ensure that each option doesn't contain any ampersands, apostrophes, or quotation marks.
For example, if you wanted to have students select from a list of their actual courses when making an appointment, you would first need to add a question to your appointment form that asks something like, "Select your course." Then, you would select "Map to: Select your course" from the APPOINTMENT FORM FIELD FOR DATA MAP in "Authentication Options." Finally, when passing a student to WCONLINE, you would include something like "&datastring=English 101|Math 261|Bio 101|History 306" in the URL. WCONLINE would ask the student to answer the "Select your course" question on the appointment form by selecting from "English 101," "Math 261," "Bio 101," and "History 306."
Testing Single-Sign-On (SSO)
Once you've entered the LOGIN URL, LOGOUT URL, and SECURITY KEY in WCONLINE, click the "save changes" button (leaving the MAKE SINGLE SIGN-ON SYSTEM LIVE setting set to "No. System is not enabled." WCONLINE will refresh the page adding a new section that displays something like the following:
SECURITY_KEYhourMONTHdayEMAIL_ADDRESS = firstname.lastname@example.org
MD5 HASHED TOKEN = e89e05926a6687e552bff10c20220478
URL = https://email@example.com&token=e89e05926a6687e552bff10c20220478
In order to test your SSO programming, run the email address "firstname.lastname@example.org" through your script. Your script should produce the unencrypted token, MD5 hashed token, and redirect URL that is displayed in WCONLINE. As long as the two displays are identical, you can set the MAKE SINGLE SIGN-ON SYSTEM LIVE setting to "Yes. System is enabled." If the two displays do not match, use the unencrypted token to see where your script is using an incorrect or unexpected value.
Once the system is live, a client (or non-administrator) will log in to your form or portal. They will then be sent to WCONLINE automatically. If it's the first time that that student has accessed WCONLINE, they will be asked to fill out your registration form (without being able to change their email or enter a password). If they've already registered, they'll be taken directly to the schedule display.
Troubleshooting Single-Sign-On (SSO)
If clients are being directed to the WCONLINE login page after coming through your form, then that means that the token in the URL that is being sent doesn't match the token that WCONLINE is expecting. The most common reasons for this are:
If you are looking for where to upload or download metadata information, or need SP entityIDs and signing certificate, then it's likely that you are misunderstanding how the WCONLINE Single-Sign-On system works. Please review the information above and in WCONLINE itself as WCONLINE doesn't use metadata or other such credentials--even to support SAML and Shibboleth. This is because the authentication process through WCONLINE's proprietary SSO system offloads the authentication and credentialing process entirely to your servers.
In order to begin setting up WCONLINE for single-sign-on using LDAP/S or Active Directory, choose "LDAP/S" from the SELECTED OPTION drop-down and then click the "Save" button. Next, carefully read the extensive on-screen information. That information provides a process overview, directions for setup and installation, and a form that lets you enter the following variables:
HOST: This is the full URL for your institution's LDAP/S server. Be sure to preface the hostname with either ldap:// or ldaps:// depending on if you want to use SSL-enabled LDAP or not. We strongly recommend using LDAPS as LDAP sends login credentials across the internet without encrypting them, which is a substantial security risk. In keeping with internet security standards, LDAPS does require that a properly credentialed (not self-signed) SSL certificate be installed on your LDAP server.
OU String #1: This is where you will enter the directory structure for where WCONLINE should look for credentials within your LDAP directory tree. Most likely, this will be entered in a format similar to "ou=students,dc=institutionname,dc=edu." Keep in mind that OUs are case sensitive and must be entered exactly as they appear in your LDAP or Active Directory directory tree. In other words, if your directory tree is set to "OU=students,DC=institutionname,DC=EDU," then entering "ou=students,dc=institutionname,dc=edu" will not work.
If your institution uses multiple OUs to cover multiple access or account classes, we first recommend trying using a single OU using the highest level shared directory name (such as "ou=institutioname,dc=edu" in the example above). If that doesn't work, enter the individual OU strings in the OU String #2 to OU String #8 as warranted. For example, if your structure demands, you could enter "ou=students,dc=institutionname,dc=edu" in the first OU, "ou=staff,dc=institutionname,dc=edu" in the second, and "ou=faculty,dc=institutionname,dc=edu" in the third (for example).
USERNAME FIELD: This is the field in which usernames are stored within your LDAP directory tree. This field is case sensitive and has to match, identically, with whatever is set in your LDAP settings. For WCONLINE, "username" is the field that contains whatever an individual types in as their user credentials when logging in, such as a username, Net ID, or ID number. Most likely, this will be entered in a format similar to "uid" or "samAccountName" or "samaccountname" or "SAMaccountName."
EMAIL: This is the field in which an individual's email address is stored within your LDAP directory tree. WCONLINE uses email as the key field in keeping track of each individual that uses the system. As such, your directory does have to have an email address associated with each username or user in order to use LDAP/S with WCONLINE.
PORT: This is the port that WCONLINE should use to connect to your LDAP/S server. Keep in mind that you most likely will need to add a keyhole to your institutional firewall to allow WCONLINE to make queries to your LDAP server via this port. In order to do so, ensure that the following IPs are whitelisted: 188.8.131.52, 184.108.40.206, 220.127.116.11, and 18.104.22.168.
OPTIONAL: REQUIRED INITIAL BIND: Some institutions require that WCONLINE bind to the LDAP server using dedicated credentials before being allowed to perform additional directory lookups. If this is the case for your institution, you'll need to enter the INITIAL BIND USER and INITIAL BIND PASSWORD here. Once entered, WCONLINE will first attempt to bind using the supplied initial bind credentials. Once successful, WCONLINE will then attempt to validate the username and password entered by the client when logging into WCONLINE. Keep in mind that the fields are case sensitive and that the INITIAL BIND USER credential must be a fully qualified and complete directory string (such as "CN=wconline_bind,OU=service,DC=institutionname,DC=edu").
Once you've entered values for the required fields (HOST, OU STRING #1, PORT, EMAIL, and USERNAME FIELD) in WCONLINE, click the "save changes" button (leaving the MAKE LDAP/S SYSTEM LIVE setting set to "No. System is not enabled." WCONLINE will refresh the page adding a new section that allows you to test the connection.
In order to test the configuration, enter known valid and known invalid usernames and passwords in the LDAP/S Settings Test fields and click "test." WCONLINE will return "success" if the connection can be established and if the credentials are valid; otherwise, the system will return the error that is resulting in the failure (such as "The LDAP/S test failed (RETURNED ERROR: Can't contact LDAP server"). If the connection fails, you will need to use that error to adjust your settings and determine how to move forward, as we have no additional information available to us to help know what is going wrong. For example, the above error most likely means that the firewall isn't letting the connection through. You also might have to correlate an error with the logs from your firewall and LDAP server in order to find the root cause.
As long as you are comfortable with the reliability and accuracy of your tests (in that valid credentials are allowed and invalid credentials are denied), you can set the MAKE SINGLE SIGN-ON SYSTEM LIVE setting to "Yes. System is enabled." Once the system is live, clients (including administrators) will log in to WCONLINE using their institutional credentials on the WCONLINE login page. If it's the first time that that student has accessed WCONLINE, they will be asked to fill out your registration form (without being able to change their email or enter a password). If they've already registered, they'll be taken directly to the schedule display.
If LDAP/S isn't working, the first step is to check the error being returned by WCONLINE's test tool, as well as to look at the logs from both your firewall and LDAP server. Nearly all LDAP failures are related to one of the following:
SECTION 1: Introductory Settings
SECTION 2: General Settings
SECTION 3: File Upload-Specific Settings
SECTION 4: Registration-Specific Settings
SECTION 5: Cross-Schedule Limits
SECTION 7: Social Media
SECTION 8: No-Show Policy and Enforcement
SECTION 9: Control Panel & Feature Access
SECTION 10: System Integrations
SECTION 11: Language Options
SECTION 12: Authentication Options