SharePoint MetaData and Classification

Securing Mobile Access to SharePoint 2010

Microsoft SharePoint 2010 has some great capabilities built in for accessing SharePoint from a mobile device. Some mobile browsers are fully supported out of the box, and others are partially supported today, with more support to come in the future. Lately I’ve been researching how we secure access to SharePoint from a mobile device or tablet for a particular customer, and there are several useful blog posts already out there that have been an enormous help. Securing access from a mobile device is becoming a critical part of security planning for SharePoint, as the phenomenon of Bring Your Own Device to work just continues to grow. In this short post, I’d like to highlight those articles and point readers to them as an important resource as they think about how to allow secure access to SharePoint from a mobile device.

With the phenomenon of Bring Your Own Device to work, IT departments no longer have complete control of which devices are being used to access corporate resources. People want to use their own mobile device or tablet in order to get their work done. And, enterprises want to allow this because of the cost savings involved, despite the risks.

In fact, a recent Forrester survey found that 81% of enterprises will support or are interested in supporting the iPad this year. This means that mobile access must be considered when determining how to control access to your sensitive content in SharePoint.

In planning mobile access to your SharePoint 2010 deployment, you should first consult the following article on the Microsoft Office 2010 Engineering Team Blog:

Configure SharePoint Server 2010 for Mobile Device Access

It will introduce the supported mobility scenarios for Office 2010. These mobility scenarios rely on support from SharePoint 2010 mobility, and this post describes how to setup your SharePoint environment so you can take advantage of mobile access.

Securing Access to Various Mobile Browsers

In Microsoft SharePoint 2010 today, you can enable or deny access to SharePoint based on a user’s mobile browser. This allows you to control which types of mobile devices can and cannot access SharePoint. This is configured through a simple customization of Out-Of-Box SharePoint. For the technical folks in the crowd, this is done by adding the appropriate section and user-agent string to the compat.browser file under the Virtual Directories folder for your specific web application.

There is a great blog post on the Microsoft SharePoint Team Blog found here (SharePoint 2010 and Apple iPad) that will guide you step by step on how to configure this.

Redirecting Users to the Full Web Interface on Mobile Browsers

As well, there are circumstances when the SharePoint 2010 mobile web interface is just not sufficient for your needs, either from a content collaboration point of view or from a security point of view. Through some simple code, you can modify the SharePoint redirect for mobile access to present the full web interface as opposed to the more limited mobile interface.

There is a great blog post by Waldek Mastykarz found here (Inconvenient SharePoint 2010 Mobile Redirect) that will walk you through the code and the modifications necessary to make this happen.

Special thanks to the authors of these articles, who spend their time helping the communicate understand how to better share and collaborate securely in Microsoft SharePoint.

-Antonio

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

Using AD Groups in a Claims Based Web Application

I ran across an interesting little side effect of altering my claims enabled web application in SharePoint 2010 the other day I thought would be useful for others to know about. The situation has to do with accessing AD Groups from within the SharePoint people picker in a claims enabled environment.

Initially one of my SharePoint web applications was configured to allow authentication either through NTLM or through a Trusted Claims Provider (which was ADFS 2.0 sitting in front of AD of course). I could select which method I wanted to use when I navigated to the site through the default sign in page which presented a drop down list of the 2 authentication providers. At any time I could authenticate through NTLM or through the claims provider. This was all standard stuff so far.

I decided that I should clean up this web application since I was only using claims based authentication, and I removed the option for NTLM authentication. This just made the environment a little cleaner from a usage and demo perspective.

Then I logged into my web application through the ADFS 2.0 provider and proceeded on with additional work. I was configuring an existing library with a new metadata column – it was a People and Group column. My intention was to use this column in a demonstration where I was selecting groups were associated with specific items in the library. I wanted to be able to specify a different group for different documents in the library. In particular I wanted to use Active Directory groups and I already had a number of groups setup. So, I add my column and tried to select the AD groups I already had been using for some time. It turned out that my SharePoint people picker could no longer resolve the groups that I was searching for.

I checked over my AD installation. I checked that my groups were configured correctly. But nothing seemed out of the ordinary, nor would any changes here to improve the situation. Then I noticed that my people picker was missing the Active Directory node – it looked like this:

