Wednesday, September 19, 2012

Word Problems: Security and Terms in SharePoint 2010

  By EPC Group's Sr. SharePoint Architect Timothy Calunod

I will begin a new aspect of this post I will call Word Problems, which will focus on one-off issues, concerns, questions or challenges I have encountered related to SharePoint. At this point the plan is to slip these in between my more serial posts, but as they say, even the best laid plans and whatnot… 

A very recent question that was brought up was related to the availability of terms from the Managed Metadata Service to its subscribers, in particular, what terms from the Managed Metadata Service are available for a user to see. For example, if Zoe is only allowed to see certain terms from a Managed Metadata Service, how can the Site Owner or SharePoint Administrator restrict his viewing and using of such terms? This is the gist of the scenario, but not the complete description, as we need more information before we can proceed. 

Terms Management Overview 

To understand the scenario a bit better, a quick review of how Terms are stored and managed is necessary. I have previously discussed this with a bit more depth in my discussion about Choice Term Sets, but to keep in focus for this discussion, we will review this at a very simple level. 

Managed Terms are stored in the MMS (Managed Metadata Service Application) and are organized at two levels: Term Groups, which provide a layer of management security, and Term Sets, which organize a group of terms into a hierarchy. The Term Groups are necessary to have Term Sets, and will define who can control the editing of any Term Sets in that Group. The Term Sets only define the hierarchy of terms, including the root term of the grouping, but can be used to open a set of terms for editing if necessary. This latter part is important for allowing users to define a managed set. 

The entire scenario looks like this: There are two Term Groups, Marketing and Sales. The Metadata in Marketing should be restricted to only users of the Marketing Term Group, and thus should not be seen or accessed by the users of the Sales Term Group. Now, if Zoe is setting up a a local Site Content Type in the Sales Site Collection, and she applies a new Managed Metadata Column to the Site Content Type, when she goes to select which Term Set to use for the column, can she see and use the Term Sets from both the Marketing Term Group and the Sales Term Group? And, depending on the answer, how can we control this, if it is possible? 

Terms Availability Basics 

According to this Technet Article about planning for Terms and Term Sets, specifically when planning for Term Groups, when separating Term Sets for visibility purposes, a Term Store Manager should create different Term Groups and create the specific Term Sets into the proper groups. However, when we do this, such as creating a Marketing and Sales Term Groups, we find that a Site Owner can create a Managed Metadata Column using either of the Term Sets from either Term Group: 
Thus we see that Zoe can still access the Marketing Term Group and associated Term Sets despite the separation of Term Groups. This is not unexpected, but as limiting as it could be. There are several possible solutions that can help to control both management and visibility, and each one requires some consideration when planning to implement them. 

It is important to remember that all users are provided the ability to apply or tag metadata through the Managed Metadata Column if they have Edit access to a List or Library, so visibility and access can begin with simply ensuring that the Site Owner creating a Managed Metadata Column only select the Term Set or Term they wish to be applied to a List or Library. This will prevent suggestions from other Term Sets automatically. 

Solution #1 – Separate Term Stores 

The most obvious conclusion for a SharePoint Administrator when deciding on how to separate Term Sets from availability is to create multiple Term Stores (via MMS) and thus limiting which Web Application will subscribe from the proper Term Store. In application, this would mean that two Managed Metadata Service Applications, such as MMS-Marketing and MMS-Sales would need to be created, and two Web Applications, such as Marketing and Sales, would also need to be created and associated with the correct MMS. In this case, the Marketing Web Application could be associated with both MMS Applications while the Sales Web Application would only be associated with the Sales MMS. The major limitation is in the architecture, as this would complicate matters tremendously and would not scale well at all. And while this can have application in some scenarios, in a single Web Application, single MMS, this would not apply. 

Solution #2 – Local Term Sets 

When working with Term Sets, a SharePoint Administrator will work with Global Term Sets, which are Term Sets that are made available to all associated Web Applications. A Local Term Set is a Site Collection-bound Term Set, in that it is created from the Site Collection and only visible and available to that Site Collection. A Local Term Set is generated when a Managed Metadata Column is created; instead of applying an available Term Set from the associated Term Store, the Site Owner can customize options by creating their own Term Set. This in effect will create a specialized Term Group for that Site Collection and will automatically limit visibility of that Term Set to prevent others from viewing that content.
When generating a new Managed Metadata Column, the name of the column automatically becomes the name of the Term Set, logically associating the new Term Set with the column. Once a Local Term Set is generated, it can be managed and accessed like any other Term Set in the Term Store for any other Managed Metadata Column, but only for that Site Collection. The Term Group will be named after the URL of the Site Collection with a Site Collection label as a prefix, but this can be changed as well.
In order for this to work, two important configuration on the MMS must be set: first, the MMS must be set to be the default location for column-specific sets, as configured on the Proxy Service Connection properties of the MMS, and second, there can only be one default store for one MMS associated with one Web Applications, similarly to how Enterprise Keywords are associated with one MMS to one Web Application. 

 In fact, the Local Term Sets appear beneath the System Terms (where the Enterprise Keywords and Orphaned Terms are stored) in a similar fashion.
Thus we find an effective method for creating secured Term Sets per Site Collection, and thus limiting other Site Collections from seeing and accessing these terms. Additionally, these Terms and Term Sets can be copied, moved and reused like other terms, although the Term Store Manager cannot access them except through the Site Collection Term Store Management Tool directly. 

Our only issue now is that if we have users in the same Site Collection, we cannot limit the visibility of specific Term Sets using this method, as the Local Term Sets are still available throughout the Site Collection as the Global Term Sets are. 

Solution #3 – Unavailable for Tagging 

Another possible solution, with limited application, can be configured using the Term Set configuration for Tagging. By default, all terms in a Term Set are available to be applied or tagged to items in List and Libraries as needed, but this can be changed either at the Term Set level or at an individual Term level by the Available for Tagging checkbox. By deselecting this checkbox, a Term or entire Term Set will be unavailable for choice in a Managed Metadata Column and thus cannot be applied at all. This can be useful if certain terms should be completely managed by a limited body but not available to the general public. 

To further limit access to restricted terms, a Local Term Set could be generated first, and then a specific Term Set could be marked as unavailable for tagging as well, to create, at least at this point, the most granular level of visibility limitation we can configure at this point. 

The major limitation is that the Term or Term Set must be toggled to make it available to be applied and then retoggled to remove its availability for tagging. Thus a very limited application would ensue, one that would require some, if not significant, administrative overhead to manage.

Managed Metadata in SharePoint 2010 can be quite fantastic, but there are still many interesting limitations and shortcomings that may need to be addressed before it can be flexible enough for a complete metadata management system. However, even at this stage, using Local Term Stores and possibly even using Tagging limitations can provide a degree of control expected in an organization's metadata management governance. Until then, some careful or thoughtful (or both) planning should be made when determining how to apply term availability through Term Sets.