SharePoint MetaData and Classification

Building a Custom Claim Provider to Manage Security Clearances

Microsoft SharePoint 2010, with its built-in support for retrieving trusted attributes about a user upon login (or what is commonly referred to as claims), can be used to authenticate users and authorize access to content. As I’ve written about previously, this allows businesses to implement new and interesting information protection policies. SharePoint also allows us to build and deploy custom claim providers that can retrieve attributes from a wide variety of sources and transform them in order to enforce specific policies within SharePoint. This article will walk through a simple example of building a custom claim provider and review some of the technical considerations that need to be taken into account.

A few weeks ago I gave a talk the Federal SharePoint User Group in Washington DC. Really good group there! Thanks to the 40 people or so that dialed into web cast for it. I`ve been traveling a lot the last few weeks with RSA 2012 and other shows, but I`ve finally gotten a chance to put the sample claim provider code I used in the presentation on our blog. Its a simple example and the process of building a claim provider is not too hard, but it is worth walking through the steps.

First I need to thank the excellent articles on Steve Peschka’s blog for the background and detailed information about developing for SharePoint using claims and federated identities. I highly recommend you check them out. The example here is based on some of those examples, but I’ve built this code with a different use case in mind and some additional detail in some of the steps in order to assist those developing custom claim providers for the first time.

Where do Custom Claim Providers Fit