I was no longer able to search against any Active Directory groups!

So, with my upcoming demonstration looming, to try to resolve this I returned to Central Admin and the Manage Web Application page. I reconfigured the authentication providers for this web application so that once again I could sign in through either NTLM or my trusted ADFS 2.0 provider. I logged in once again using the ADFS 2.0 provider, went to add a group to my metadata column an I could find my AD groups again. My people picker now looked as follows:

Notice the Active Directory node on the left side. I could now find and select my ‘JointChiefs’ group and add it to my column (note I need to choose the one on the right side that is under the Active Directory heading.

So, it turns out that even if I’m always signing into SharePoint through my ADFS 2.0 claims provider, I need NTLM or Kerberos configured as an authentication provider for my web application in order to access Active Directory entities like groups in the SharePoint people picker. Please keep in mind that this is without any customization of the people picker using a custom claim provider.

Hope this helps someone that might run into the same situation.
– Antonio

How do you Check Multiple Groups to Enforce Security in SharePoint 2010?

Implementing claims based authorization in SharePoint 2010 provides great alternatives to using security groups in order to control access to sensitive content in SharePoint.  Traditionally, security groups have been used to restrict access to content or to enforce a role based security mechanism.  However, organizations are quickly finding that security groups, whether they are SharePoint groups or Active Directory groups, do not scale well in large enterprise environments.  Many enterprises already have large numbers of groups deployed, so how can those organizations still make use of those groups to enforce advanced security policies without complicating group management further?  As well, how can they check membership to multiple groups in order to allow access to sensitive content? This article focuses on using claim rules in Active Directory Federation Services version 2 (ADFSv2) as an efficient mechanism to enforce security policies in SharePoint based on group membership.

The Challenge with Security Groups

We’ve worked with several customers that need to enforce security policies in SharePoint which are based on a user’s membership to one or more groups.  Often, large enterprises have large numbers of existing groups, typically numbering in the thousands which have been created over a period of years, and creating new groups in order to manage security is not an option because the existing set is already difficult to manage.  They’re usually looking for a better solution.  We have seen lately that some organizations with very sensitive content have policies that involve allowing a user access to a particular item, list, library or site in SharePoint if that user belongs to more than 1 group – for example, I mean a scenario where a user is permitted to access DocumentX if they belong to both GroupA and GroupB.

SharePoint does not easily support such a requirement.  By default, SharePoint supports an OR relationship between all users/groups that have been given access to an item.  So, if today I give GroupA and GroupB access to a SharePoint item, a user needs to belong to only one of the groups in order to gain access.  Currently, to enforce such a policy in SharePoint requires you to manually create a third group, GroupC, which contains only the users that belong to both GroupA and GroupB.  These groups are sometimes called “Intersecting Groups” because they represent the intersection of GroupA and GroupB.  We can easily see how this does not scale:

• In a large environment, with many existing groups and many sites/lists/libraries/items with varying security requirements, you may need to manually create a very large number of groups (and manually determine what the intersection is)
• If the security policy requires that a user belongs to 3, 4 or more groups the problem only becomes more difficult to manage with manually
• The number of groups keeps increasing and the problem of managing a large number of groups only gets worse
• What happens when the membership of GroupA or GroupB change, perhaps because a user changes roles or teams, you will need to manually modify the membership of GroupC

ADFSv2 along its support for Claim Rules gives us a much more scalable solution to enforce such security policies in SharePoint.  For more background on Claim Rules in ADFSv2 and the Claim Rule Language, please see the following previous articles:

• Claims Based Security in SharePoint 2010 with ADFSv2 – Part 1: Claim Rules

• Claims Based Security in SharePoint with ADFSv2 – Part 2: Claim Rule Language

Checking Membership to a Single Group

In ADFSv2 we can easily create a claim rule using a ‘Group Membership’ rule template – this rule would check a user’s membership to a specified AD group and use that as a condition when issuing a claim. Such a rule would be executed for each user at the time of authentication (ie. at login time) which means that a policy based on this rule will always be up to date and using the latest group membership from Active Directory.

You can create this rule by following these steps in ADFSv2:

• Click Trust Relationships > Relying Party Trusts on the left side of the ADFSv2 Console
• Right click the appropriate Relying Party Trust and select the Edit Claim Rules… menu item
• Click the Add Rule… button
• A wizard appears – in the dropdown list select “Send Group Membership as a Claim”; click Next
• Give the rule a meaningful name
• Click Browse to select the appropriate AD group you wish to check for membership
• Type in the name of the group and click Check Names – you may be required to login to the AD domain; I selected a group I had pre-created called “Finance”
• Select the Outgoing Claim Type (the claim that will be issued) and specify the Outgoing Claim Value; the Outgoing Claim Type must be a claim type that has already been created in the list of Claim Descriptions, and the Outgoing Claim Value can be any string – I selected an outgoing claim called “policydecision” and specified the value “true”

NOTE: using the ‘Group Membership’ rule template only allows you to check for membership to 1 group at a time.  The wizard interface will look like it allows you to specify more than one group, but it will ultimately restrict each claim rule to only checking 1 group.

Let’s look at the Claim Rule Language for this example:

c:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1109”, Issuer == “AD AUTHORITY”]

