Authentication (Secure Pages)

Restrict access to your published pages. 

On this page:

Last reviewed: March 1, 2024

Overview

Using Shibboleth, Lightweight Directory Access Protocol (LDAP), and Secure Socket Layers (SSL), it is possible to limit access of your published pages to specific LDAP groups or named UB constituents.

Implementation in the UBCMS

Access is restricted through an authenticated page whose name must end in “–pw” (e.g. mypage-pw). This will limit access to that particular page (i.e. mypage-pw.html) and its children.  (Also the public URL for your new page will always begin https://.) The actual restrictions are set in page Properties.

Within the UBCMS, all hostnames (subdomains) are certified for secure pages (e.g. WWW.buffalo.edu is a hostname, as is NURSING.buffalo.edu). All secure pages rely on a certificate for that hostname, and for all UBCMS pages, the certificate is managed and paid for centrally by UBit. But if your unit operates its own servers with an independent certificate, your unit would be responsible for purchasing and managing that on your own.

Secure pages appear in your site's navigation and lists/carousels in Author, but on your live site, are hidden unless a user has access to view the pages, has authenticated (logged in to a secure UB system), and the user is within the secure part of your site -- otherwise the pages will essentially be invisible. To make secure pages visible in site navigation or lists/carousels, see the Advanced Section below.

The UBCMS is not an appropriate place for ANY regulated private data; e.g. bank credit/debit card numbers, government-issued ID numbers, health information, or computer passwords.

Secure pages will initially load slowly

Each time a user accesses a secure page within a 24 hour period, their account needs to sync. Once the sync has finished, refreshing the page should be the same speed as a regular page. > Read more about this Known Issue.

Authentication is only provided on the public site

Any UBCMS user who can normally see your pages in the UBCMS will also be able to view your authenticated pages while in the authoring system. (All UBCMS users can view any page in Shared Content.)

If you also need privacy from other UBCMS users, place the content on a secure regular page in your site (not in Shared Content), and ask us to create a new explicit permissions group to limit access. Choose the option "People in your existing group(s) will LOSE access to these folders. Only this new group will have access." Or use the Private Authoring feature to control whocan view/edit/publish these pages.

Also remember that content in Assets is normally visible to all authors, and when you add an asset, it is even promoted as "new" to all authors at the top of the Assets Browser. If you need to keep them private in Author (e.g. details of a special unannounced event or a restricted-use photo) consider embedding them directly into your page, or use Private Authoring.

> Learn more about Private Authoring

Secure Documents

If you wish to publish any documents on your secure pages that you do not wish ANYONE else to see (i.e. not even other authors), attach them directly to one of your secure pages and do not host them in the DAM. (All authors can view ANY documents that are in the DAM.)

Create the “–pw” Page

Create the new page. The name of must end in “–pw” (e.g. mypage-pw).

This will limit access to that particular page (i.e. mypage-pw.html) and any of its children. 

Set up your page as desired, then adjust that page's settings in Properties as described in the next section.

As soon as a page's name ends in "-pw", users are required to login. The additional Page Properties settings simply define the access limits more narrowly.

Secure the Page

screenshot of the Equalizer button.

Equalizer button

  1. In the Edit Console, click the Equalizer button, then Open Properties and a new screen will load.
  2. Select the Advanced tab, then scroll down and expand the Authenticated Published Pages section. 
  3. Check Authentication Required. (This turns on your narrower restrictions.)
  • Allowed
    • All users - Limit access to only people with a UB account, select ' (NB. all "-pw" pages by default are limited to 'All Users.')
    • All faculty/staff - Limit access to only UB faculty and staff.. For this setting, the UBCMS uses whomever is coded in LDAP as 'staff.' This excludes volunteer accounts and retirees, but includes people with emeritus in their title even if they are marked as a retiree.
    • The LDAP field only has one value--someone cannot be both student and staff. We believe most student and graduate assistants are marked as a student and not staff so they will be excluded.
  • Additional Users/Group.
    • Limit access to specified users and/or groups of users.
    • These must be in the form of individual UBitnames or LDAP groups.
    • You can mix and match groups and userids but each group or user designation must be added as a separate value.
    • Click Add to add one or more users or groups, for example,
      • ub_all_staff   [all UB staff]
      • uw-apy  [Anthropology faculty & staff]
      • jjs58  [user with UBitname "jjs58"]
      • hjarvis [user with UBitname "hjarvis"]
Limited to UB Accounts

Access can only be controlled for UB employees and students (or a volunteer appointment). A UBITName is required.

More about LDAP groups

Limiting by LDAP groups is probably best used in cases where another process is already maintaining those groups, such as Student Accounts, and also when the group is too large or unpredictable to manage yourself in the page Properties.  

Some units already maintain LDAP groups for other purposes that may be of use in identifying your staff or faculty or students, so we encourage you to consult with your department IT staff.

Developers with Unix knowledge can look up LDAP group and its members by connecting to ubunix.buffalo.edu through SSH-Telnet. Run these command line queries:  

  • grep keyword /etc/group  where keyword is a UBITName, LDAP group, or a partial string of either. This will check if that group exists, and display UBitnames associated with it where that group is not their primary group..
  • grep :groupID: in /etc/passwd which will display the names of anyone where this is their primary group.
  • groups UBitname to display which groups include the specified person (identified by their UBitname).

Note: UBit may refer to these as 'UBLDAP' groups, to distinguish them from the Active Directory (UBAD/ADFS) groups that are used by systems such as email.

Requesting or Adjusting an LDAP Group

Site Owners or Site Managers only!

LDAP Groups can be created or adjusted directly by individual offices through the UBIT Help Center.

  • Brief Summary: specify "LDAP group adjustment".
  • Requested on Behalf of Name: your name.
  • Requested on Behalf of UBITName: your UBITName.
  • Preferred Contact phone number: your office number.
  • Service or Machine Name: specific Accounts.
  • Description: state "create new LDAP group", or "change existing LDAP group"
    • clearly state the existing or prefered LDAP group name
    • clearly state adjustments; e.g.
      • ADD John Doe (jdoe)
      • REMOVE John Doe (jdoe)

Using LDAP Parameters on a Page

Once a page is secure, because the visitor is now identified, the following parameters are available from LDAP (with an example of the output for Jerod Sikorskyj):

id                   jjs58
path              /home/users/j/jj/jjs/jjs58
displayName  Jerod J Sikorskyj
givenName    Jerod
familyName   Sikorskyj
phone           645-5195
email            jjs58@buffalo.edu
affiliation     staff
department Enterprise Application Services
title             Application Developer
address        108 Academic Center

To use any of these parameters on an authenticated page, you must use the User Info Loader component, located in the author Sidekick under “Form Components.”

Place the User Info Loader component at the top of the page.

  • Click on the “+” sign to add a field (“+”changes to a “-“ sign so it can be removed). 
  • To make an LDAP parameter available for inclusion on your page, use this syntax:
                    #<variable>=<LDAP parameter>
                    e.g.        #your_name=displayName
  • Anywhere in your page that you put an HTML snippet with a named element (e.g. #your_name), the text of that HTML element will become the value of that LDAP variable. So in the above example, <h3 id="your_name">text_to_be_replaced</h3> will display an H3 heading with the value of displayName when published.  
  • To use an LDAP parameter in a form, use this syntax: 
                    input[name=<variable>]=<LDAP parameter>
                    e.g.        input[name=emailAddress]=email
  • You would then insert a Form container as usual and add the appropriate input fields. 
  • For example, to use an LDAP parameter in a Text Field, set the component values to:
    • Element Name: variable (e.g. Element Name: emailAddress)
    • Title: whatever text you wish
  • Each variable must match the value you used in the User Info Loader component for name=<variable>; in this case, emailAddress will automatically pull in their email address.

Make sure to activate all pages to the publisher to test them live.

An Example

Here is a sample form that includes the user data drawn from LDAP. Access is limited to anyone with a buffalo.edu account.

> Secure test page example

Was This Information Helpful?

(Required)
(Required)
(so we can thank you or request more details)
(Required)
(buffalo.edu addresses only please)
(Required)