Authentication

CampusPress supports a wide range of authentication options.

We handle any server configurations and WordPress plugin settings that are needed.

We’ve found that no two authentication configurations are the same, but most integrations can be completed in less than a week.

Contact us or email contact@campuspress.com if you need additional information on our authentication options.  

ADFS

We provide single-sign-on authentication with ADFS to handle user and site management.

What we need:

Email contact@campuspress.com to let us know you want to set up authentication with ADFS and provide the following:

  1. Version of SAML supported.
  2. Metadata for your SP
  3. Your Login URL
  4. Your Logout URL (Optional)
  5. A user account that we can use for testing

Azure AD

We provide single-sign-on authentication with Azure AD to handle user and site management.

What we need:

Email contact@campuspress.com to let us know you want to set up authentication with Azure AD and provide the following:

  1. Your metadata.  The login URL is mydomain.edu/wp-login.php
  2. A user account that we can use for testing. It needs to be set up similar to either a student or teacher account.

Authentication with Azure AD can be set to auto create user accounts only or to auto create user/site accounts.

CAS

We provide single-sign-on authentication with CAS to handle user and site management.  The process is relatively simple and our team will provide assistance to help set it up.

What we need:

Email contact@campuspress.com and let us know you want to set up authentication with CAS and provide the following information:

  1. Server details and version
  2. Hostname
  3. Port
  4. Path
  5. Login URL
  6. Logout URL
  7. The email domain(s) used by staff and student user accounts
  8. CAS user account we can use for testing and troubleshooting

CAS Customization Options

CAS can be set to auto create user accounts only or to auto create user/site accounts.
Affiliations can be used to auto add users to course blogs based on the users affiliation meta and affiliation value.  Underneath the site URL in Sites in the network admin you’ll see affiliation action link where a super admin is able to set it up. Users are only added to the Course blog when they log into your CampusPress network.  

G Suite

We can provide single-sign on authentication with your Google Apps for Education domain to handle user and site/blog management.

The process is relatively simple and our team will provide assistance to help set it up.

What we need:

Email contact@campuspress.com and let us know you want to set up authentication with Google Apps as we first need to install the Google Connect plugin.

Set up Google Connect

Once we’ve installed the Google Connect plugin your Google Apps domain administrator needs to create the Google API Key, Client ID, and Client Secret.

You set up Google Connect as follows:

1.  Go to Settings > Google Connect in the network admin dashboard.
Add wp-login.php to the end of your CampusPress URL if you are redirected to the Google apps login page.

2.  Create Project by visiting the Google Developers Console.

3.  Click on “APIs & Services” > “Credentials” and then “Create credentials” > “OAuth client ID“.

4.  Click “Configure consent screen” to customize application details.

5.  Select “Web application“.

6.  Enter the following into “Authorized redirect URIs” text area: https://campusdomain.com/wp-login.php?loginGoogle=1 (where mycampusdomain.com is your CampusPress URL):

7. Copy and paste the newly created Google Client ID and Google Client Secret into Settings > Google Connect in network admin dashboard.

8.  Add your Google Apps domain (or multiple domains by separating them with comma) in the field for “Restrict login for domain“.

These are your teacher and student email domains.

9.  By default, it is set to force Google Login and will redirect to your Google apps login page.

You only change it to ‘No‘ if you need to add some users as local users and want to provide an option for users to log in as a local user or a Google Apps user.

10.  By default, it is set to create a site/blog the first time a new user signs in with their Google apps username and password.

Change it to ‘No‘ if you only want user accounts created.


Users can create their own site/blog using Dashboard > My Sites > Create New site once they’ve logged in or a super admin user can create their new site using Batch Create.

11.  Click Save Changes.

12.  Test logging in using both a staff and student email account to confirm it is working (you need to use email accounts that haven’t logged into your CampusPress network).

Send an email to contact@campuspress.com if you need assistance.  

LDAP / Active Directory

We can provide single-sign-on authentication with Active Directory / LDAP to handle user and site management if the requirements of the network meet the required standards. You’ll find an overview of these requirements and how to set up below.

What we need:

