SharePoint MetaData and Classification

SharePoint Security Based on Content Type

In an earlier post we talked about securing SharePoint data based on metadata properties. Using metadata security allows us to break away from the standard SharePoint security model of defining security at a site, document library, folder, or per document level, and instead base security on the document’s metadata. All the actual SharePoint document permissions can then be set automatically based on metadata rules.

Metadata security works great, especially if all the documents in a library share the same metadata properties.  But sometimes we want some documents to have their own special metadata properties.  SharePoint content types allow us to do this.  Each SharePoint content type we define can have its own special metadata properties (columns).  For example, let’s say we have a Budget Document content type with a metadata property of “Business Function” with possible values of marketing, R&D, finance etc., and, and we have a Travel Expense content type with a metadata property of “Approving Manager”. We may have both types of documents in the same SharePoint document library.  If we have both of these content types in the same document library it would be difficult to base security decisions on an assumption that all documents have the same metadata properties.

That’s why we decided to support content types as a security object in our Metadata Security for SharePoint product. In the above example, let’s say only a specific group of financial analysts should be able to change budget documents which belong to the Finance function, and only the sales people should have access to the Travel Expense form. Let’s configure the Budget Document security options:

1.    Define a site column called Business Function.

2.    Define the Budget Document as a site content type. Add the Business Function site column to the content type’s columns.

3.    Configure an Information Management Policy in the particular library you are using -> select Information Management Policy from the Document Library settings, and select the Budget Document Content Type as the Content type for this policy.

4.    In the information management policy, define the Titus Labs Metadata Security rule  -> select Business Function as the Field Name and Finance as the Value.

5.    Define the Permission Set (Permission Set 1) that will assign the permissions to the correct analysts when the rule is true (ie Business Function equals Finance).

Once this is done all existing Budget Documents in the library, as well as any new Budget Documents that are added, that have Business Function equal to Finance will have these permissions automatically assigned. If we look at the permissions for the “Budget Draft” document (created using the Budget Document content type) we can see that it has the permissions assigned by the metadata rule.

As you can see this approach allows us to apply very specific security policy to content types within SharePoint.

Office 2010 Backstage and Metadata

Some of you may have seen the Microsoft blog posts on the Microsoft Office 2010 Backstage view - http://blogs.technet.com/office2010/archive/2009/08/11/microsoft-office-backstage-part-3-the-info-tab.aspx. Microsoft created the Backstage view in order to make Office's OUT features - those that you use to do things to the whole file (rather than the content within it) - a little more visual. Things like printing, document security, document inspector and document properties.  The Backstage view presents a visual view of the document along with the document’s properties.

A lot of the properties that were only accessible via the File – Properties menu selection, or via the Office button and Prepare – Properties in Office 2007, are now directly accessible via the Backstage view. It’s easy to click on the properties and add metadata values.

The only useful properties that don’t seem to display on the Backstage view are the Office Custom properties. These are typically created by third party applications, like our own Document Classification application, and are viewable via the Custom tab in the Properties dialog. It would be nice if these properties also appeared in the Backstage.

As we know, metadata properties are very important for document management and records management.  This metadata can be used for retention, search and security with document management systems like SharePoint.  We will have to wait to see how Microsoft has integrated the Backstage properties with SharePoint custom columns.  In Office 2007 documents, SharePoint properties could be viewed as “Server properties” in the Document Information Panel.  Hopefully Microsoft will make this even easier and allow viewing of the SharePoint properties within the Backstage view of the document.  A two-way synch capability between the Backstage view properties and SharePoint custom column values would also be very cool.  This would allow users to change the document properties in Office 2010 Backstage, and have these new values reflected in SharePoint columns when the document is re-saved or uploaded to SharePoint.

Labeling and Watermarking in SharePoint

Earlier in the week Lara discussed SharePoint’s native labeling functionality.  As Lara mentioned, the biggest disadvantage of the native labeling in SharePoint is that the user has to do something to get the labels in the document.  In this post, I’ll discuss how we’ve enhanced the standard labeling in SharePoint with our Document Marking for SharePoint product.

Before I get into the details, I want to give everyone a bit of background on this product.  Our Document Classification desktop product, which we’ve been selling for about 4 years, has the ability to add labels and watermarks to Office documents on the desktop.  Some of our customers told us they liked this functionality, but they would prefer to see this done on the server.  Being the most popular platform for sharing documents we decided to build labeling and watermarking functionality into SharePoint.  Our goal was to make this a completely transparent process to users.  The feedback we got was that, due to compliance and organizational policy, labelling needs to be mandatory in some environments.   Thus labeling and watermarking functions should be controlled via administrator policy.   The user should not be responsible for inserting labels.

The Document Marking for SharePoint product allows organizations to add labels and watermarks to Office documents via policy.  The label or watermark can be any fixed text, or metadata available in SharePoint.  So you could add labels that include standard SharePoint metadata like the author or date of creation,  or custom metadata fields such as Project name, classification etc.

