Hiding and Restricting Information: Audiences and SharePoint Security

Next week, I will be delivering a fantastic (if I do say so myself) one day MasterClass for SharePoint 2010 in London and Munich. If you’re in the area, there’s still time to register!!

Earlier this month, at another event--TechEd North America in New Orleans--I presented a session about SharePoint Security. The session focused on the security of content itself—from the Web application to the site collection to the sites, lists, libraries, folders, items, and documents that comprise SharePoint content. During the session, a question arose several times, from several perspectives—a question that I also recently heard from a client: What about “audiences”? There is confusion about audiences and their relationship to security. In this week’s column, I’d like to offer some clarification and guidance about audiences.

An audience is a dynamically-defined group, typically created by defining user profile attributes that qualify a user as a member of an audience. You can define audiences in SharePoint 2010 by opening the management page for your user profile service application.

Audience membership—the determination of which users actually belong to the audience—is managed by a timer job. That is the first characteristic that is important to consider related to security. When you add or remove a user from a group, the change takes effect the next time a user is authenticated. Audience membership is managed per audience, so a change may not take effect immediately.

The most important difference between audiences and groups is that audiences are never used to secure a resource. Access control—also called role assignments or “permissions”—is always configured based on SharePoint groups or by groups defined in the role provider (such as Active Directory), never by audiences. You cannot restrict access to a list or a document in a library based on audience. Instead, audiences are used to publish content to. In other words, you use audiences to make content more easily visible… to “bubble up” content… to “personalize” a site.

Let’s assume that you have an intranet portal, and on the home page you want to expose information to appropriate users. Your executives may be concerned about the current stock price, your marketing team may be concerned about upcoming product launch information, and your finance team may need to know about upcoming budget meetings. Audiences can be used to target information to each of those “groups.” However, what you are not doing is preventing normal users from seeing the stock price, or preventing the sales team from seeing information about product launch. If a user knows the exact URL to the finance group’s calendar, they could see the upcoming budget meetings unless you’ve restricted access using groups and permissions. But on the intranet portal, you’ve “hidden” or “exposed” information to certain users.

I’ve had discussions with customers who start by saying they want to “prevent” users from “seeing” information. The word “prevent” suggests security and access control—groups and permissions. But on more detailed discussion, I learned that they simply want to “hide” the information from users who have no reason to see it. They didn’t care that users could get to certain information, they just wanted to make a site more useful to the users by hiding less-useful information. In those situations, audiences are perfectly acceptable. And, to be sure, the dynamic nature of audiences is fantastic—you change a user’s “Department” attribute in Active Directory and their audience changes. Fantastic.

As long as you keep in mind the distinction between “hiding” or “showing” information (audiences) and truly “securing” information (“allowing” or “preventing” access, which is done with permissions and groups), you can make the appropriate business decision for each scenario.