=> issue(Type = “http://schemas.sp.local/policydecision”, Value = “true”, Issuer =c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

So, this rule ultimately says if the user logging in belongs to the AD group Finance, then issue the claim policydecision=true.  You’ll notice that even though I selected “Finance” as the AD group to check against, the rule converted that to the group SID “S-1-5-21-563680538-1201701862-760492540-1109”.  group SIDs are immutable, meaning once they are created they do not change, so this is fine.  The only issue this might cause is readability of the rule language, but we can work around that.

Checking Membership to Multiple Groups

But what if you want to check 2 or 3 AD groups for membership and only if a user belongs to all of them  issue the claim policydecision=true?  This can easily be done by creating a custom claim rule that replicates the condition in the claim rule above and separates the conditions with &&.  Since the rule converts the group name to group SIDs you’ll need to get the SIDs for all the groups you wish to check.

You can do this using 1 of 2 methods:

• Access ADSIEdit for your Active Directory, navigate to the appropriate groups, find the objectSID attribute for each group and note down their values
• Or, if you don’t have ADSIEdit access to AD, create a claim rule using the “Send Group Membership as a Claim” rule template for each group in question and then copy and paste the text from the resulting claim rule language (remember for each rule created you can click the View Rule Language… button) – you can delete these rules later

Once you have the group SID for each group, create a Custom Claim Rule and enter the following:

c:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1109”, Issuer == “AD AUTHORITY”]

&& c1:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1110”, Issuer == “AD AUTHORITY”]

&& c2:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1111”, Issuer == “AD AUTHORITY”]

=> issue(Type = “http://schemas.sp.local/policydecision”, Value = “true”, Issuer =c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

This claim rule will now check membership to 3 different AD groups, and only if the user belongs to all 3 groups will the claim “policydecision” with the value of “true” be returned as an outgoing claim.  Be sure to replace the group SID values with the respective values for the groups you have in mind – it happened that the 3 groups I created and used all had sequential group SID values, but yours many not.

Within SharePoint 2010, if a claim of type “http://schemas.sp.local/policydecision” with a value of “true” is assigned to an item with the permission level of Full Control, then the user will only gain Full Control access to this item if they belong to all 3 groups.

Benefits of Group Membership Rules in ADFSv2

This is in fact a very efficient way of enforcing such a security policy within SharePoint 2010:

• Every time the user logs into SharePoint, group membership is validated, so policies are always using the latest information to determine what outgoing claims are returned
• No manual groups to create or maintain, especially as memberships to existing groups changes
• Only 1 claim is added to the outgoing claim set for each rule – when a user logins, ADFSv2 by default retrieves the SIDs for the groups a user belongs to as part of the incoming claim set

Note:  This solution will be limited to Active Directory groups because ADFSv2 doesn’t have access to SharePoint groups.

Using TITUS Metadata Security Claims Edition with Group Membership

TITUS Metadata Security Claims Edition can automatically apply group membership policies like these to documents, items and folders in SharePoint 2010 using claims.  TITUS Metadata Security has a great feature where the values of metadata columns can be used to dynamically set claims on items or folders as permissions with specific permission levels.

For example, let’s consider a situation where we have financial data in a SharePoint library that is particularly sensitive and where Contribute access is only given to members of the Audit Team, who are Senior Managers, and who are part of the Finance Department.  We can enforce such a policy automatically by creating 3 metadata columns for the library with the columns named Team, Role and Department. These columns can represent the 3 groups that users must belong to in order to access particularly sensitive content.  Then, in TITUS Metadata Security a policy can be created which reads as follows:

Claim Type:                         http://schemas.sp.local/policydecision

Value:                                   {Team}{Role}{Department}

Permission Level:             Full Control

So, an item that requires a user to be part of the Audit Team, to be a Senior Manager and to be part of the Finance Department in order to access it, can set the 3 columns as such in SharePoint.  TITUS Metadata Security will then automatically generate the appropriate claim by taking the column data specified by the policy and concatenating those values together to form the claim value.  TITUS Metadata Security will then apply the claim type with the generated value as permission to the item.  It will apply this claim to existing content in SharePoint, as well as when new content is added or when content changes (even when metadata changes).

A corresponding claim rule must also be created in ADFSv2 that is similar to the one listed above, but with a slight change, as follows:

c:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1109”, Issuer == “AD AUTHORITY”]

