Service & Quality are Everything


Global System Settings

Authentication Options

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.

Authentication Options Screenshot of OptionsBy 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:

  • SINGLE-SIGN-ON (SSO): Our proprietary SSO solution is designed to work with any authentication scheme that your institution already has in place—Shibboleth, SAML, ADFS, Google, Banner, Azure. How it accomplishes this is by offloading the authentication process entirely to the institution. Once the institution has authenticated the client (typically by having the client log in to a form or portal within the institution's website), the institution passes the client to WCONLINE already authenticated. Scroll to the "Single-Sign-On (SSO)" section of this manual page for extensive information on this option.
  • LDAP/S: Alternatively, if your institution maintains an LDAP (or Active Directory) server, then you can configure WCONLINE to allow individuals to log in directly on the WCONLINE login page using their institutional usernames and passwords.  Scroll to the "LDAP/S" section of this manual page for extensive information on this option.

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.

Single-Sign-On (SSO)

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 URLLOGOUT 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:

MD5 HASHED TOKEN = e89e05926a6687e552bff10c20220478

In order to test your SSO programming, run the email address "" 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:

  • The incorrect time is being used to construct the token.  WCONLINE's time is static and does not change for daylight savings.  Be sure that your script is returning the time that matches the time displayed live in "Authentication Options."
  • The time is not in the correct format before being encrypted.  WCONLINE uses the hour in 24-hour format with leading zeros for numbers less than 10, and the current month and day both with leading zeros for numbers less than 10.
  • The email address isn't being presented in all lowercase or contains an apostrophe that isn't being escaped.
  • The system hasn't been set to "Yes. System is enabled."
  • The person logging in through the institutional form is an administrator in WCONLINE and, therefore, has to log in to WCONLINE through the WCONLINE login form.  If an administrator doesn't already have an account in WCONLINE, then they will first log in via your institutional login form.  WCONLINE will then have them fill out the registration form.  Once they register, WCONLINE will send them a password via email that they can use to log in on the WCONLINE login page.  Finally, they can then change their password in Client and Record Management.

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:,,, and

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").

Testing LDAP/S

Once you've entered values for the required fields (HOSTOU STRING #1PORTEMAIL, 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.  

LDAP/S Test InterfaceIn 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.

Troubleshooting LDAP/S

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:

  • If using LDAPS, you must use a properly credentialed (and not self-signed) SSL certificate.
  • If you have a firewall, you must provide keyholes through that firewall for WCONLINE queries across the port that you specify.
  • If you are using Active Directory, case is especially important and you must ensure that every credential (including things like "ou=" and "samAccountName") are properly capitalized in exactly the same way as in your institutional configuration.
  • If you are using a master bind, that account must have permission to perform queries against the OU or OUs that you enter.
  • If your directory listings don't include an email address, then you won't be able to use LDAP/S through WCONLINE.

Global System Settings

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 6: Appointment, Unavailable Time, and System Colors

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

WCONLINE Product Manual

The product manual is available completely online. Choose a chapter from the list below or use the search tool to perform a keyword search.

CH 1: Welcome


CH 2: Data Collection & Forms

CH 3: Access, Access Levels, and the Schedule

CH 4: Synchronous Online Meetings


CH 5: Update Profile & Email Options

CH 6: Client & Record Management

CH 7: Schedule Management

CH 8: Staff and Resource Management

CH 9: Starting Availability Management

CH 10: Blackout Times Management

CH 11: Announcement Management

CH 12: Mass Email Tool

CH 13: System Data Export

CH 14: Report: System Statistics

CH 15: Report: Master Listings

CH 16: Report: System Utilization

CH 17: Global System Settings

CH 18: Form Setup: System Forms

CH 19: Module Setup: Early Alerts & Flags

CH 20: Module Setup: Survey

CH 21: Module Setup: Time Clock


CH 22: Frequently Asked Questions

This manual applies to the current version of WCONLINE® and is constantly updated as new features are released.