The administrator defines the policy via SharePoint Information Management Policy.   We’ve added two policies, one for watermarking and one for header / footer labels.  The policy can be attached to a document library, or you can create a site collection policy. The example below shows a policy that will add a watermark to Microsoft Word documents.  The watermark will contain the value of the column “Classification”. 

  

The screenshot below shows an example of the Header / Footer policy.  In this case, we will be adding a header and footer to Microsoft Word documents.  The text inserted in the header and footer will include the fixed text “Titus Labs:” and the value of the custom column called Classification.

Once the policy has been defined for a document library all documents in the library will have the policy applied.  This can include existing documents in the library, a new document added to the library or a bulk upload of documents.  All this is done transparently to the user.  For new documents, the policy is applied when the document is saved or uploaded to the library. If the label needs to be changed for some reason, the administrator can change the policy and the document labels are automatically updated.  Once a policy is applied, the next time a document is opened the header footer and watermark will appear in the document.

If you are interested in seeing the product in action, have a look at the YouTube video we’ve created - http://www.youtube.com/watch?v=jDh9hiV-uHs

Document Labeling in SharePoint

Document labeling is an easy way to increase user awareness about the sensitivity of information in a document. For instance, a document may have a CONFIDENTIAL label at the top of the document, which makes it hard for the reader to claim they didn’t know the document was sensitive.

The difficult part is getting the label onto the document – and doing it in a way that’s consistent across the organization. If you leave it up to the users to type in labels themselves, they’ll either skip doing it (too hard!) or they’ll make up their own labels. And what if you have hundreds or thousands of legacy documents to label? You can’t expect your users to go back and label these documents one by one.

SharePoint goes some way toward solving these problems, although there are limitations. Let’s talk first about what SharePoint can do.

SharePoint has an Information Management Policy called “Labels”. Here’s what it looks like:

You can use this policy to add labels – such as Confidential - to the top of documents, as shown below:

There are several options available for administrators to customize the labels, including the ability to:

1)   Prompt users to add the label when they save or print, rather than relying on the user to click the Label button in the ribbon

2)   Specify labels containing static text and/or variables such as Project Name

3)   Control the appearance of the labels, such as font, size, and justification

The labels are added from within Microsoft Office Word, PowerPoint, and Excel 2007. One method is for the user to click the Label button on the Insert ribbon group, as shown below:

 

Another method is to add the label through a prompt that appears when a user saves or prints a document (if the administrator has configured this option):

The labeling capabilities in SharePoint are a good start for increasing user awareness and improving the handling of sensitive documents. However, a number of limitations exist with this feature:

1)   Watermarks are not supported. There is no way to automatically apply a watermark to the document with native SharePoint capabilities.

2)   There is no support for bulk labeling of documents. Users must open each document individually and apply the label.

3)   Related to point #2, if the labels need to change for some reason (e.g. the organization name changes, or updates are made to the labeling taxonomy), all previously labeled documents need to be opened one by one to apply the change.

4)   Even if you prompt users to apply a label, the user can choose to save or print the document without a label.

5)   Users can modify the labels in any way they like, including changing the text, size, and placement. This makes it difficult to enforce consistency across the organization.

6)   The feature does not work with Office 2003, nor does it work with Office 2007 Standard. Users must have Office 2007 Professional, Enterprise, or Ultimate.

An alternative approach is to add the labels automatically with no user interaction. This opens up new feature possibilities, such as watermarking, bulk labeling, and wider Office version support. This approach requires third-party software, which Charlie will cover in the next blog entry.

-Lara

Applying Information Management Policies for Specific Content

What can we do if we want to apply policy to SharePoint documents based on content?  More specifically we may want to apply policy based on a SharePoint content type, or documents tagged with certain metadata.   SharePoint Information Management Policy is the answer.  Information Management Policies allow us to apply specific policy to documents.  Information Management Policies are only available with MOSS 2007, they are not supported in WSS.  Information management policies can help organizations comply with legal or governmental regulations, or they can simply enforce internal business processes.  For example, an organization that must follow government regulations requiring that they demonstrate "adequate controls" of their financial statements might create one or more information management policies that audit specific actions in the authoring and approval process for all financial documents.

Using information management policies in conjunction with SharePoint content types allow specific policies to be applied to specific documents.  In a previous blog, Metadata or Content Types, we discussed what content types are and how they can be used.  SharePoint information management policies can be applied to a document library, a site, or a specific content type.  Applying policy to a content type allows the policy to be applied based on document content.  This policy can then apply across document libraries, sites or site collections.  

Let’s say we want to apply a specific retention policy to all legal guidelines which are published by the company. The first step would be to define the Legal Guidelines content type in SharePoint, and then create some specific Legal Guideline documents.  Once this is done we can apply specific policy to this content type.  If we only wanted to apply this policy within a certain document library, the administrator would go into Document Library settings, select "Information Management Policy Settings" and then select the content type to which to apply the policy.  The following screenshot shows how an administrator can define Information Management Policy for specific content types.  In this example, we could define a specific policy for the” Legal Guidelines” content type.

 