&& c1:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1110”, Issuer == “AD AUTHORITY”]

&& c2:[Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “S-1-5-21-563680538-1201701862-760492540-1111”, Issuer == “AD AUTHORITY”]

=> issue(Type = “http://schemas.sp.local/policydecision”, Value = “AuditSeniorManagerFinance”, Issuer =c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

Since the group SIDs must be provided in the claim rule and they can only apply to specific named groups, we can simply include the group names as the value right in the issuance statement of the claim rule as shown.  TITUS Metadata Security can also allow you to specify metadata conditions so that such claims are only generated and applied under specific metadata-based conditions.

TITUS Metadata Security for Microsoft SharePoint allows you to secure your sensitive data within SharePoint.  Security policies can be based on users, security groups, trusted claims or some combination of the three.  Policies can be applied based on existing security groups dynamically and automatically in very secure environments, without increasing the management overhead of additional security groups.

-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.

Configuring the Realm – Using SharePoint 2010 with ADFSv2 to Retrieve Claims

When configuring SharePoint 2010 for claims based authentication or authorization you typically need to connect to an identity provider to retrieve user attributes as claims. To really see all the benefits of claims in the enterprise, we need to ensure that our SharePoint Server trusts the claims its receiving, and that often means configuring it to connect to a “trusted identity provider”. One such server application that can act as a trusted identity provider is Microsoft Active Directory Federation Services version 2.0 (ADFSv2). ADFSv2 is often also referred to as a ’secure token server’ because it plays the role of retrieving user attributes from Active Directory (or some other LDAP directory or data store), wrapping them up in a SAML token, digitally signing that token and returning it to the calling application – in this case SharePoint 2010. Configuring ADFSv2 in such scenarios can be tricky and unforgiving, and this article focuses on 1 particular part of that configuration – the Realm.

If you attended my session at the Microsoft SharePoint Conference a couple of weeks ago, called “Using Claims for Authorization in SharePoint 2010″, you would have seen my demonstration of SharePoint 2010 connecting to ADFSv2 to retrieve claims in a trusted manner, and then TITUS Metadata Security automatically applying authorization policies to documents in SharePoint based on a user’s claims and document metadata. During the demonstration, one person questioned the value I had configured for the “realm” variable. They very astutely noticed that it was configured to the following:

urn:sp-server-2010.sp.local:sharepoint2010

The portion of the realm which reads “sp-server-2010.sp.local” actually matches the domain of the SharePoint server I was using during my demo, and I think this implied the realm variable was doing more than it actually is, so I think this topic is worth a little clarification.

I’ll back up for a second to describe at a high level how I configured ADFSv2 and SharePoint, and then focus specifically on exactly how the realm variable is used.

High-Level Configuration of SharePoint 2010 and ADFSv2

When configuring SharePoint 2010 to authenticate through ADFSv2 and retrieve claims, the following is the process at a high level that you’ll typically follow in a very simple base case:

1. Download ADFSv2 from the Microsoft ADFS web site (its free) and after starting the setup program select to install it as a Federation Server.
2. On the ADFSv2 server, go into the IIS Management Console and create a self-signed certificate.
3. Within the ADFS 2.0 Management application, create a New Federation Service – there is a great wizard provided for this. Take note of the “Federation Service Name” (in my case it is https://sp-server-2010.sp.local) as its used a little later on.
4. Expand the Service node, and under the Claims Descriptions node add a new claims description for any custom claims you wish to return – there are 21 claims already there by default like Email. Here we are selecting claims to be sent back to SharePoint, but we are not yet mapping them to AD attributes. For any custom Claims Descriptions you’ve added, take note of claims type URL.
5. Expand the Trust Relationships node, and under the Relying Party Trusts node add a new relying party trust – there is a great wizard for this as well.  There are several options to choose here, but some of the critical ones are the following:
   - Select “WS-Federation Passive” as the protocol
   - For the Relying Party URL use the ‘Federation Service Name’ from above plus ‘/_trust/’ (so in my case its https://sp-server-2010.sp.local/_trust/)
   - For the Relying Party Trust Identifier here is where we need to specify a realm and where the confusion came in.  More on this point a little lower in this article.
6. Create Claims Rules for the Relying Party Trust you just configured. Here is where we map AD attributes to Claim Descriptions. For complex scenarios, consider using the Claims Rule Language built into ADFSv2.
7. View and Export ADFSv2 Token Signing Certificate – c:\adfs20Certificate.cer. You will need to copy this to the SharePoint 2010 server. We need to use this certificate when configuring SharePoint 2010.
8. In SharePoint you are now going to create a new web application. You’ll select that it uses Claims Based Authentication over NTLM to start, ensuring that it uses port 443 and SSL. Ensure the public URL of the web app matches the one in the ADFSv2 certificate – this is where we start to establish trust between this web app and the ADFSv2 server. Do not create a site collection yet.
9. You will then run a PowerShell script on the SharePoint server in order to map the claims being retrieved, set the realm and set the certificate that SharePoint should use to validate the claims received (the c:\adfs20Certificate.cer file described above). The PowerShell script is included below.
10. Finally, in SharePoint 2010 you will now log into Central Admin, access the Authentication Providers page for the web application you just created, click Default and check on “Trusted Identity Providers” and the ADFSv2 Provider you just configured. You can optionally uncheck the NTLM provider you configured earlier. You can now create a new site collection, site and libraries.

Now, there are a lot of details in each step and as mentioned the process can be unforgiving if mistakes are made. For a detailed end to end description of the entire process I encourage you to visit Steve Peschka’s Share-n-dipity blog.

The Realm

Now, getting back to the discussion on the realm – when creating a Relying Party Trust within ADFSv2, you are establishing a trust relationship between ADFSv2 and a calling application. In our case the calling application is SharePoint. When creating this trust, you need to specify a Relying Party Trust Identifier which is a realm. The realm can in fact be anything you want, as long as it follows the specific format:

urn:something:something_else

In my case, because the calling application was my SharePoint 2010 server I chose to use the URL associated with that server so it ended up looking like this:

urn:sp-server-2010.sp.local:sharepoint2010

…but I could have used anything I wanted after the “urn:” and after the second “:”. I would recommend avoiding spaces here though.

The realm is associated with the claims aware web application that’s making a request to ADFSv2 (again, in our case the SharePoint web application). When ADFSv2 receives a login request from SharePoint, it is uses the realm to map the request to one of the relying party trusts that has been configured. With that relying party trust, once the user has been authenticated, ADFSv2 then knows which attributes to retrieve, how to map or manipulate them and what protocol to use in returning them to SharePoint.

So, in our case, when I navigate to SharePoint at https:\\sp-server-2010.sp.local I’ll be redirected to ADFSv2 and it will receive the realm “urn:sp-server-2010.sp.local:sharepoint2010″ with the login request. Once I’ve been authenticated and ADFSv2 has retrieved, mapped, wrapped and signed my claims, ADFSv2 will redirect me to https:\\sp-server-2010.sp.local\_trust\ because that’s the WS Federation passive protocol URL that I configured with the relying party trust. Its important to note that the realm is simply used to map the calling app that’s making the login request to a configured relying party trust so that ADFSv2 knows how to deal with the request. The realm is not used at all to to redirect the user to any URL.

This realm value is also used in the step mentioned above which requires running a PowerShell script on the SharePoint server. That step configures the SharePoint web application with the realm to use in making its login request to ADFSv2 – so its important to use the same value configured in your relying party trust. Here is a sample of that PowerShell:


# Make sure the claim types are properly defined in the ADFS server
$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.sp.local/EmployeeStatus" -IncomingClaimTypeDisplayName "EmployeeStatus" -SameAsIncoming
 
# The realm will identify the web app in ADFS. It is generally created in the form "urn:something:something_else"
$realm = "urn:sp-server-2010.sp.local:sharepoint2010"
 
# Use the certificate that has been exported from the ADFS server
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\adfs20Certificate.cer")
 
# The url below will tell SharePoint where to redirect to in order to authenticate with the STS
# so this should have the ADFS url, plus the protocol (Windows integrated security - "/adfs/ls")
$signinurl = "https://adfs20.sp.local/adfs/ls"
 
# Adds the STS (AD FS 2.0) to SharePoint
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20 Provider" -Description "SharePoint secured by ADFS20" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3 -SignInUrl $signinurl -IdentifierClaim $map.InputClaimType
 
# The certificate imported from the ADFS should be added to the trusted store
New-SPTrustedRootAuthority -Name "ADFS Token Signing Root Authority" -Certificate $cert


Again, the script must be run on the SharePoint 2010 server. There is a lot going on in it including:

- mapping claim types
- configuring the realm which SharePoint will use in the login request
- specifying the certificate to use in validating the token received from ADFSv2
- adding the trusted identity provider to SharePoint – named “ADFS20″ Provider here
- adding the certificate from ADFSv2 to the trusted certificate store

I’ll mention one more time that its very important to ensure that you’ve included the correct realm and all the correct URLs in your PowerShell script. If you run it with typos it can often mean starting the whole process over again. Hopefully this helps to clarify any questions about how the realm is used in configuring SharePoint with ADFSv2.

More importantly, hopefully this post helps to clarify how trust is established between SharePoint 2010 and a trusted identity provider like Microsoft Active Directory Federation Services 2.0, because only when user attributes in SharePoint are trusted is the enterprise really going to fully benefit from Claims through Claims Based Authentication and Authorization.

-Antonio

Using Claims in SharePoint 2010 – What are claims?

Reflecting on the Microsoft SharePoint 2011 Conference (SPC2011) of last week there were several hot topics presented – one was the concept of claims and using claims in SharePoint 2010 for  interesting security-related scenarios like authentication.  This topic is particularly important in the identity management space right now.

I’d like to thank everyone that came to my session on the Wednesday afternoon titled Using Claims for Authorization in SharePoint 2010.  It appears that the deck I presented may still not be available on the Microsoft MySPC site.  I have asked Microsoft to look into this and post the updated deck I provided them, but in the mean time I’ll make the deck available here for download.

 

Using Claims for Authorization in SharePoint 2010
(presented by Antonio Maio, TITUS on Wed, Oct 5, 2011 at Microsoft SPC 2011)

I’m going to post several articles over the next few days and weeks on this topic .  I’d like to start this series off by talking about the basics and give readers a foundation for the concept of claims, and how they can be used in various business and data governance scenarios.

What are Claims?

People often talk about the concept of claims in a very simple manner, saying that claims represent user attributes or attributes about a user.  Sometimes claims are referred to as metadata about a user – I’ve been guilty of this one myself.  To over-simplify the topic, we sometimes hear them spoken about as Active Directory attributes or LDAP attributes.

Really, to understand the concept, you have to view claims as an assertion that I make about myself.  In other words, a claim is an attribute that I claim to have or be.  For example, I can tell you that I am Canadian.  I can tell you I’m a Canadian of Italian heritage.  You may or may not believe me.  This is something that I’m claiming about my identity.  If you were to look at my passport, perhaps you’d be more inclined to believe this claim, because my passport is an official document that many agencies trust.  If you were to ask someone that you trust about me, and that person happens to know me well, then you would likely be inclined to trust what they say about me.

In the digital world, an application trusts a claim about a user’s identity if it is issued to the calling application by a trusted identity provider.  That’s why, when creating or deploying a claims aware application its important to establish a trust relationship between that claims-aware application (the relying party) and the claims issuer (sometimes called a claims identity provider).

Claims offer us much more than just retrieving attributes from a directory.  As an example to consider, typically an external partner to an organization is not permitted to connect their system to the organization’s internal directory to retrieve attributes.  Even if they are permitted to connect, the partner has no way of trusting those attributes because they have no way of validating them.  As well, for the organization, there really is no effective way of limiting what attributes each calling application is permitted to access. 

The real power of claims becomes evident when you consider the following points:

• claims are issued to applications by trusted identity providers
• these trusted identity providers can be on-premise, in the cloud, inside or outside the enterprise
• trusted identity providers can be configured to only return certain claims to specific trusted calling applications
• claims are packaged up into tokens using standards based formats (like WS-Federation or SAML)
• claims tokens are digitally signed and communicated back to the calling application using standards based protocols (like SAML)

Claims allow us to take identities across network boundaries in a secure and trusted way, enabling us to solve some new and exciting challenges for our customers.  These challenges include federation, complex authentication requirements, as well as authorization based on not only who I am but what my clearance level is, if I’m connecting over a secure connection or an internet cafe, the time of day, if I need 2 factor authentication for specific systems or sites, and so on.

More to come on configuring and using claims in SharePoint 2010, and some of the limitations you may see.

-Antonio

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.

New File Share to SharePoint Migration Utility from Microsoft

Microsoft is releasing a new Powershell script to allow customers to upload files directly from a file share to a SharePoint document library.  In addition, the script will allow files that have metadata to carry that metadata into SharePoint.  The script was developed by the group responsible for the Windows Server 2008 R2 File Classification Infrastructure and supports both SharePoint 2007 and SharePoint 2010.  If you are not familiar with the File Classification infrastructure, it allows organizations to assign classification metadata to files on a Windows Server 2008 R2 file server.  For more on File Classification infrastructure see one of my earlier posts on this topic.

The business reason behind the script is that a lot of organizations still have thousands of documents on server file shares.  At some point these organizations will want to migrate those files into SharePoint to make them more available for collaboration, and to facilitate management of the files. FCI allows organizations to assign metadata to all the files on a file server, and this new script will enable transfer of the files and the associated metadata into SharePoint.

The combination of FCI and SharePoint overcomes a major hurdle in using the full power of SharePoint -populating files with metadata.   Metadata allows users to filter and search information in SharePoint in a much more powerful way, especially with SharePoint 2010 features such as navigation hierarchies and key filters. Many customers say they can get their files into SharePoint, but they have no idea how to assign metadata to all these files.  FCI along with this new script allows organizations to overcome this hurdle. 

Getting metadata into SharePoint provides benefits for user search and file disposition and can also be used to strengthen security via products like our Metadata Security for SharePoint. 

The new script is called FciSharePointUpload.ps1 and is available from Microsoft at this download site.

The script provides two options:

Option 1: Upload a file to a SharePoint Library - SharePoint 2007, SharePoint 2010.

 

FciSharePointUpload.ps1 –file <file path> -url <target site> -libPath <relative library path> [-name <target name>] [-sourceAction {keep|delete|url}] [-targetAction {overwrite|skip|fail}] [-propertyAction {copy|ignore}] [-user <user name> -password <password>]

 

Option 2: Upload a file to SharePoint using the official file web service that is coupled with a content organizer (e.g.: Record center) – SharePoint 2010 only.

 

FciSharePointUpload.ps1 –useOfficialFileWebService –file <file path> -url <target site> [-name <target name>] [-contentType <content type name>] [-sourceAction {keep|delete|url}] [-propertyAction {copy|ignore}] [-user <user name> -password <password>] [-additionalProperties] <property list>

 

The parameters are as follows:

• file: path to the file to upload (required)
• url: URL to the SharePoint site (required). Example: -url ”http://sharepoint/sites/mariant”
• libPath: relative path to the document library within the site (required), Example: -path ”Shared Documents”
• name: name of the target file (optional). If not specified, it defaults to the source file name as specified by the “file” argument. Example: -name Test.docx
• contentType: name of the content type to use for the document (optional). If not specified, defaults to “Document”
• sourceAction: indicates how to handle the source file after a successful upload (optional) - 1) keep - leave the file in place (default) 2) delete: delete the file;3)url: replace the file with a shortcut to the uploaded document’s URL
• targetAction: specifies how to handle existing destination documents (optional)  - 1) overwrite, replace (default) , 2) skip: leave existing version and continue , 3) fail: return error
• ropertyAction: specifies FCI property transfer mode (optional) - 1) copy: transfer properties (default) , 2) ignore: do not transfer properties, let SharePoint choose defaults
• user: user name to use for authentication (optional). The argument is ignored if “password” is not specified.
• password: password to use for authentication (optional). The argument is ignored if “user” is not specified.
• additionalProperties: list of extra properties to use for the document (optinal). The argument is followed by a space-separated list of strings. Each group of three strings is interpreted as the name, type and value of the property to add, in this order. The list size must be a multiple of three. These additional properties are always used, regardless of the propertyAction argument value. Example: -additionalProperties PII Boolean True BusinessImpact Choice High