In order to see how a custom claim provider fits into a SharePoint architecture that uses claims based authentication, you can refer to a previous article I`ve posted: An Architecture for Claims Based Authorization in SharePoint.

At a high level, here is what this could look like:

Using Claims for Authorization in SharePoint 2010

The Scenario – Setting It Up

In the Intelligence, Military and Government community, our customers tell us that managing an user’s security clearance is no trivial task. Users can have a wide variety of security clearances, and often there is a hierarchy associated with them. For example, if a user has Secret clearance, that typically permits them to access content that is classified as Secret and Confidential (with Confidential being the lower security clearance), but not Top Secret. If a user has Top Secret clearance, then they’re permitted to access content classified as Top Secret, Clearance and Confidential. Within a user’s identity however, customers often do not want to store multiple security clearances for them – they typically just want to store the user’s highest level of clearance, and have logic for determining all the content classifications they’re permitted to access executed somewhere else. This is the scenario that our example will follow.

A user will login to SharePoint and we’ll assume that a single security clearance (their highest level) is retrieved from an external trusted provider like ADFS 2.0. Our custom claim provider will then examine the clearance level returned and execute some simple logic to add any additional security clearances the user is entitled to.

Step by Step – Building a Custom Claim Provider for Security Clearance

1. Create a New Project
We start building a Custom Claim Provider by creating a new SharePoint 2010 project in Visual Studio 2010 (or later) and selecting an Empty SharePoint Project. Remember a custom claim provider will only be invoked in a web application that is configured for Claims Based Authentication, and Claims Based Authentication is only supported in SharePoint 2010 or later. Be sure to give your project a meaningful name, like ClaimProviderSecurityClearance.

2. Add the necessary References, Start a Class and Add Using Statements
You will need to add references to Microsoft.SharePoint (which will likely already be there) and Microsoft.IdentityModel. To do this, right click on References in the Solution Explorer pane, select Add References and selected the DLLs listed here. For the IdentityModel reference, you’ll need to browse to find it here:

\Program Files\Reference Assemblies\Microsoft\Windows Identity Foundation\v3.5\Microsoft.IdentityModel.dll.

Add a new class by right clicking on the project name in the Solution Explorer, selecting Add, then Class… In the Add New Item window, select C# Class and give it a meaningful name. A .cs file will appear in the main editing window, which will have some basic Using statements, and a skeleton class with a namespace that matches your project name.

Add the following Using statements to the ones already provided:

• using Microsoft.SharePoint;
• using Microsoft.SharePoint.Administration;
• using Microsoft.SharePoint.Administration.Claims;
• using Microsoft.SharePoint.WebControls;

Mine looks as follows:

3. Modify Your Class to Inherit from SPClaimProvider
You need to modify the class that you added to inherit from the base class SPClaimProvider. At this point, mine looks as follows:

4. Implement the Abstract Class
To get a skeleton implementation of the other class members, simply implement the abstract class by right clicking on base class SPClaimProvider in your .cs file and select Implement Abstract Class. This will result in a skeleton implementation of the following.

Members:

• FillClaimTypes
• FillClaimValueTypes
• FillClaimsForEntity
• FillEntityTypes
• FillHierarchy
• FillResolve(2 overrides)
• FillSchema
• FillSearch

Properties:

• Name
• SupportEntityInformation
• SupportHierarchy
• SupportResolve
• SupportSearch

As we move on, we’ll focus mainly on the implementation of the FillClaimsForEntity method and a number of helper methods.

5. Define the Properties for the Custom Claim Provider
Scroll down within your class and find where the implementation resides for the properties listed above. We need to set the appropriate properties to true depending on the behavior we want to achieve with our provider. The most important properties to consider for this example are Name and SupportsEntityInformation. The latter is important because you must set this property to true, if you are to implement the FillClaimsForEntity method and transform or augment the claims within the user’s identity. If set to false, then FillClaimsForEntity will not get called and you will not be able to manipulate the user’s claims. This section should look as follows:

The final 3 properties relate to the modifying the people picker used to select claims, users or groups in a claims based authenticated web application. Setting them to true is not strictly needed for this example, but if we want the claims defined by this provider to appear and interact appropriate with the people picker then they must be set to true and a basic implementation is required (which is shown below).

6. Create Static Properties for Name and Helper Functions
Next we need to create the following static properties in order to implement the provider’s Name, and the following helper methods to define the Claim Value and the Claim Value type:

Notice the URI used to define the claim value we’re working with (http://schemas.sample.local/clearance) which represents a security clearance. The URI can be anything you like, but it should follow a similar format for readability. The right most portion after the final / should be a meaningful name for the claim value because this is what will appear in the people picker in SharePoint. We have also defined the claim value’s type to be a string. This can be the same as a claim value that is returned from an external trusted provider like ADFS 2.0 if you wish to manipulate it after the user authenticates to ADFS 2.0. This example only defines 1 claim value, but if you were to work with multiple claim values within a provider you would replicate the following methods for each claim value you’ll be working with and give them each a unique name:

• ClearanceClaimType
• ClearanceClaimValueType

And then within the methods FillClaimTypes and FillClaimValueTypes you would have one claimTypes.Add() statement for each Claim Value you are working with.

7. Implement the Data Source and the Methods to Augment Claims
Up until this point, we were still putting in place the plumbing that is required by any custom claim provider you might build. Now we start adding our specific logic for managing security clearances in this simple case.

First we add our data source and another helper method as shown here:

Notice that for example purposes only, we’re using a simple array to define the data source and it contains only 4 possible security clearances defined simply as strings. In a real production environment, a more robust system may be used for storing and retrieving these types of attributes like MS SQL Server, an LDAP database, a PKI or Identity Management system.

The helper method shown DoesClaimValueAlreadyExist() is really useful for determining if a specific claim exists with a specific value in the user’s identity after authentication to a trusted external provider has already taken place. In this example, our external trusted provider is returning an attribute which defines the user’s highest security clearance. If the claim exists with the specified value, it simply returns a boolean. It is used heavily in the next step.

Next we’ll implement FillClaimsForEntity() where are logic for managing clearances exists. It will look as follows:

As you can see, the logic here is quite simple. Just check what their highest level of clearance is, and based on that add all the lower level clearances the user is entitled to. This logic could certainly get more complex, especially if we take things like Caveats into account or what department a user belongs to.

8. Implement People Picker Related Methods
In this example, we are not customizing the experience within the people picker so we are only including a very basic implementation here. If your business requires that the people picker be customized (because the experience is not great with claims out of the box) then you would do this by implementing a custom claims provider – look for more on that in a future post. Here is what it looks like without any customization and, although usable, it has many issues that I’ll get into in another post as well:

A minimal implementation is required in order to simply have the Clearance claim included in the people picker when it is used. The implementation would look like this:

The specific purpose of each method is as follows, related in each case specifically to the claims defined in this provider:

• FillEntityTypes – Set of possible claims to display in the people picker
• FillHierarchy – Determine hierarchy for displaying claims in the people picker
• FillResolve(2 overrides) – Logic for resolving claims specified in the people picker
• FillSchema – Specifies the schema that is used by people picker to display claims/entity data
• FillSearch – Fills in search results in people picker window

9. Define the Feature Receiver that Will Deploy the Custom Claim Provider
Custom claim providers are deployed to SharePoint 2010 as farm level features so they must be built within the context of a SharePoint feature receiver. To do this, we’ll add a new class to the project as we previously did (right click the project in the Solution Explorer, select Add, then Class and select a C# class).

The class will need to inherit from SPClaimProviderFeatureReceiver and it should look exactly as follows (with your namespace and class name):

Next we’ll need to right click on Features in the Solution Explorer and select Add Feature. You’ll see a file called Feature1.Feature. Here you must select Farm in the scope drop down and click Save. Then in the Properties pane on the right side you’ll need to set the Receiver Assembly and Receiver Class properties correctly.

This should allow the feature receiver to be deployed correctly to your SharePoint server from within Visual Studio. If you perform the deployment, then go to Central Admin and Manage Farm Features you’ll see your Custom Claim Provider listed and active by default.

Congratulations! You’ve just built and deployed your first Custom Claim Provider.

Testing Your Claim Provider

Remember, this claim provider is dependent on a few things, namely:

• One of your SharePoint 2010 web applications must be enabled for Claims Based Authentication
• A ‘clearance’ claim must be first returned from an external trusted provider like ADFS 2.0

If you are using ADFS 2.0, remember you need to first map the expected claims into SharePoint using PowerShell. If this is not done, SharePoint will simply ignore any incoming claims that have not been mapped.

If you don’t have ADFS 2.0 in place returning such a claim, you can simply add 1 more claims.Add() statement near the beginning of the FillClaimsForEntity() method that starts the user off with one of these particular claim.

Then you simply login to your SharePoint web application that is claims enabled and see which claims have been retrieved.

When you login, you’ll need a way to see what claims have been returned for that user. To help with this, we highly recommend installing the following Claim Tool for SharePoint. It will allow you to quickly view what claims SharePoint has retrieved for the user in question. I have the web part added at the site level so I see it as soon as I login and its invaluable for debugging.

Conclusion

Building custom claim providers is not difficult and, because they run as features on the SharePoint server at the farm level, they can help to implement some really interesting policies related to authenticating identities and authorization.

Once a user has signed in and their claims are retrieved, SharePoint 2010 does a great job of enforcing access control on documents/items to which claims have been assigned. Of course a user must have those claims as part of their identity to gain access to a document or item with the assigned permission level. Transforming claims in this way after they have been retrieved from ADFSv2 can allow you to implement some very robust access control policies in SharePoint. Applying those claims with permission levels to documents and items in SharePoint is still a manual and labor intensive task that can be very error prone – for more information on how the TITUS SharePoint Security Suite can automatically assign such access control policies at a fine grained level in SharePoint please read the white paper Microsoft SharePoint Security – Harness the power of claims to protect information or check out the video.

Enjoy.
-Antonio

SharePoint Security Paper: Harness the Power of Claims to Protect Information

The topic of claims, or trusted user attributes, is an established and well defined concept within the
identity management space. In SharePoint 2010, Microsoft introduced support for a claims-based identity model. Claims-based identities can be used in Microsoft SharePoint to enhance the process of user authentication. By harnessing the power of claims and extending its use to authorization, organizations can also effectively manage security and governance policies for accessing valuable information assets. It is important to
understand the many concepts of the claims-based identity paradigm in order to implement granular,
scalable and dynamic security within Microsoft SharePoint.

Organizations can implement and effectively leverage user claims in Microsoft SharePoint 2010 to securely share sensitive information. By implementing claims-based authorization in SharePoint and leveraging the benefits of trusted user attributes, organizations can solve many of the security challenges they face in their collaboration and file sharing environments. Further, it becomes evident that in order to properly manage security and fully realize the potential of claims, organizations must have solutions that automatically enforce access control and security policies on all of their SharePoint content.

This new white paper describes how organizations can implement and effectively leverage user claims in Microsoft SharePoint 2010 to securely share sensitive information.  Download the “Harness the Power of Claims to Protect Information” white paper, or go to our webpage, and learn how you can successfully implement claims-based authorization across all the SharePoint content in your organization.

Adding Security to SharePoint for Stronger DoD 5015.2 Compliance

DoD 5015.2 mandates requirements for DoD records management systems. The ability to add metadata tags and to secure these tags is one of the key mandatory requirements. The general access control requirements are defined in section C2.2.8. Though SharePoint by itself can meet most of these security requirements, it can be overly complicated to setup security permissions in SharePoint especially when trying to protect information at the record level. Titus has developed a number of SharePoint security solutions which make it easier to meet DoD 5015.2 security requirements when using Microsoft SharePoint.

Automating Security Permissions Titus Metadata Security for SharePoint allows DoD administrators to quickly configure and maintain appropriate security permissions for their records. The solution allows administrators to automatically apply SharePoint permissions based on the record’s metadata. The example below shows how administrators can build simple rules in Titus Metadata Security for SharePoint to automatically maintain correct security permissions. This example shows how records with metadata = "Finance" can be automatically assigned SharePoint permissions.

 

Click to view larger image 

For the handling of Classified information DoD 5015.2 requires additional capabilities. One of the additional security requirements is defined in section C3.1.21. which states “RMAs shall provide a capability whereby authorized individuals may restrict access to records and their metadata based on access criteria. In addition to baseline access restriction capabilities, these additional criteria include:

C3.1.21.1. Current Classification (subparagraph C3.T1.2.).

C3.1.21.2. Supplemental Marking List (subparagraph C2.T2.6.).

C3.1.21.3. Metadata Elements identified by the organization to be used for access control.”

Titus Metadata Security for SharePoint meets the requirements of C3.1.21. The example below shows how an administrator can build a rule so that permissions to records are granted based on the record’s current classification.

Another requirement for the handling of Classified records as stated in C3.2.2. is the Marking of Printouts and Displays. “Current classification, reasons for classification, and downgrading instructions should be required metadata items for displays, printouts, reports, queries, review lists, etc. when organizations implement classification restrictions on individual selected metadata fields. The highest classification level shall be displayed (in the header and footer of the printout) when aggregate results are displayed.“

The Titus Document Policy Manager for SharePoint meets this requirement. This solution can automatically mark classification headers/ footers on Microsoft Office documents and PDFs for displays, printouts etc. The example below shows the results of automatic header / footer marking (CONFIDENTIAL) on a document.

Titus also offers solutions for classification / downgrading and declassification of records as required by DoD 5015.2 section C3.3. (PRODUCT COMBINATIONS) which states “RMAs should interact with auto-classifiers, tools for downgrading and declassifying, and other tools that support the creation of classified records. When RMAs are integrated with or use services of these tools, the tools should automatically pass record metadata from the creating environment to the appropriate RMA record metadata fields as mapped by the organization.” The Titus solutions interoperate with Microsoft SharePoint to pass the appropriate metadata fields to SharePoint Records Manager metadata fields.

 

SharePoint 2010 Capacity / Performance Recommendations - Permission Planning

Hi my name is Antonio Maio, and I'm the SharePoint Product Manager at Titus.  There has been quite a lot of content written on Microsoft’s capacity recommendations for SharePoint 2010 and how various aspects can affect overall SharePoint performance.  Several recommendations Microsoft makes have to do with how content is structured, and with how permissions are managed.  These recommendations are important to understand, both in practice and within the wider context of other SharePoint recommendations and limits, because SharePoint performance for end users can be significantly impacted by  badly structured content libraries or over-use of metadata or unique permissions.

The TITUS SharePoint Security Suite has been designed to work well within the limitations and recommendations Microsoft has published on libraries and lists within SharePoint.  I’ll discuss some of these recommendations here, how they relate to TITUS Security Suite products, and what they mean in practice.  For the full list of capacity and performance recommendations on SharePoint 2010, please refer to Microsoft’s extensive documentation on the subject:  http://technet.microsoft.com/en-us/library/cc262971.aspx.

Recommendation on Unique Permissions

One important recommendation which Microsoft makes is that lists (and libraries) in SharePoint can have a maximum of 50,000 unique permissions.  This is actually a configurable value in SharePoint 2010, which can be adjusted by administrators in the Central Administration console.  It refers specifically to the number of items in a list or library that can have a unique set of permissions at one time (i.e. a unique security scope).

For example, if a library has a set of permissions at the library level so that some users have full control and others have read access over content within the library, this constitutes 1 security scope.  If a document within that library then has some unique permissions set, in other words it breaks inheritance from its parent library, then that constitutes a 2^nd security scope.  If another document within this library has a unique permission applied to it, where an Active Directory group of 1000 users is given read access, this constitutes a 3^rd security scope.  Finally, if you have 100 items within the library that have unique permissions, in other words 100 items all break inheritance from their parent library, then that constitutes 101 security scopes (remember you have 1 at the library level).

This seems to suggest that you can only have up to 49,999 items within a library when you want to have unique permissions for each item. Although this is technically true, there are other recommendations and limits within SharePoint that come into play.  Also, generally you will want to setup a library with inherited permissions for most documents, and then some exception documents will have unique permissions.  As well, there are strategies for dealing with much more content than this within a library when you need specific permission levels in place for sensitive content.

Related Limits and Thresholds

Here are some other important recommendations from Microsoft to keep in mind when managing the structure of your SharePoint content, along with the required permissions:

• Size of a Security Scope

One security scope can contain many users or groups, each with their own permission level.  So, for a specific document I can have unique permissions that state User1 has Full Control permissions, User2 has Read permissions, GroupA has Contribute permissions, and it all constitutes 1 security scope.  Microsoft recommends that for any security scope that you have no more than 5000 users or groups.  This is a recommendation and not a hard limit.  So, on any individual document, folder or library/list you should have up to 5000 groups or users set each with their own permission level.

• Active Directory (AD) Groups versus SharePoint groups

Microsoft recommends using AD groups when using groups to set permissions, as opposed to SharePoint groups.  AD groups are much faster and efficient for SharePoint to process. SharePoint groups, although supported, require SharePoint to go back to the database and crawl the entire index when assigning permissions.

• List View Threshold

A setting was introduced into SharePoint 2010 called the List View Threshold which controls the number of items that can be retrieved from the database on any query.  This value ultimately affects the number of items that can be viewed at the root level of a library or a folder – its default value is 5,000, it can go as high as 50,000, but it is dependent on farm size and architecture as well.  Microsoft recommends that you do not exceed this value when storing items in a list, library or folder, unless you plan to create custom views on these containers which do not exceed 5,000 items.  They continue by saying that exceeding this value will also cause general slowdown across your SharePoint repository.  Depending on how your content is organized, it may not be practical to store more than 5,000 items in a single library, list or folder because those items can become increasingly difficult to find and work with.  As well, retention policies should be considered when items accumulate in libraries for long periods of time, as they will eventually affect performance of your overall SharePoint farm.

Recommendations on Unique Permissions

Although the Unique Permissions Threshold discussed above is set by default at 50,000 there are various recommendations made in several Microsoft documents as well as other blogs and documents (some which contradict each other) about setting this value lower to 5,000 or even 1,000 in order to optimize performance.  As well, there is other documentation contradicting it by saying it is dependent on the List View Threshold (see the Microsoft support article:  http://support.microsoft.com/kb/2420771).  What we have found in practice with customers and through testing is that where you set this limit is very dependent on 2 things:

• The size and architecture of the SharePoint farm (servers, memory, CPU, # of web front ends, etc), and
• The structure and organization of your content

In practice, we’ve found that 5,000 items with unique permissions in a single library or list is very reasonable for most environments depending on their size and configuration.  We’ve worked with TITUS Metadata Security to automate permissions assignment in these cases and seen the SharePoint farm continue to operate quickly and efficiently.  As well, our testing with libraries containing 50,000 items with unique permissions has shown that that these environments can also continue to operate well.

When you think about this limit, in order to exceed it, you would need to have a library in which you had 5,000 documents each with a unique set of users or groups with their own permissions.  You could of course have other documents in this same library which inherit permissions from the parent, because those would not contribute to the Unique Permissions Threshold.  However, this would cause issues with your view of the library because the number of items would exceed the List View Threshold as discussed above (unless you get into creating custom views).  We’ve seen in practice, even in large enterprises, that SharePoint content tends to be spread across multiple libraries logically, typically by department, team or function. In all practicality, having over 5,000 items with unique permissions in one library probably suggests that a slightly different structure is required for organizing this content.

If by chance you do run into this, here are some simple recommended strategies to better organize content not only to reduce the number of security scopes, but also to make the content easier to find and easier to work with.

• Organizing your content logically within sites, libraries and lists by team, department or function where similar groups of people have the same access rights is an obvious one
• Using AD groups to apply permissions can help to greatly reduce the number of individual users with explicit permissions set
• Organizing content within folders and document sets can also be used to better organize content – for example, putting 100 documents with similar function and the same permissions into a folder, and having the permissions set on the folder will reduce the number of security scopes from 100 to 1 because those documents will inherit permissions from the folder.  The same applies for document sets.

Final Thoughts

With these considerations in mind, the recommendations and limits described by Microsoft are in fact quite high when put into practice, and they help you to better organize your content in SharePoint so that it’s easier for end users to find and work with.  TITUS can then help to ensure that this content is secure within SharePoint and that the right users are accessing the right content.  Overall, TITUS recommends that customers have a well structured SharePoint farm, sized appropriately, and that content be organized logically with various libraries, lists, folders and document sets.

Using TITUS Metadata Security for SharePoint, administrators can automate permissions assignment and management on both folder and items.  We recommend using Metadata Security to automatically apply item-level permissions to your sensitive content based on its metadata, and automatically apply permissions to folders for other content.  TITUS works with customers to ensure that SharePoint limits and recommendations are respected, and that permissions management becomes automated and consistent across the farm using TITUS products.

Technorati Z85A5TE4HQ4F

Managing SharePoint Drop Down Lists through Permissions

Last night we were talking about one customer scenario where we recently helped to secure and control the values they’re users have access to within a drop down list.  Their users need to upload project documents to SharePoint, and they’re required to choose a project name  for each document from a drop down list.   However some project names are considered sensitive and can only be viewed or selected by users with higher-level security clearance.  It was an interesting simple implementation that I thought I’d share.

 

The scenario was this (I’ve changed the example slightly to protect the innocent):

The customer has information workers that upload project documents to a SharePoint library, and they must select the project name associated with each document upon upload.  This project name is specified through a metadata field that all users are required to fill out from a predetermined list.  However, some project names are considered sensitive and are only accessible to users with higher-level security clearance.  So, the question is, how do we impose this kind of security within SharePoint on values within a drop down list, and how do we manage it effectively as the list grows.

The solution we found was the following:

• We created a new SharePoint List called ‘Projects’ with 2 columns: Clearance and Project
• The Clearance column represented the minimum security clearance required by a user to access a particular project name, and the Project column represented the project names themselves
• We added all possible project names to this list along with their associated security clearance – here is an example of what this could look like:

List of Project Names Associated with Security Clearance

• On the library in which users will upload documents, we added a custom metadata column called ‘Project’ and configured it to retrieve values from the List mentioned above – you can do this by going to Library Settings, clicking ‘Create column’, selecting that column to be of type ‘Lookup (information already on this site)’, selecting the List created above from the ‘Get information from’ drop down, and finally selecting the List’s project name column in the ‘In this column’ drop down.  Here is an example of what this would look like:

Settings for the Project Metadata Column

• We then configured TITUS Metadata Security on the list so that permissions were automatically applied to each individual list item for specific Active Directory groups, based on the Clearance metadata column – so our rules looked something like this:

1. If [Clearance] = ‘General’ then apply Read permission to AD Group : AllUsers

2.  If [Clearance] = ‘Secret’ then apply Read permissions to AD Group:  SecretUsers AND AD Group: TopSecretUsers

3.  If [Clearance] = ‘Top Secret’ then apply Read permissions to AD Group:  TopSecretUsers

The rules are cumulative, so that if you have top secret clearance you get access to all project names, if you have secret clearance you get access to generally available and secret cleared names, and if you simply have general clearance you only get access to those names.

The net result is that when a user uploads a document and they ‘re prompted for a project name, their group membership in Active Directory and the permissions applied by TITUS Metadata Security will determine automatically which project names are available to the user in the drop down list.

The Metadata Security rules are only applying Read permissions so these users can select them in a drop down list but they can’t edit the project names if they happen to navigate to the list. The SharePoint Administrator or someone cleared to view/edit all project names would have full control over them.

So, overall, this is a simple but powerful way of automatically controlling which drop down list items users are permitted to access.

Security for SharePoint 2010 Document Sets

Whew...April is a busy month.  Not a big month for vacations I guess.  I've been away from the blog for a few weeks.  One of the things we were working on is planning for the next release of our Metadata Security for SharePoint product.  We are having a good look at SharePoint 2010 to make sure we can port to that platform and over time take advantage of the additional features of 2010.

But you probably didn't come to hear me talk about how busy things are.  One thing that was interesting that we came across when we were doing our SharePoint 2010 planning was the new Document Sets feature.  Document Sets basically allow you to manage a number of documents as a single entity. You can apply workflow to the whole set, or you can apply specific information management policies to the set, things like Retention, Auditing, etc.  So this makes management of related documents easier as there is no need to manage the documents individually if they are similar. The concept is somewhat similar to folders, but you can't apply information management policies to folders by themselves. A Document Set is actually a SharePoint Content Type under the covers.  But there are a number of new tools for Document Sets that provide advantages over a standard content type, such as a customizable home page, workflows, ability to send all the documents in a Document Set together (SharePoint will zip them together in a package).

In terms of setting up Document Sets I'm not going to go over that here.  There seems to be a number of good blogs out there that cover this.  Liam Cleary does a nice job of explaining how to configure Document Sets in his blog - SharePoint 2010 User Experience - Document Sets.

In regards to security, you can apply security to a Document Set as a single entity, similar to what you could do with Document Libraries or Folders.  So if you have a bunch of documents that are grouped into a Document Set, (for example an RFP response, or all documents related to a merger etc) it may make sense to apply security directly to that document set, making the security slightly different from the parent library.  This is fairly easy to do.  You right click on the Document Set as shown below, and select Manage Permissions. In the example below, we have created a Document Set called Merger, which contains all the documents related to a recent merger with XYZ Company.  Since these merger documents are very sensitive we will want to apply special permissions to the Document Set.

(Click to see larger image)
 

Once we are in the permissions dialog we can break the inheritance with the parent library

Once the inheritance is broken, we can go ahead and configure the specific permissions we want for the document Set.

After setting the permissions, all the documents in the document set will inherit these permissions.  So we are done.
 

Typically all the documents in a Document Set will share the same metadata as they are all related.  As a result, we can also automatically set the specific permissions for the Document Set using the Titus Labs Metadata Security product.  Using this product, the administrator would define the metadata rules and desired permissions (for example, if metadata = merger, set permissions to x y and z).  So we achieve the same thing as setting the permissions manually except the process is done automatically so if you have a lot of documents or document sets to configure this will be done very quickly.

Visit to the NYC SharePoint User Group

Last week, Titus Labs had the opportunity to present our SharePoint Security Enhancement products to the largest SharePoint User Group in the US – the New York City SharePoint User Group (NYCSPUG).

 

With over 1600 active members, it was a great opportunity to not only showcase our SharePoint products, but to also understand the culture and interest of the numerous User Groups in the US and their points of interest for security needs within their relative SharePoint environments.

 

Held at the new Microsoft office in Manhattan, the meeting brought together 115 members, including SharePoint administrators, developers, Independent IT Consultants as well as business owners looking to understand the benefits of SharePoint in their environment.

 

We presented on the topic of native security features in SharePoint versus the enhanced security that Titus Labs brings forth. Our ability to leverage existing metadata within SharePoint in order to apply and automate permissions to libraries and lists was of key interest to attendees. Having to manage sensitive documents and content manually is cumbersome, so having the ability to automate that within SharePoint brought value to the day-to-day tasks of many of the SharePoint administrators and business owners who attended.  The general consensus and feedback from attendees was that regardless of the size of your company, whether it be 50 users or 50,000 users, Metadata Security becomes a ‘must have’ for the sensitive information within their SharePoint Libraries, and the amount of  documents within those libraries does not necessarily reflect the importance of them. 

 

Specifically here is some feedback I heard from customers on SharePoint security:

 

a)    There seemed to be previous hesitation from some companies to implement a ‘company-wide’ adoption for SharePoint, due to sensitive information. Metadata Security would alleviate that doubt and risk for end-users. Item Level Permissions really spoke to their needs as well from an administrative point of view.

 

b)    Document Marking was also of great interest. Feedback was geared around being able to have the end-user aware of the sensitivity, and being guided through Document Marking for their own documents that are put into SharePoint. Positive feedback from the group on the fact the documents were marked as they were actually being saved into SharePoint, not afterwards.

 

These types of ‘meet and greet’ sessions create value to not only the attendees, but to the vendors as well. Understanding what the needs of the customers are, and the struggles some have, lend the information necessary to continue to build and develop products that address the needs of these organizations.

 

We look forward to engaging with more SharePoint User Groups worldwide to continue these invaluable sessions!

 

- Jennifer Lalumiere

 

Performance Results - Automating SharePoint Item Permissions

One of the issues surrounding SharePoint security is the amount of time it would take to set item level permissions on a number of different items or documents.  The administrator has to go into "Manage Permissions" for every item that might be sensitive and adjust the permissions as required. For organizations that have a lot of sensitive information, this just isn't feasible.  That's why Titus Labs came up with the Metadata Security for SharePoint product, that automates the configuration of item level permissions.  

One question we often get from potential customers is "I have a lot of documents in my library, how long will it take for your product to set the item level permissions for all these documents".  The answer to this question can be broken up into two parts:

Firstly, the impact on performance is really only felt the first time the administrator automates the item-level security settings for the documents / items. The first time a metadata policy is configured to automate item level permissions, the Titus Labs Metadata Security for SharePoint product will iterate through all the documents, examine the metadata and set the item level permissions.  Depending on how many documents you have this could take a few minutes.  If you have a lot of documents you may want to think about doing this during the night when there are few SharePoint users on the system.

After this first pass through, permissions will only need to be set on new documents.  Even in a fairly large system you usually don't have a lot of new documents being added all at once. Documents are added randomly during the day.  This has virtually no performance impact, as setting the item level permissions for one document or a few documents at once is very minimal. 

Here is a summary of some performance benchmarks we did which test the automation of item level permissions using the Metadata Security product.  Again, keep in mind that this workload only needs to be executed the first time a policy is set on a library or list.  So this is strictly a one time process. Also, keep in mind that Microsoft recommends a maximum of 2,000 documents per document library.

Metadata Security for SharePoint R2 - Standalone WSS 3.0 on Windows 2003:

-   100 documents: 5 sec.

-   200 documents: 10 sec.

-   500 documents: 25 sec.

-   1,000 documents: 50 sec.

-   2,000 documents: 100 sec.

-   5,000 documents: 4 min.

 

Metadata Security Build R2 - Standalone MOSS 2007 on Windows 2008:

-   100 documents: 32 sec.

-   200 documents: 56 sec.

-   500 documents: 84 sec.

-   1,000 documents: 130 sec.

-   2,000 documents: 3 min.

-   5,000 documents: 4 min

 

Performance on the MOSS Server is slower because the information is stored in a separate SQL Server database.

Good luck.  Let us know if you have questions...Charlie

Preventing Users From Attaching Sensitive SharePoint Documents to Email

Like many organizations, you've probably moved a lot of your corporate documents to SharePoint. What used to be hidden away on personal drives or shared folders can now be shared with a wider audience, helping to improve communication and decision making within your organization. But this greater accessibility comes at a cost to security; anyone who can view a document in SharePoint can use the Save As option to copy the document to their local computer. Users can then easily attach the document to an email and send it out. Many times this isn't even a malicious action; the user simply doesn't realize that the document is sensitive, or isn't thinking of the consequences of emailing sensitive information over the internet.

 

So what can you do to stop this? Short of implementing an enterprise rights management (ERM) solution such as Microsoft Rights Management Services (RMS), you can solve the problem in the following ways:

 

1) Use a product likeTitus Labs Metadata Security for SharePoint to prevent unauthorized users from seeing the document in the first place. This is a good solution if you want to restrict documents to certain users, rather than allowing access to everyone in the organization.

2) Use a product likeTitus Labs Message Classification to scan the content of attached documents, and warn the user if they are attempting to send a SharePoint document that is sensitive.
 
The second solution is what I'd like to focus on for today's blog entry. The ability to scan attached documents is something we've recently added to our Message Classification for Outlook product.  The solution scans email and attached documents after the user clicks Send, and warns the user if they are about to expose sensitive information to unauthorized recipients. The feedback is immediate, like a spell check, helping to raise awareness and educate users on corporate email policy.  Here is a sample screen shot:

 

 

You can also view a 3 minute demo here.

 

Message Classification is a great solution if you have specific keywords or regular expressions/text patterns that identify a sensitive document. For example, you may have SharePoint documents containing special project names or codes, or you may have documents with headers and footers that indicate the document is confidential. Message Classification can identify these types of documents, and prevent the user from sending them in email. It's the best of both worlds; you can still collaborate on these documents in SharePoint, but you can also prevent email slips by users.

 

As a client-based solution, Message Classification avoids the problem of email being blocked at the gateway due to false positives. If an email is incorrectly identified as sensitive, users can be given the option to override the warning and send the email anyway. This puts accountability on the user, while providing the flexibility to ensure business processes are minimally impacted by false positives. All warnings and overrides are logged, which means organizations can easily identify areas of concern, such as employees generating high numbers of overrides, or keywords that are triggering the most warnings.

 

Next week, our Product Manager, Stephen Kingston, will go into more detail about how you can use regular expressions to find these sensitive documents in email.

 

-Lara

 

Security Considerations for SharePoint Search

This is a continuation of one of my previous blogs in January on Using Metadata for SharePoint Search. In that blog I discussed how to setup SharePoint search so that you can search using metadata, rather than, or in addition to, full text search.

A lot of customers using our Metadata Security for SharePoint product to set item level permissions in SharePoint ask us about the implications of item level security for SharePoint search. These customers understand the benefits of security trimming for document libraries and lists because they are using the Metadata Security product to automate the configuration of item level permissions based on metadata.  But they often ask if security trimming is also applied on SharePoint search results. They want to make sure restricted documents cannot be accessed, and do not show up in search results of users' who don't have the appropriate security permissions to view the document. Fortunately this is exactly how SharePoint 2007 operates.  SharePoint Server 2007 uses security trimming to ensure that users do not see content or links to content that they do not have permissions to view. You don't have to do anything special for this to happen.  Out of the box, SharePoint Search operates in this way.  Just keep in mind that out of the box, security info is picked up at indexing time. So if you change the permission on a file or folder, the result won't be changed immediately until the next time this content gets crawled (by full or incremental crawl). So there could be a window where the rights are not correctly displayed in the search results if the permissions have been recently changed.  

Keep in mind also that if you are using SharePoint Search to index other websites (non-SharePoint) that security trimming will typically not be applied. 

There are a few gotchas to SharePoint Search security trimming which you should watch out for.  Two of these are documented in Microsoft technical articles:

Items associated with "keyword best bets"

Sharing data across web parts

In general if you are searching SharePoint sites you can be comfortable that your data is well secured in the same manner as if users were accessing via the traditional document library or list views.