So what kind of policy can we apply via SharePoint Information Management Policies?

MOSS 2007 includes several predefined policy features.  It is also possible to add custom policies to the list of information management policies.  Examples of predefined policies include the auditing and the expiration policies:

  Auditing - The Auditing policy feature helps organizations analyze how their content management systems are used by logging events and operations that are performed on documents and list items. Organizations can configure the Auditing policy feature to log events such as when a document or item is edited, viewed, checked in, checked out, deleted, or has its permissions changed. All of the audit information is stored in a single audit log on the server, and site administrators can run reports on it.

Expiration - The Expiration policy feature helps organizations delete or remove out-of-date content from their sites in a consistent, trackable way. This policy feature helps organizations manage both the cost and risk associated with retaining out-of-date content. Organizations can configure an Expiration policy to specify that certain types of content expire on a particular date or within a calculated amount of time after some document activity (such as creating or editing).

The following screenshot shows some of the SharePoint predefined policies.  If we wanted to audit all actions associated with the Legal Guidelines content type, we would simply Enable Auditing.

Once the policy feature is selected we click OK and the polcy will be automatically applied to all documents of content type “Legal Guidelines”.

As you can see, using content types and SharePoint information management policy can help you manage your information and meet compliance requirements, including specific retention or auditing requirements.

Using PDF in SharePoint Document Libraries

On Tuesday’s blog, we talked about limiting a user’s access to read-only when opening an Office document from SharePoint.  As mentioned, Microsoft Office read only support is weak.  Anyone can do a “Save As” on the document and change the content.

Generally if people want to put something in a read-only format they convert to PDF.  You can’t change the document, and depending on the settings of the PDF, you may not even be able to copy the text out of the PDF.  PDF is also the accepted standard for archived documents.  Documents that are scanned for records retention are usually scanned into a PDF format as that is the accepted format for archiving. 

If you’ve got a SharePoint portal and want to share documents with customers or partners, or you want to share documents with other employees that should only have read-only, how do you get the document in PDF format in SharePoint?  For example, the legal department may be creating contracts for use by other employees in the organization.  The lawyers need access to the original Microsoft Word format in order to be able to modify the contract, but other employees should only get the contract in PDF format.  One alternative is to have the lawyers PDF the document on their desktop every time there is a change to the document. They could then save the PDF to the SharePoint library. The problem here is that every employee would have to have PDF conversion tools on their desktop, and this could be a very time consuming process to have to maintain the PDF.

A product we have developed, called Titus Labs PDF Control for SharePoint solves this problem by automatically creating PDF versions of Microsoft documents as the documents are added to SharePoint. The PDF conversion takes place transparently in the background, and requires no additional software on the user’s desktop. If the source document change in the future, the PDF is updated automatically; this ensures that the PDF version is always up to date.

The software is administered via SharePoint Information management policies.  The PDF policy can be turned on for particular libraries.  Administrators can control the permissions on both the source document and PDF in SharePoint, so that some users can access the original documents, while others can see only the PDF.

 

 Once the policy is enabled,   PDF will be automatically created for all Office documents saved or uploaded into the library.  In the screenshot below, a PDF has been automatically created in the Administrative Documents library for all the saved Office documents.

Depending on the permissions of the users, they will either see all of the documents, or they may only see the PDF versions of the document.  The screenshot below shows a user who only has permissions to the PDF versions in the same Administrative Documents library.

Limiting Access to Read Only in SharePoint Document Libraries

Limiting Access to Read Only in SharePoint Document Libraries

We often hear from customers that they want to allow customers or partners access to documents via a SharePoint portal.  They want to be able to share final documents with this audience, and typically they don’t want people to be able to change the documents.  Read only versions of Microsoft Office documents are a possibility here, but there are some definite disadvantages.  First let’s have a look at how Read Only access would be setup in SharePoint

First we modify the permissions of the library, or the document itself to give Read-Only access.  In this case, a specific user – Charlie – has been granted read only access to the document called Acquisition Plan.

 

When the user Charlie signs on to the library and selects the menu of options for the Acquisition Plan document  in order to see what permissions they have, they will see a very limited set of permissions.  Note the user does not see the “Edit in Microsoft Office Word” option.

The user can still click on the document and open the document in Read Only mode. Note the (Read Only) beside the document name in Microsoft Word.

Though the user cannot modify this copy of the document, the user can do a “Save As” on this document and save the document with a different name.  The user can then modify the document as they wish.

All the Microsoft Office applications work in the same way.  As a result, most customers are not satisfied with the “Read Only” mode of Microsoft Office applications. Customers would prefer to distribute a document in a Read Only mode that cannot be modified. 

Later this week in our next post we’ll examine some alternatives to the Microsoft Office Read Only mode.