CSM - snc_external unable to access platform features [SSO login, Document Viewer, Cart, scripts]

[Michael Jones -]

I've had some recent experience setting up a CSM implementation that incorporated a number of platform features that I quickly discovered were not immediately available to CSM Contacts with the snc_external role. This role is a feature that is enabled with the Explicit Roles plugin and is intended to simplify maintaining security when providing external users access to your instance, and it performs that function admirably and effectively. In some cases a little too effectively.

There are a number of platform features that are impact by the assignment of the snc_external role; some of the solutions are documented, others not quite so clearly, so in an effort to potentially save others the same hunting and digging that I went through, I've documented my findings in a single article. 

We'll start with some basics that are documented, but still warrant some consideration.

Script Includes for snc_external users:

Any script includes that you create (and some out of the box ones) that will be called under the context of a user with the snc_external role will require the creation of an ACL to make it available. This would include GlideAjax calls. If the resource needs to be available to internal users as well, you will need to include the snc_internal role in the ACL. 

UI pages for snc_external users: 

For the most part you probably won't be using any UI pages for external users, but there are exceptions. In my case one issue was that snc_external users could not access ANY Service Portal pages, including the ones we were building explicitly for them. They also failed to be redirected after SSO login when hitting the site (where internal users had no issues) which was perplexing. 

It turned out that $sp was set as inactive in the sys_public table (making it no longer public, as a hardening precaution) so we had to include an ACL specifically for that UI page. 

Service Portal Widgets for snc_external users: 

There are a number of out-of-the-box Service Portal widgets that just won't work for snc_external users; you would need to modify them (in the global scope) to include the snc_external roles (one of the few changes you can make to an OOB widget). It goes without saying, if you create a new widget, you will have to add this role as well.  

Service Portal Pages for snc_external users: 

Same as with widgets, you'll need to include snc_external in the roles for each page you want them to be able to reach! Otherwise they will be playing a lot of breakout! 

Now, for some of the more esoteric features that I came across...

Using the Cart for snc_external users:

If you want External Users to be able to use the Service Catalog with the Cart, and have the small-cart on the header menu in functional order, well you're in luck. So did we and this is what we figured out. You need to add the snc_external role to the cart widget (seems obvious) but you will also have to add the snc_external role to the these ACLs

sc_cart             read

sc_cart.*          read

sc_cart_item    read

Displaying Documents with Document Viewer for snc_external users: 

We wanted to be able to let an external user click a link and view pdf files in a modal, instead of being forced to download them. This called for document viewer!

The first step was creating a Knowledge Base and articles to contain the pdfs and providing permissions to snc_external to view, etc. Then, create the formatted URLs for the documents.

Next you need to add $viewer to the sys_public.list and set it to active. 

Last, you need to create an Execute ACL for the script include ConversionRequestUtil; without it, the whole thing fails. 

Users vs. Contacts:

One of the more challenging aspects of CSM is the distinction between users and contacts. 

Users in this context will be those that perform work within the CSM space; they are the fulfillers, shakers and do-ers. They will always be snc_internal and will have additional roles.

Contacts are the entities that request and receive the end result of services that you offer. They will only have the snc_extrrnal role and outside of some very unusual situation, nothing else. 

A user cannot be a contact, and a contact cannot be a user!

The challenge here is when organizations use the same processes internally as well as externally, which presents some challenges with the out-of-the-box configuration for case. An agent can't open a case for themselves, for example, at least not without some customization to allow the selection of any user vs. only contacts. 

Overall advice and closing comments: 

Users with the snc_external role are intended to be the least privileged class of user possible; one tiny step beyond public! Keep that in mind! Until you have explicitly reviewed and configured something, assume that it won't work for an snc_external user the way it might for an snc_internal user.

That mind-set will save you some headaches and frustration along the way. 

If you found this article useful or helpful, please be kind a click appropriately! If you really found it useful, maybe bookmark it for later reference 🙂