Email contact@campuspress.com and let us know you want to set up authentication with with Active Directory / LDAP as we first need to install the LDAP plugin.  The LDAP plugin should only be installed when you are ready to set up as it can cause issues because Users > Add New is replaced with Users > Add Users which can’t work if it isn’t set up.

Please note:

  • We can only connect to one LDAP server.
  • If the student and staff accounts use two different LDAP servers you need to choose which accounts you want to set up LDAP authentication for.

Set Up LDAP

Once we’re installed the LDAP plugin you’ll need someone from your LDAP team to help configure the settings.

You set up LDAP as follows: 
1.  Add our IP addresses or IP block range to your LDAP firewall (we’ll send these IP addresses once we’ve installed the LDAP plugin).

2.  Go to Settings > LDAP Options in the network admin dashboard.

3.  Add your Connection settings and click Save Options.

4.  Go to General Settings to select your default options and then click Save Options.

Options are:

  • Auto create WPMU username – This needs to be set to Yes for their user account to be created the first time a new user logs in using their LDAP username/password.
  • Auto create WPMU Blog – Set to ‘Yes‘ if you want a new blog created the first time a new user logs in using their LDAP username/password.  Set it to ‘No‘ if you only want their user account created.  Users can create their own blog using Dashboard > My Sites > Create New site once they’ve logged in or a super admin user can create their new site using Batch Create.
  • Blog Name For Auto-Created Blogs – allows you to specify the URLs used for creating new blogs.
  • Create local users – set to ‘No‘ if you don’t want blog admins creating local user accounts.
  • Allow blog admins to add users – leave as ‘Yes‘ if you want your blog admin users to be able to add LDAP users to their blog.
  • Allow blog admins to bulk users – leave as ‘Yes‘ if you want your blog admin users to be able to add LDAP users to their blog.
  • Disable Public Sign up – leave as “Yes‘ if you want users to be able to create additional sites using Dashboard > My Sites > Create New site
  • Lost-Password Message – add a message to explain that their user account is tied to their school account and provide either an email address or link to information on how to reset their password.
  • Public Display Name Format – controls how their name is displayed.

5.  Once configured test logging using both a staff and student user account in to confirm it is working (you need to use accounts that haven’t logged into your CampusPress network).

Email contact@campuspress.com if you have any issues setting up LDAP.  You’ll need to provide a test LDAP user account we can use it for troubleshooting. The LDAP user account must be attached to an email address (but it doesn’t need to be a valid email address).

LDAP Overview and Requirements

LDAP , or Lightweight Directory Access Protocol , provides a standard way to share user information. It also allows an internal or external system to authenticate users. The LDAP protocol itself is standard and vendor neutral. However, there are often implementation specific issues, primarily relating to the schema (how the information is presented).

Schema Support
The set of attributes available in a LDAP record is called a schema. Schemas are additive, and there are many standard ones available. We have worked with the Microsoft Active Directory and Apple OpenDirectory schemas as well as rfc2307 (Unix/NIS, posixAccount) and inetOrgPerson. Even plain old inetOrgPerson provides adequate information for Edublogs integration. Non-standard or heavily customized schemas may require custom integration work at an additional charge.

LDAP Settings
Super Admins will have access to the LDAP settings and options by going to ‘Network Admin’ > ‘Settings’ > ‘LDAP Options’. The Campus network will first need to be up and running before LDAP can be configured.

SSL
SSL, or Secure Sockets Layer, is a standard method of encrypting connections between systems. We are able to use this standard method of encryption (or optionally the very similar, also standard TLS, or Transport Layer Security) to encrypt the LDAP connection between your servers and our servers.

We are unable to obtain certificates for domains we don’t own, and will provide CampusPress networks with the needed CSR info to generate certificates.  We need the certificate and intermediate certificates in PEM form. If you need to specify which server to select for the Certificate select Apache.

Certificate Signing
To help ensure the security of your users’ data, SSL certificates must be signed by a reputable Certificate Authority (CA) such as Comodo (including InstantSSL and PositiveSSL), Thawte or Verisign. Other widely recognized certificate authorities are also acceptable (as a rule, if major current web browsers will accept a certificate, it is fine). We do not accept certificates that are self signed or signed by your own CA or any non-accredited signing agent. We are available to assist you in finding an appropriate certificate agency.

