By continuing to use this site, you agree to the storing of first- and third-party cookies on your device to enhance site navigation; analyze site, product, and service usage; and assist in our marketing and promotional efforts. Cookie Policy

Skip to Content


In addition to the in-product authentication, OU Campus supports Lightweight Directory Access Protocol (LDAP), Central Authentication Service (CAS), and Shibboleth authentication methods. Should the authentication certificate or host name be changed, please notify our support team at least twenty-four hours in advance so the appropriate changes can be made.

LDAPLink to this section

There are three supported LDAP security options and two types of supported distinguished names (DNs). Users still log in through the normal OU Campus login interface. When they do, they visit a login page housed on the application server that holds their account. The server may be located in the OmniUpdate server farm (for SaaS accounts) or in the server located at your institution (for self-hosted accounts). The user enters their login credentials, which are then passed back to the OmniUpdate server using SSL encryption.

OU Campus first looks up the username in its local database. If a matching user is not found, access is denied. If the user is found, the system attempts to authenticate the user. If LDAP information is specified for the account, the OU Campus server attempts to bind to the sever specified with the given DN, and the password submitted by the user at log in. The OU Campus user is granted access only if the bind is successful.

When creating a new user, leave the "Password" field in the user information panel blank. Then, fill in the LDAP configuration fields:

  • Authentication Type: LDAP security level or authorization type
  • Hostname: LDAP server hostname or IP
  • DN: The user's unique distinguished name (DN)

Three security options for authentication type are supported in OU Campus. Each uses the simple method of binding.

  • Simple: When using the Simple method, the LDAP session is conducted in plain text, without encryption.
  • Simple (SSL): When using SSL encryption, OmniUpdate needs to install a copy of the customer's X.509 public certificate on the OmniUpdate server. The SSL method is commonly used in many LDAP installs, including installs utilizing Microsoft's Active Directory.
  • Simple (StartTLS): The StartTLS security method is also supported by OmniUpdate.

Generally two types of DNs can be used with OU Campus. The first is the standard LDAP DN, comprised of relative distinguished names (RDN), which looks similar to this:

CN=FirstName LastName,OU=Staff,DC=domain,DC=edu

The second type of DN looks like an email address. Usually this format is seen in a Microsoft Active Directory environment. A DN for Active Directory might look similar to this:

CASLink to this section

CAS is a single sign-on protocol for the web. It permits a user to access multiple applications while providing their credentials (such as user identification and password) only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. When logging in, users are redirected to the CAS authentication page from where they can enter their credentials.

CAS involves at least three parties: a client web browser, the web application requesting authentication, and the CAS server. It may also involve a back-end service, such as a database server, that does not have its own HTTP interface but communicates with a web application.

When the client browser visits an application to authenticate to it, the application redirects it to the CAS server. CAS validates the client's authenticity, usually by checking a username and password against a database (such as SQL or Active Directory).

If the authentication succeeds, CAS returns the client to the application by passing along a security ticket. The application then validates the ticket by contacting CAS over a secure connection and providing its own service identifier and the ticket. CAS then gives the application trusted information about whether a particular user has successfully authenticated.

When CAS is configured, users are redirected to the CAS login and logout pages as opposed to the standard OU Campus login page. The user enters their login credentials, which are then passed back to the OmniUpdate server using SSL encryption. CAS then authenticates, compares the username with the usernames configured in OU Campus and, if everything validates, the user is granted access to OU Campus. OU Campus usernames must match usernames on the CAS server in order to be authenticated and logged in via CAS.

If the CAS is not signed by a public Internet Certificate Authority (CA), it must be provided to be installed on the OmniUpdate server before OU Campus can authenticate via CAS. If you need to whitelist OU Campus Services in CAS "Services" panel, use the URL of the OU Campus login page.

  • If regular expressions (regex) can be used: https?://
  • Otherwise, specify: and

Once CAS is set up, enable it for OU Campus in the account settings, including providing your CAS service base URL (without the trailing "/login") and logout page URL.

When creating a new user, leave the "Password" field in the user information panel blank. The OU Campus username must match the user's CAS ID.

ShibbolethLink to this section

Note: The following information on integrating Shibboleth applies only to self-hosted OU Campus installs. If you are interested in SAML/Shibboleth authentication for your SaaS account, please contact our support team.

Standard Shibboleth Native Service Provider (SP) software integrates with OU Campus. User accounts are created and managed in OU Campus; Shibboleth is used to authenticate only. When logging in, users are redirected to the Identity Provider (IdP) page to authenticate. OU Campus verifies that the user identification attribute defined returned by the IdP matches the username of an OU Campus user.

The requirements for Shibboleth authentication integration are:

  • Be a member of the InCommon Federation. OmniUpdate is a member and InCommon acts as a broker between the OmniUpdate service provider (SP) and the identity provider.
  • Release user ID attribute to the OmniUpdate service provider.

OU Campus integrates with standard Shibboleth service provider software, which is not specific to OmniUpdate and uses the mod_shib extension for Apache (or its IIS equivalent). The service provider metadata is included in that installation.

Included in the OU Campus WAR is a JSP for Shibboleth support, located under /secure. The file can be adjusted for specific configuration parameters. Assuming that the Shibboleth service provider is set up and working properly, the next steps must be taken to set up OU Campus:

  1. Place the JSP into the /secure directory of the installation.
  2. Update the OU Campus account to use Shibboleth authentication in account settings. In the Login Page panel, configure the CAS or Shibboleth URL field. Point to the file shib:/secure/shibboleth.jsp (file name for the JSP file may vary).
  3. Configure the Logout URL field as well.
  4. Save the changes.
  5. Test by logging in to OU Campus from that account in a separate browser.

This setting takes effect immediately and takes over authentication for that OU Campus account and all sites inside the account. It is not possible to have one user authenticate using Shibboleth and another authenticating using CAS, LDAP, or the standard authentication. Multiple accounts may all use the same JSP file, if linking to the same IdP, or each have their own JSP file for different IdPs.

When creating a new user, leave the "Password" field in the user information panel blank. The OU Campus username must match the user's Shibboleth ID.