KB User's Guide - Documents Tab - Using the CampusAccess Setting to Protect Content
The CampusAccess field allows individual documents to be put behind a general campus login (e.g. user is required to have valid campus login credentials) and therefore not accessible to the general public.
- Review of the Internal and External Site KB Model
- Definition of a Campus User
- Using the CampusAccess Setting
- Including Inline Content For Authorized Users
Review of the Internal and External Site KB Model
Each KB space can have an Internal site and/or an External site. Typically,
- content published to the External site is publicly accessible by anyone with internet access.
- content published to the Internal site is restricted to your fully authorized internal users (i.e. those added to your Users list in the KB Admin Tools) as well as users authorized via a Group Authorization rule.
While it is possible to authorize all campus users for your Internal site by using the Group Authorization feature, doing so is only recommended if you will not be publishing internal content for a more specific set of users.
Definition of a Campus User
Regardless of whether you use the CampusAccess setting described below, it is always true that any campus user can successfully authenticate to your Internal KB site. However, when a user logs in, the KB performs a check to see what type of user they are. If they are a fully authorized internal user, or if they are a group authorized user, they will see all of your internal content as described above.
If they do not fall into one of those two categories, they are considered a campus user. A campus user who logs into your Internal KB site will see the site exactly as it appears under the External URL. Specifically, all homepage content modules, side modules/links, and site styling will match that of your External site.
Additionally, when a campus user searches for content, they only be able to find and access externally-published documents, as well as any documents that have been published with one of the latter two CampusAccess settings described below.
For additional information on the various user types and what they can see in the KB, please see: KB User's Guide - Explanation of User Types and Access Levels
Using the CampusAccess Setting
At the document level, you can make documents available to all campus users (i.e. users with valid login credentials for your specific campus). In the KB Admin Tools, there are three "CampusAccess" options found on the document edit screen (right below the "SiteAccess" field). The three radio button options are:
Defer to SiteAccess (External site = Public access with no login; Internal site = Authorized staff user access).
All documents are set to this option by default. If you leave this option selected, document access control works exactly as described in the first section—if the document in question is published externally, it will be available to unauthenticated users, and if it is published internally, that internal version will only be available to your authorized internal users.
Ext/Internal with campus login (Document title is exposed to External site but content view will prompt users to log in with their campus credentials)
Selecting this option allows campus users to search for and discover the document via your External site, yet ensures that the content is restricted to valid campus users only. "[Campus login required]" is appended to the title when it appears on external site.
When the user attempts to access the document, they will be prompted to log in with a valid NetID and password if they are not already logged in. At this point, they will be redirected to the Internal site URL. If they are not an authorized internal user, they will see the site as a campus user.
Note: Selecting the Ext/Internal with campus login campus access option requires that you check "Internal" SiteAccess so that the document content can be viewed there. However, you will be allowed to publish the document without necessarily checking "External" SiteAccess.
- Internal for all campus users (Document is available to all of your internal staff and ANY campus authenticated user).
This option makes the document available to any user with valid campus login credentials without having to expose your document title on the External site. By Selecting Internal for all campus users, those with a valid campus login credential can sign into your Internal KB site. If they are not an authorized internal user, they will see the site as a campus user.
Note: Selecting the Internal for all campus users option requires that ONLY "Internal" SiteAccess be selected.
Including Inline Content For Authorized Users
In some cases, you may wish to mix in content that is only intended for your authorized internal users. Normally you would do so with the inline internal content restriction tag; however, that will not work the same way when applied in a document available to campus users.
Instead, it is recommended that the restricted internal content reside in a completely different document. That separate document can then be incorporated into the campus accessible document with the use of the IncludeDoc custom tag. This would be achieved with the following steps:
- Create a separate new document with the internally-restricted information.
- If you only want this content to be accessible via the doc where you are embedding it, set the Search Priority to Exclude from Search.
- Set SiteAccess to your internal site only.
- Leave CampusAccess set to Defer to Site Access.
- Set the Status to Active.
- In the original doc where you are applying CampusAccess, type the document ID number of the newly created doc containing the restricted content and apply the Include Doc per KB User's Guide - Documents Tab - IncludeDoc and Dynamic Web Page Content.
Note: The embedded doc can be further restricted via the ReadAccess setting, which allows you to limited access to a specific User Access Group.
If you need clarification of what the best setting is for you and your specific present and future needs, please contact the KB Team at firstname.lastname@example.org for a consultation.