Local Users

A local user account is the user account created by WordPress within CampusPress.  Whenever possible, we recommend connecting your CampusPress network with your existing single-sign-on system such as LDAP, Google Apps, Shibboleth, CAS or SAML.

Authentication with your single-sign-on system (SSO) allows your users to log in with their school username and password.  It can also be set to auto user creation or auto user/blog creation the first time a new user logs in with their their school username and password.

All Users are automatically created as SSO users, if you’ve set up single-sign-on authentication on your CampusPress network, except if the user is added using Users > Add New (in the site admin and in the network admin).  Blog & User Creator, My Class and Batch automatically create the new user as an SSO; the new user can log in with their school username/password provided their correct SSO username and email address was used.

Shibboleth

We are a sponsored partner of the InCommon Federation. Our metadata is published in eduGAIN interfederation metadata export as well. We support metadata exchange with any member of eduGAIN interfederation.

We use a customized WordPress Shibboleth plugin and can provide single-sign-on authentication using Shibboleth to handle user and blog management. The process is relatively simple and our team will provide assistance along the way.

Attributes

​Required:
– mail
Optional (but preferred):
– cn
– displayName
– eduPersonPrincipalName
– givenName
– sn
For limiting blog creation to certain groups:
– eduPersonAffiliation and/or eduPersonScopedAffiliation

Using InCommon

Send an email to contact@campuspress.com with a request to set up Shibboleth via InCommon with the following information:

  1. Your Login URL.
  2. Your Logout URL (Optional).
  3. A test shibboleth user account that we can use for testing.
  4. Your Attributes.

Upon receipt of your email we will set up your metadata and submit it to InCommon.

Before InCommon will release your metadata to us it needs to be approved by your team, and the email is sent from InCommon to the WHOIS main contact.  You need to make sure the person listed in your the WHOIS main contact is aware that they will be receiving  an email from Incommon to approve use of our entityID and ask them to send a reply to InCommon approving their request as soon as possible.  

Please note:

  1. InCommon only publishes metadata once per day and on on weekdays only.
  2. InCommon needs email confirmation from your WHOIS contact before they’ll release the metadata to us.

Exchange metadata manually

If you aren’t a member of InCommon, we need to exchange shibboleth metadata manually.
Send an email to contact@campuspress.com with a request to set up Shibboleth with the following information:

  1. EntityID for your IdP
  2. Metadata for your IdP
  3. Your Login URL
  4. Your Logout URL (Optional)
  5. A test shibboleth user account that we can use for testing
  6. Your attributes

Upon receipt of your email we will set up your metadata.  

We will send a link to the metadata once it has been set up, ask you to add our Metadata to your IdP config and let us know once it has been added so we can complete installing Shibboleth.

Configuration Choices

You can make changes to your Shibboleth settings as follows:
1. Go to Settings > Shibboleth in the network admin dashboard.
2.  Once you have made your changes click Save Changes at the bottom of the page.

Login Button Text


This is where you can change the text that appears on the button on the default WordPress login page.

Shibboleth Is Default Login
By default, it is set to force Shibboleth login and will redirect to your Shibboleth login page.
Uncheck the option to “Use Shibboleth as the default login method” if you need to add some users as local users and want to provide an option for users to log in as a local user or a Shibboleth user.

User Profile Data
Used to define the Shibboleth headers which should be mapped to each user profile attribute.  Managed profile fields are updated each time the user logs in using the current data provided by Shibboleth and users will be prevented from manually updating these fields from within WordPress

Create Blog
By default, it is set to create a blog the first time a new user signs in with their Shibboleth username and password.

Uncheck the option to “Create blog” if you only want user accounts created.

Blog Eligibility Header
Used to control which users have blogs auto created if you’ve unchecked “Create Blog”.  For example, you can use blog eligibility header set to auto create blogs for staff and faculty only; and students set to auto create usernames.