Here is an example I created.  I created a file share called "Merger".  I then tagged all the files in this share with metadata property called CorpClassification, and a value of "CONFIDENTIAL" using FCI (you can't actually see the metadata in the file system).

I then created a column called CorpClassification in a SharePoint library called Merger, and using the script I copied these three files into the SharePoint library.  As you can see the metadata has been transferred with the files.

Be careful when creating the property and column type in FCI and SharePoint.  These have to match up as per the script requirements, or the script will not work.  In my case, the FCI property was of type "Choice", this means I had to create a column of type Choice - Checkboxes in SharePoint. If I tried to define any other column type (e.g Choice - Dropdown) the script will not work.

SharePoint 2010 Navigation Hierarchies and Key Filters

You've probably noticed that I've had a few posts on the SharePoint 2010 Managed Metadata feature since I got back from the SharePoint conference.  We get excited about this kind of thing because metadata is a big part of all of the software we build here. But some people are probably saying "Why should we get so excited about new metadata features in SharePoint?  The new UI and improved capacity are really the neat things about SharePoint 2010." Well, I guees it all depends on your point of view. The way I see it SharePoint is all about colloboration and document / records management.  The more easily you can work within SharePoint and the more easily you can find stuff, the more productive a knowledge worker can be.  So that's why I thought I would cover off the new Navigation Hierarchies and Key Filters in SharePoint 2010 today. Once you have your metadata into SharePoint you can start taking advantage of it, and navigation hierarchies and key filters are 2 great examples of how you can leverage metadata in SharePoint.

Navigation Hierarchies

Navigation Hierarchies appear in the left hand pane of the new user interface and allow users to navigate metadata taxonomy in order to filter the view of lists / document libraries etc. For example, I've setup a document library that contains documents with different security classifications.  To do this I've added a column called Classification that has possible values of PUBLIC, CONFIDENTIAL and INTERNAL. Here is the document library:

 
 (click to see larger image)
  
I can turn on the navigation hierarchy for this library by going into the Document Library settings, selecting Metadata Navigation Settings, and then adding the Classification column to the list of Selected Hierarchy Fields.

 

Once this Setting is in place we can go back to our document linrary and we will see Classification as a available field in the Hierarchy:

By clicking on the CONFIDENTIAL value in the hierarchy, I will see only the CONFIDENTIAL documents in my library.

 

Maybe not that impressive in a document library that only has 15 documents, but in a library that may contain a few hundred documents this would really help users filter down to specific documents they want to find and work with.

Key Filters

Key Filters also appear in the left hand pane of the user interface just below the navigation hierarchy. Key Filters operate in a similar fashion to the navigation hierarchy.  They are also used to filter a list or document library.  The difference is that the user does not have to navigate a hierarchy, they can simply type in the value they wish to filter on, or in some cases select the value from a drop down list.  When the user clicks Apply, their list or library will be filtered based on the value. 

In order to configure the Key Filters option, the administrator goes into the Document Settings, Metadata Navigation Settings, and then adds the Classification column to the Selected Key Filters Fields.

These features should help your users get more value out of the metadata.  If you are interested in using metadata for SharePoint security see the Metadata Security blog.