Authentication

In addition to the in-product authentication, Modern Campus CMS 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 Modern Campus CMS 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 Modern Campus 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 Modern Campus server using SSL encryption.

Modern Campus CMS 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 Modern Campus CMS server attempts to bind to the sever specified with the given DN, and the password submitted by the user at log in. The Modern Campus CMS 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 Modern Campus CMS. 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, Modern Campus needs to install a copy of the customer's X.509 public certificate on the Modern Campus 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 Modern Campus.

Generally two types of DNs can be used with Modern Campus CMS. 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: user@domain.edu.

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 Modern Campus CMS login page. The user enters their login credentials, which are then passed back to the Modern Campus server using SSL encryption. CAS then authenticates, compares the username with the usernames configured in Modern Campus CMS and, if everything validates, the user is granted access to Modern Campus CMS. Modern Campus CMS 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 Modern Campus server before Modern Campus CMS can authenticate via CAS. To enable (whitelist) the domain name for Modern Campus CMS Services, go to the CAS "Services" panel, use the URL of the Modern Campus CMS login page.

• If regular expressions (regex) can be used: https?://a.cms.omniupdate.com
• Otherwise, specify: http://a.cms.omniupdate.com and https://a.cms.omniupdate.com.

Once CAS is set up, enable it for Modern Campus CMS 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 Modern Campus CMS username must match the user's CAS ID.

ShibbolethLink to this section

Note: The following information on integrating Shibboleth applies only to self-hosted Modern Campus CMS 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 Modern Campus CMS. User accounts are created and managed in Modern Campus CMS; Shibboleth is used to authenticate only. When logging in, users are redirected to the Identity Provider (IdP) page to authenticate. Modern Campus CMS verifies that the user identification attribute defined returned by the IdP matches the username of an Modern Campus CMS user.

The requirements for Shibboleth authentication integration are:

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

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

Included in the Modern Campus CMS 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 Modern Campus CMS:

1. Place the JSP into the /secure directory of the installation.
2. Update the Modern Campus CMS 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 Modern Campus CMS from that account in a separate browser.

This setting takes effect immediately and takes over authentication for that Modern Campus CMS 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 Modern Campus CMS username must match the user's Shibboleth ID.