The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
iris_geist
ServiceNow Employee
ServiceNow Employee

This week I was working on a very interesting requirement - a customer wanted multiple CMS sites, but some public and others requiring login. After extensive searching, I figured I would create my own step-by-step guide on how to access a private and a public site created through CMS with Single Sign-on.

Why have some sites public and some private? For example, if your company wants to allow the public to interact with them through the ServiceNow pages, to read knowledge articles, submit product ideas, etc. this should be done through a public facing site that does not require login. To read internal knowledge articles, submit an incident with the IT department etc., login should be required and this requires a private site.

The prerequisite to this step-by-step guide, is that you have all your sites, pages, and content created and working. See Set up multi-provider SSO for details. SSO should be set up including the property that automatically redirects all users to the Identity Provider (glide.authenticate.sso.redirect.idp as described in Modify the primary and default IdP   )

To create public and private CMS sites you need to complete these three steps:

  1. Make CMS content publicly visible to all users
  2. Create a login page for sites that require authentication
  3. Modify the login dynamic content block to redirect to the default identity provider

If you are looking for more detail on Public pages asking for authentication read this post from jonnyseymour - it also talks about the property glide.ui.cms.enforce_public_pages that introduces an extra level of security on your public pages.

How to create multiple private and public CMS sites accessible with SSO

1. Make Content Management content publicly visible to all users

To perform this step, go to System Definition > Public Pages (or sys_public.list in the navigation filter text) and ensure that the entry for the page named "view_content" is set to be active.

cms content public.png

The page "view_content" is used for any CMS application, custom or out of box. Setting the page to active in the public pages application allows any user to access these pages without the need to log in.

Now that all pages on all CMS sites are publicly available, we have to undo this step for any site that should require authentication.

2. Create a login page for sites that require authentication

As soon as a login page is set for a site in the content management application, the user will be prompted for login every time this site is accessed.

CMS login.png

Out of the box, we have the Portal - Login Page, that you can copy to create your custom Login Page. Once you have your custom login page, associate it to the site as shown above.

3. Modify the login dynamic content block to redirect to the default identity provider

To determine into which dynamic content block to enter the below code, click on the i-Icon next to the login page.

dynamic block.jpg

On this screen, click on Edit Page.

CMS clean login.png

You will see the content block that contains the login screen. On the upper right corner, click on the pencil icon to edit this content block.

The original code will be similar to this:

<?xml version="1.0" encoding="utf-8" ?>

<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">

  <j2:set var="jvar_login_url" value="$[jvar_RP.getReferringURL()]" />

<center>

<div style="width:900px;text-align:left;">

  <g:insert_form name="login" />

  <g:inline template="welcome_content.xml"/>

</div>

</center>

</j:jelly>

I got the code snippet to redirect to the IdP from this great post by goranlundqvist A mix of Service Portal, public pages and SSO

<j:set var="jvar_user_loggedin" value="${ gs.isLoggedIn() }"/>

<j:if test="${jvar_user_loggedin == false}">

  <script>

  top.location.href = "../saml_redirector.do?sysparm_uri=/<your site URL suffix>/<initial page, such as home.do>";

  </script>

</j:if>

Merging this code snippet with the original code:

<?xml version="1.0" encoding="utf-8" ?>

<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">

  <j2:set var="jvar_login_url" value="$[jvar_RP.getReferringURL()]" />

<j:set var="jvar_user_loggedin" value="${ gs.isLoggedIn() }"/>

<j:if test="${jvar_user_loggedin == false}">

  <script>

  top.location.href = "../saml_redirector.do?sysparm_uri=/<your site URL suffix>/<initial page, such as home.do>";

  </script>

</j:if>

<center>

<div style="width:900px;text-align:left;">

  <g:insert_form name="login" />

  <g:inline template="welcome_content.xml"/>

</div>

</center>

</j:jelly>

If the user is not yet logged in, this code will redirect to the SAML IdP defined in the system, and then have that IdP redirect back tot eh sysparm URI, such as https://<instance>/ess/home.do

Following these outlined steps, you can have some sites that require login, while other sites and their underlying pages are completely publicly accessible. This will give you better control over what your customers can see and do with and without authentication.

2 Comments