Sharing in SAS Drive (part 2)

[#1]

Let's look at the SAS Drive sharing feature in use.

This article is a continuation of Sharing in SAS Drive (part 1) and provides a more detailed look at the SAS Drive sharing feature. We'll see an illustrated story describing how it is intended to be used, and I'll give my observed answers to some questions I had about Sharing.

We'll also discuss the benefits and potential concerns that a SAS Administrator might have for sharing in SAS Drive and how to disable re-sharing or the sharing entirely for customers (or SAS Administrators!) who do not want to use it.

Sharing from your personal folder

The examples which follow use a SAS Visual Analytics deployment which was built for the Administration topics in a SAS Global Enablement and Learning (GEL) Viya 3.4 Implementers Workshop. In that workshop, the hands-on environment has users and groups, a folder structure and a security model for the permissions on those folders that were designed for a fictional organisation called GELCorp.

Hamish and his report

Hamish is a member of the HR department, and he's considered a SAS Visual Analytics expert by his GELCorp colleagues. He creates an example report which he thinks will be useful to others within GELCorp, illustrating how to use a particular feature in Visual Analytics 8.3. For this example, it doesn't matter what that feature is.

His example report displays data sourced from a table in an HR-managed CAS library, which is accessible to users outside HR, but has a row-level filter applied so that users only see data for their own department of GELCorp. So, Hamish sees only HR data:

Click any image to see a larger version.

He saves it in his own personal folder; his 'My Folder', as 'Hamish's example report':

This report is not intended to be an 'official' deliverable. Its purpose is not so much to present data for interpretation, but rather to be a working example of some feature in Visual Analytics that could be useful to others.

Hazel, Hamish's colleague in HR, sees this report and encourages Hamish to share the report with everyone in HR, so that anyone who is interested in it can take a look at how it works and learn about the interesting features it uses.

Inevitably, not everyone in HR is actually interested in Hamish's report. Hugh would prefer not to see it.

The GELCorp corporate folder structure

The GELCorp corporate folder structure includes folders for the HR department to use, and it has folders for ad-hoc 'Analyses', 'Data plans' and 'Work in Progress' (reports being developed for publication). As a member of HR, the security model grants Hamish permission to save a copy of his report into any of these folders, and he often does:

As an aside, the structure also has a 'Reports' folder for published HR reports, to which Hamish does not have write access to save or move reports. He needs a content administrator such as Alex, or the SAS Administrator, to publish - i.e. move or copy - reports into that folder for him.

Hamish decides that none of the available folders in the corporate folder structure are really the right place for a working example of some cool feature in Visual Analytics. The existing GELCorp folder structure was not designed with that use case in mind.

Hamish could ask Alex or a SAS Administrator to create and properly secure a new folder in the GELCorp folder structure for this purpose. But at that moment, he does not know whether he will ever want to share this kind of sample report with others again, or whether he will want to share it with the same group next time. Next time it might be someone in Sales who needs the example. Should he ask for a folder with a very generic name this time, just in case? Or will he ask for another folder next time? Or ask the administrator to change the permissions on the original folder if he wants to change the set of users with whom it is shared? There are formal processes for answering these questions, and they may result in the decision not to do something because it is too much effort, or too slow.

My point here is that users in real customer organisations come across perfectly valid reasons to share their work with others all the time, in ways that the corporate security model does not support, and cannot be efficiently adapted to support. In some organizations who follow a very formal way of working - usually for good reasons - this means the ad-hoc sharing is not appropriate. But in other organisations, enabling user-led, ad-hoc sharing will do more good than harm.

How Hamish can share his report efficiently

This is where SAS Drive is useful. Instead of saving a copy of his report in one of the 'official' GELCorp HR folders, Hamish opens SAS Drive, finds his report, and shares it with all of HR:

Permissions when sharing and resharing

As you can see, Hamish has a choice of two types of permissions when he shares the report; 'Can read', or 'Can read and edit'. In this case, 'Can read' seems the better choice; he doesn't wish to allow other users to modify his report.

If a user reshares an object, he can give the recipients no greater permissions than he has been given, in other words:

• If the object was shared with him (or a group he belongs to) as 'can read and edit', then if he reshares the report, he can choose to reshare with 'can read and edit' or just 'can read'.
• If the object was shared with him (or a group he belongs to) as 'can read', the most he can do is share it with other users or groups as 'can read'

Here, Hazel has shared one of her reports with Hamish, with only 'Can read' permission. When Hamish tries to share the report, the Share dialog still appears to allow him to share the report with someone else with either 'Can read' or 'Can read and edit' permissions:

However, if Hamish tries to share with 'Can read and edit' permissions, SAS Drive will not allow him to:

What can you share? Permissions needed on an object to share it in SAS Drive

Sharing and resharing are globally enabled by default, in the sas.authorization configuration instance for the Authorization service. An administrator can globally disable resharing only, or sharing altogether. I return to this at the end of this post.

While sharing is globally enabled, Hamish can share his report because he saved it in his 'My Folder', and he has the secure permission on everything in his own 'My Folder':

Permissions needed to reshare in SAS Drive

While both sharing and resharing are globally enabled, Hamish is also able to reshare any object that has been shared with him or with a group to which he belongs.

In summary, for the Share... menu item to be enabled for an object in SAS Drive, sharing (and if relevant, resharing) have to be enabled, and either:

• To share, you must have the secure permission on the object, or
• To reshare, the object must have been shared with you or a group you belong to

Opening an object that someone has shared with you

Now that Hamish has shared his report with HR, Hazel, Hamish's colleague in HR, can see his report in SAS Drive. She can open it and if she wishes to, save her own copy:

Chain Sharing

Hazel can see in SAS Drive who the report was shared with, by choosing the Share... menu option from the report object's menu in SAS Drive, if it is enabled. And as we discussed a few paragraphs above, she can also reshare the report with other users or groups.

Those other users or members of those groups could in turn reshare Hamish's report, and so on, creating a potential chain of shares for this report.

Here Hazel reshares Hamish's report with Sales:

Now Sasha in Sales can see Hamish's report too - and could re-share it if she wanted to. But notice that Sasha cannot see any HR data in the report, only Sales data:

This is because there is a row-level filter on the source table, limiting the data which can be seen by members of HR and Sales.

You cannot easily refuse a shared object

In this story, Hugh (also in HR) would prefer not to see Hamish's shared report among his list of items 'Shared with me' in SAS Drive. Perhaps one person has shared something with Hugh that he would like to see, and 100 other people have each shared 10 things with HR which he is not particularly interested in. He considers them 'spam'.

Can a user refuse or hide some shared items in the Shared view in SAS Drive?

From what I can find in the current version of Viya 3.4, it seems that there is not currently a way to do this:

Sharing from the corporate folder structure

Suppose that Hamish would like to share the design of (though not the data presented in) another report he developed, with all of the Sales group. But this time the report is in the GELCorp/HR/Analyses folder. Members of the Sales group cannot normally see that folder.

What are Hamish's options?

Sharing the report from the corporate folder is not an option for Hamish

If Hamish navigates to his report n the GELCorp/HR/Analyses folder in SAS Drive, he will notice that the Share... button is disabled, because:

1. He does not have the secure permission on the report - or on any other report in the corporate folder structure. That is very much intended in the GELCorp security model design - he was not meant to have that permission.
2. The report has not been shared with him.

Option 1: Hamish can save a copy and share it

There is nothing to stop Hamish from opening the report in SAS Visual Analytics or SAS Report Viewer, choosing Save As... from the menu, making a copy of his report in his own 'My Folder' where he has the secure permission, and sharing it just as he did above.

SAS Administrators should be aware of this. When Sharing is enabled, ANY report, or data plan, or other object accessible to a user can be shared using this method, even if it cannot be shared directly from its original location.

Every user has somewhere that they can share a report from: their 'My Folder'.

Option 2: Hamish can ask an administrator to share the report

Hamish does not have the secure permission on the report in its current location in the corporate folder structure, but some other users do.

One is the SAS Administrator, sasadm. Another is Alex, a member of the group GELCorp Content Administrators. Both are granted all permissions on GELCorp folder structure, which means they have the secure permission on the report and can share it.

Note that in neither of these cases would a member of Sales automatically get access to the wrong data in Hamish's HR report. The Sales person would only get access to the data they have been granted access to in CAS, if any. In the example I chose here, they see Sales-specific data in the report because Sales does the ReadInfo permission on the CAS library and table, and a row-filtered Select permission on the table, but if Sales did not have any access to the data in the report, someone in Sales could still open the report, but would see no data at all inside it.

There could, of course, be some members of the Sales group - such as Sophia who is a Manager - who do have access to the HR data because another group to which they belong (in Sophia's case the Managers group) is granted access to that data by design in the security model. But access to the HR data is not shared a result of the report having been shared with them.

How to disable sharing and resharing in SAS Drive

A SAS Administrator can disable part of all of the Sharing system in Viya 3.4, from the Environment Manager > Configuration page, under All Services > Authorization Service. There they can change either or both of the following settings to 'off':

• reShareEnabled: determines whether users can reshare resources that have been shared with them
• sharingEnabled: determines whether sharing is enabled

Both of these configuration properties are 'on' by default when Viya is first deployed.

Results of some experiments

I tried some experiments with my SAS Visual Analytics environment, asking some questions and finding answers as best I could. Here is what I found - some of this is explained in the documentation, but I wanted to try it for myself too:

1. Can a user share a report in their 'My Folder' with anyone at all? Even constructs like Authenticated Users, Everyone and Guest?
   • You can share with any user and any LDAP or Custom Group, and with multiple of each.
   • You cannot share with constructs such as Authenticated Users, Everyone or Guest.
2. Can you share your entire 'My Folder'?
   • No. The context menu for your 'My Folder' does not display the 'Share...' menu option.
3. Can you tell who shared an object with you?
   • Not exactly. You can see the object in the Shared folder in SAS Drive, in the 'Shared with me' view, so you can tell that it was shared with you. But you cannot directly see who shared it with you. You will often be able to infer who shared it with you from its properties, which include the name of the user who created it and who last modified it. But if it was reshared, especially in a chain, you may have no way of determining who shared it with you.
   • With a little effort, a SAS Administrator can work out who shared the object with you, by finding the object's URI, and searching for sharing rules in the SAS Environment Manager > Rules page, which target the object or one of its parent folders.
4. Can you see what objects you have shared with others?
   • Yes. In SAS Drive, the Shared folder has a 'Shared by me' view.
5. If something is shared with you, is there a way to hide it, or stop it from being shared with you?
   • No. You are stuck with seeing the object in SAS Drive. You would have to find out who shared the object with you, and get them to stop sharing it. Fortunately you can sort the objects shared with you by various of their attributes (e.g. name, date modified), which may help you find the one you are interested in.
6. Is there any limit to the number of items you can share? Or the number of users you can share an item with?
   • I cannot see any indications of limits for this.
7. Is there any command-line interface to Sharing?
   • End users are not expected to use the sas-admin command-line interface (CLI). SAS Administrators have access to the sas-admin CLI, where sharing rules can be viewed and deleted just like any other general authorization system rule, using the existing authorization plugin to the sas-admin CLI, e.g. /opt/sas/viya/home/bin/sas-admin authorization list-rules, or /opt/sas/viya/home/bin/sas-admin authorization remove-rule.
8. What happens if you disable resharing after users have already shared and reshared?
   • Users can no longer create new reshares, but existing re-shares remain in place. If sharing is still enabled, users can still share.
9. What happens if you disable sharing altogether after users have already shared and reshared?
   • Objects a user could see in SAS Drive because they were shared or reshared with that user disappear from SAS Drive, along with the whole Shared folder in SAS Drive. Nothing that was shared or reshared in the past is shared any longer. Nothing new can be shared: the Share... menu option no longer appears for objects in SAS Drive.
   • Share rules in the general authorization service remain in place. They just have no effect while sharing is disabled.
10. What happens if you re-enable sharing?
    • The Shared folder appears in SAS Drive again, along with the Share... option on each object's menu.
    • Any sharing rules created before these features were disabled are still present, and become effective again, so once again users can see things that were shared with them before sharing was disabled.
11. What happens if you delete an object that was shared. Are related sharing rules deleted?
    • Yes, sharing rules that target a report are deleted permanently when you delete the report. If you create a new report of the same name, is it not immediately shared because it has a new object URI. It's a different report.

Potential benefits and challenges of SAS Drive sharing for admins

Sharing in this sense presents SAS Administrators with a huge opportunity to free up their time for other work, but it also potentially presents a bit of a security concern and maintenance burden.

As we have discussed, the security concern is not really with data, because access to data cannot be shared, only access to other Viya objects such as reports and data plans.

But the fact that report even exists could be of concern to the SAS Administrator, in some situations. Hamish may have a legitimate reason to develop a report titled 'Employees likely to be fired'. But one hopes that he would not be irresponsible enough to share such a report, any more than he would be to give a copy of it to a colleague not authorized to see such sensitive content. But this is probably a niche concern.

The greater challenges for a SAS Administrator, as I see them, could be these:

1. Your users' view of content in SAS Drive may become cluttered with unwanted 'spam' which:
   • they are not and were never interested in some of it.
   • they may have once been interested in some of it, but are no longer interested in. Human nature suggests users will share readily and remove shares reluctantly, so that the volume of shared content will tend to grow with time.
   • A user may see shared items of the same type (report, data plan, code) with names which are similar or identical. How about seeing 15 different reports all called 'test'? Can you pick out the right one?
   • The number of objects shared with a user may be so large that it overwhelms the SAS Drive visual interface, making it harder for users to find shared content they actually want.
2. Users do not have a way to 'opt out of' or 'hide' content shared with them. The person 'sharing' the 'spam' may not feel it is 'spam', and may be reluctant to unshare it. SAS Administrators or departmental administrators may have to referee disputes about whether a users's personal content should be shared or not.
3. Once they discover sharing, the user community may prefer to share content with each other in an ad-hoc manner, because it is quick and easy, when they should really ask for and use a properly secured folder to collaborate, with correct permissions, even though that takes longer and requires more effort. SAS Administrators risk having their user base lose confidence or lose interest in the corporate folder structure. Administrators should periodically review content being shared, and if possible, figure out if large numbers of objects are being shared because there is not a suitable folder for more formal collaboration.
4. Administrators may find it impractical to support business processes involving content in a users' own 'My Folder', and may need to encourage users to use the corporate folder structure more.

Conclusion

Sharing is a very nice new feature in SAS Viya. SAS Administrators should be familiar with how it works and monitor its use in organizations.

I would expect that over time, SAS Drive in general, and the sharing feature, in particular, will evolve and become richer and more consistently supported across the SAS Viya visual interfaces.

I also expect that as more large organizations discover the impact that Sharing has on their user's experience and on their ability to effectively manage and maintain a good security model, we will learn what practices to recommend. At the time of writing, this capability is so new that it is difficult to anticipate what we should recommend to customers, but the SAS administration community will certainly be paying attention to this!