SharePoint MetaData and Classification

Fail Safe Security for Microsoft SharePoint

Microsoft SharePoint is used in many highly secure environments around the world that deal very sensitive information – information that is considered ’secret’ or ‘top secret’ and where security of that data is critical to not only business but also to national security. These deployments exist primarily in military and government installations, or as part of the intelligence community. In these SharePoint deployments, its extremely important that security and access control policies be configured in such a way that they “Fail Safe”.

The concept of “Failing Safe” means that if the security system which implements the access control policies fails, for whatever reason, that sensitive information will automatically have the most restrictive access rights automatically applied. Therefore, in these cases, if such a system failure occurs then the sensitive information that is being protected is not left open and in the clear, allowing non-authorized users to access it.

Examples of an access control policy system failing could be an authorization server going down, it could be an inadvertent reboot of a server, or it could even be an unauthorized user gaining access to the environment and interrupting communication between the authorization system and the content management system (SharePoint). There are many such examples. Hardening critical infrastructure and protecting it against all possible forms of attack or circumstances that might arise is a very difficult task that must be performed. However, you also want to ensure that you look at this problem from the point of view of: if all else fails, then access to my sensitive information will revert back to the most restrictive access rights possible so that my sensitive data is not inadvertently released.

TITUS Metadata Security for SharePoint uses trusted claims about a user, and combines them with document metadata to ensure that the right people are accessing the right information in SharePoint. TITUS Metadata Security automatically applies fine grained access control to SharePoint content using the SharePoint permissions system. This has the advantage of enforcing the access control policies that administrators or site owners configure on all the mechanisms that information workers can use to access content within SharePoint, including the SharePoint web view, the explorer view, search, FAST search, the client object model, the server object model and any web services that may be deployed. With TITUS Metadata Security, policies are dynamically enforced, so that as a user’s identity changes or as metadata changes, security policies are automatically applied and user’s are only accessing the content they are permitted to access.

TITUS allows you to set the default permissions on all content within SharePoint to the most restrictive access rights possible. Then when defining access control policies and enforcing those policies with TITUS Metadata Security, TITUS will simply add the appropriate access rights for specific users, groups, or users with specific claims to only gain access to sensitive content that they are permitted to access . This allows Microsoft SharePoint to “Fail Safe” so that if a malicious user or a failure in process subverts the access control policy system, that your sensitive information will revert back to its default inherited SharePoint permissions (the most restrictive access rights possible) and still remain secure!

There are several other systems on the market which implement access control policies or entitlement management in Microsoft SharePoint. However, these systems often require that default permissions on all content be initially configured to the most open access rights possible. The issue here becomes that if that access control system were to be subverted or fail, for whatever reason, and if SharePoint then reverts back to its default inherited permissions then all content including your most sensitive content will be inadvertently leaked. TITUS Metadata Security for SharePoint is the only leading fine grained security system for Microsoft SharePoint that allows SharePoint to”Fail Safe”.

TITUS Metadata Security for SharePoint allows organizations to leverage all of the benefits of user claims and document metadata to secure their sensitive information in SharePoint. It ensures that the right people are accessing the right information and it allows Microsoft SharePoint to implement Fail Safe Security so that sensitive information remains secure in all circumstances.

-Antonio

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

Previously, we’ve talked about how using trusted attributes of a user’s identity (or claims) along with document metadata is a very robust way of enforcing security policies within Microsoft SharePoint 2010. This article reviews another important tool that can be used to configure security policies for SharePoint:  Claim Rules.

In general, claim rules can be used to centrally evaluate, transform or augment claims before they are returned to a relying party application like SharePoint. Microsoft Active Directory Federation Services version 2.0 (ADFSv2) can act as a trusted identity provider to SharePoint and other relying party apps.  It provides a great interface with templates for creating and editing claim rules as part of its management console.  As well, it provides a ‘claim rule language’ that can be used to configure detailed policies with very specific conditions. This allows us to configure specific claims to be retrieved under very specific conditions, and thereby enforce very specific security policies for authentication and authorization.

This series of articles talks in detail about how to use this mechanism to enforce dynamic access control policies within SharePoint 2010 and, it illustrates how these policies relate to particular industries and regulations in SharePoint.

This article assumes an in-depth level of knowledge related to configuring SharePoint with Claims Based Authentication using ADFSv2.  For additional background on these topics please see the following article: An Architecture for Claims Based Authorization in SharePoint.

SharePoint 2010 can be configured to connect to a trusted identity provider like ADFSv2 to authenticate a user at sign-in time.  This is called Claims Based Authentication.  Under such a configuration, when a user signs into SharePoint, it will communicate with ADFSv2 passing it the user’s credentials.  ADFSv2 will then authenticate the user against Active Directory.  Before this happens, ADFSv2 will have been configured to trust the SharePoint 2010 server (the relying party) that is connecting and, as part of that trust relationship, ADFSv2 will have also been configured with 1 or more claim rules.  After the user is authenticated, ADFSv2 will apply the configured claim rules to the incoming claims in order to transform or augment them before they are issued and returned to SharePoint.

Configuring Claim Rules

ADFSv2 can be configured to accept incoming claims as well as issue outgoing claims.  In either case, trust needs to be configured between ADFSv2 and the calling app.  For incoming claims, the trust relationship in the ADFSv2 management console is referred to as the “Claims Provider Trust”.  For outgoing claims, or claims that ADFSv2 issues to a relying party, the trust relationship is referred to as the “Relying Party Trust”.  The important point here is that claim rules are configured as properties of these “trusts”.

ADFSv2 Management Console

ADFSv2 can be configured with one or more trusts (one for each calling application), and each trust can have one or more claim rules. When configuring a trust for SharePoint, you will need to provide the realm of the SharePoint server. ADFSv2 will use the realm passed to it in order to map a particular request to a particular trust that’s been configured.  For more information on configuring the realm, see the following:  Configuring the Realm for SharePoint 2010 and ADFSv2 to Retrieve Claims.

Once the trust is configured for the particular SharePoint server, to create a claim rule for that trust, perform the following steps:

• In the ADFSv2 Management Console, click Relying Party Trusts in the tree at the left side
• Right click on the particular trust which pertains to the SharePoint server you’re working with
• Click the Edit Claim Rules menu
• Ensure that you have the Issuance Transform Rules tab selected (the first tab)
• Click the Add Rule button and follow the instructions in the wizard – it is quite easy to use
• Keep in mind that the claim rules will be executed in the order listed. This can be important, especially if you have one claim rule acting on the claims issued by another rule. You can use the arrows on the right side of the Edit Claim rule window to change the order and get the desired output.

Once you’ve configure a set of claim rules for a particular trust, unfortunately they cannot be reused on another trust. If you must reuse the same claim rule(s) with more than one trust, you’ll need to manually recreate them. We’re focusing on enforcing security policies within SharePoint, so this particular article will focus only on claim rules configured for a Relying Party Trust which issues outgoing claims to SharePoint. From this point forward, the article will refer to SharePoint as the relying party, but please keep in mind that any relying party can be configured and used with the same types of claim rules.

Again, when a user signs into SharePoint, SharePoint will call its configured trusted identity provider, ADFSv2 in this case, and ADFSv2 will authenticate the user against its directory or database. Then ADFSv2 will execute the claim rules that have been configured with the particular trust for the calling SharePoint server. These particular claim rules will be used to determine which attributes are ultimately issued to (ie. returned) to SharePoint.

Claim Rule Templates

Claim rules will be used to determine which attributes are ultimately issued as outgoing claims (ie. returned) to SharePoint. These rules can be quite simple – for example, they can simply retrieve specific LDAP attributes from Active Directory and return them to the connecting SharePoint server as SAML claims. They can also be more complex, and we’ll see some examples of that later. The ADFSv2 management console provides 4 templates and an easy to use wizard for configuring rules. For many security policies, these templates are quite sufficient for achieving a policy’s intended purpose. These templates are:

1. Send LDAP Attributes as Claims

• Probably the simplest type of rule, it can be used to retrieve user attributes from an LDAP directory and issue them as outgoing claims to SharePoint.
• It can be used to perform a simple mapping of attributes if required, from an LDAP attribute name to perhaps a different name (or claim type) that SharePoint is expecting. For example, a claim rule could retrieve the standard LDAP attribute ‘organizationStatus’ and map it to the claim type ‘EmployeeStatus’ if that’s more appropriate for the intended user experience within SharePoint.
• Multiple claims can be retrieved or mapped with a single rule.
• Performance can be somewhat affected by this type of claim rule due to the account look up that must occur. However, for all practical purposes the performance impact appears to be minimal for each individual request.

2. Send Group Membership as a Claim

• This claim rule will check to determine if the user is a member of a specific AD group and if so, it will issue a specified claim with a specified value. This can be very helpful if you already have security groups in place and want to leverage them to enforce claims based authorization policies in SharePoint.
• The unfortunate thing about this template is that each rule will only check membership to 1 group. You can create multiple instances of this type of rule for the same trust, and within each rule check membership to a different group so that a particular claim is issued in each case. However, if you want to enforce policies where a user must belong to multiple groups in order to access content within SharePoint, then a more sophisticated solution is needed – Please see Part 3 of this blog series for an example of how to accomplish this with the Claim rule Language.
• As well, this claim rule does not support SharePoint groups, only Active Directory groups. To check membership to SharePoint groups, you must create a custom claims provider that runs on your SharePoint server… but that is for another day.
• One positive thing about this rule template is that it is very fast to execute. The reason is that one of the default claims that ADFSv2 retrieves is the list of all groups SIDs that a user belongs to. ADFSv2 does not need to do any additional account look up.
• This rule can only be used for users that authenticate locally using AD DS (Active Directory Domain Services) and come through ADFSv2 through the Active Directory Claims Provider Trust.

3. Transform an Incoming Claim

• This claim rule compares the type of an incoming claim to a selected type. Depending on its type, it can apply various actions to transform the type or value before issuing the outgoing claim to be returned to SharePoint.
• If the incoming claim matches the selected type, one option when configuring this rule is to simply pass it through and have it issued with the same type and value.
• Another option is to modify the type of the claim before it is issued as an outgoing claim. So, for example, an incoming claim could be of type “OrgStatus” and this rule could be used to issue it as the outgoing claim type “Status”, keeping its current value. Another incoming claim in the same environment could be of type “OrganizationStatus” and a similar rule could issue it as the outgoing claim type “Status”, again keeping its current value. This type of rule can help to normalize claim types when they are coming from various sources and perhaps have differing claim type names, but all mean the same thing.
• Additional options in this rule template allow you to modify the value of the claim before it is issued. The following options are available:
  • If the value of an incoming claim equals a specified value, then change its value to a new specified value before issuing the outgoing claim. There are no StartsWith, EndsWith or Contains-like options available here. More complex value checking requires a custom claim rule – see Part 2 of this blog series.
  • If an incoming claim contains an email suffix, then replace it with a specified email suffix.

4. Pass Through or Filter an Incoming Claim

• This claim rule compares the type of an incoming claim to a selected type. Depending on its type, it can optionally apply other filters before issuing the outgoing claim to be returned to SharePoint.
• If the incoming claim matches the selected type, one option when configuring this rule is to simply pass it through and have it issued.
• Another option is to filter it based on certain values. The following options are available for filtering:
  • Only issue the claim if its value equals a specified value – for example, if an incoming claim is of type ‘EmployeeStatus’ and if its value is ‘Full Time’. The claim is issued only if both conditions are met.
  • Only issue the claim if it is an email address and if it ends in a particular value – for example, check if the claim type is E-Mail Address, and if so issue it only if the email suffix is ‘titus.com’ or some partner email domain.
  • Only issue the claim if its value starts with a particular string – for example, check if the claim type is Department and if its value starts with certain department acronym.
• Claim values cannot be changed with this type of rule. They must either be issued or not based on their type and value.
• This rule can apply to claims that have been issued by previous rules. One interesting use for this type of rule is if certain claim types contain sensitive information and you do not want that information to be issued to certain relying parties. The issuing of certain outgoing claims can then be restricted based on their values.

Once a user has signed in and their claims are retrieved, SharePoint 2010 does a great job of enforcing permissions on documents and items to which claims have been assigned with a permission level. 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. Centrally managing how claims are retrieve and returned through ADFSv2 claim rules 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.

Once again, for many security policies these rule templates are sufficient for achieving a policy’s intended purpose. If more sophisticated policies are required, ADFSv2 does provide a Claim Rule Language that can be used to author detailed policies with very specific conditions. Please see Part 2 of this blog series in order to learn more about how to use the Claim Rule Language.

-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

Microsoft SharePoint Conference Presentation on Claims

I got quite a few questions and request for copies of my slides for the presentation I did a few weeks ago at the Microsoft SharePoint Conference 2011 in Los Angeles.   The presentation was called Using Claims for Authorization in SharePoint 2010. For an explanation of how claims can be used for authorization (deciding what documents or items users are allowed to see) in SharePoint click on this link to download my presentation. The PowerPoint has been converted to PDF format.

I have also started a blog series on Claims in SharePoint and here is my first post What are Claims – Using Claims in SharePoint.

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

Records Management – Automation, Metadata and Security Considerations

Hello from the Microsoft SharePoint Conference 2011 in Anaheim CA.

Many enterprises use Microsoft SharePoint for Records Management.  Despite how much has been written on this, Records Management is sometimes confused with Document or Content Management , but it’s in fact quite a unique discipline with its own best practices and processes. Microsoft SharePoint 2010 provides some great features to enable these processes, and it provides enterprises with the appropriate controls over the data and documents that they declare to be corporate records.  Here at the Microsoft SharePoint Conference, Records Management figures pretty prominently among several of the sessions.  There’s lots to learn here about managing records and I’m going to review some of that in this post.

 

Introduction to Records

To start things off, a record refers to a document or some other piece of data in an enterprise  (electronic or physical) that provides evidence of a transaction or activity taking place, or some corporate decision that was made.  A record requires that it be retained by the organization for some period of time.  This is often a legal or regulatory compliance requirement.  As well, a record by definition must be immutable, which means that once a document or piece of data is declared to be a record, it must remain unchanged.

These requirements for records immediately suggest certain processes that must be in place to ensure that they’re managed appropriately from several perspectives:  business , auditing/legal , tax, revenue , and even business continuity.  As we often find, for business processes to be applied consistently across all SharePoint content or records, automation is a key requirement, as well as making appropriate use of metadata.

Working with Records in Microsoft SharePoint

Declaring Records and Retention

First, its important to determine what type of content should be considered a record.  For example, if I’m working on my department’s budget for next year, my initial draft and its various iterations should likely not be considered records because they are still changing – they are not yet approved, nor are they final, nor can I make any decisions based on those preliminary versions.  But once my budget is ‘approved’ or considered ‘final’ then it can be declared a record because I can now base corporate decisions on it.  Establishing a policy around what type of data is a record requires planning, meeting with appropriate stakeholders and agreeing on policy that’s communicated to everyone that may be declaring content as a record.

Next, its important to assign a retention period to records.  The period for which records are retained, along with the process followed once that time period has expired, is a critical requirement for records management.  There are legal and business implications to consider when content is kept content too long.  The business policy could be that after X years, a record is archived and then after Y years from that point it is disposed (which could include deletion or moving it to offline long-term storage).  Again, establishing this policy requires planning and getting agreement from stakeholders, especially around any legal, regulatory compliance, revenue or tax implications.

Records Management Features

Once that policy is in place, Microsoft SharePoint provides several features to enable users and/or automated processes to actually declare content to be a record:

1. Records Center Site

The records center site is essentially a SharePoint site dedicated to centrally storing and managing records.  SharePoint 2010 still has the Record Center Site template from MOSS2007, but it now provides integration with several new very useful features including:

• A dashboard view at the site level for Records Managers with searching capabilities
• Integration with the Content Organizer for routing records within the site
• Document ID service to assign a unique identifier to documents which travels with it
• Email Integration with the Content Organizer
• Legal Holds
• Metadata Navigation/Filtering

Depending on the business need, it may make sense to centralize records management and storage in this way.  If the business demands that a small number users be considered ‘Record Managers’ and its their role alone to declare content as records then it may make sense to follow this approach and make use of the Record Center Site.

2. In-Place Records Management

This feature allows individual users to declare documents/content as records while they reside in their current location.  In using this feature, records do not need to be moved or added to a central Record Center site, nor do they need to be routed within the Record Center.  This is a trend in the records management space, because it allows users to continue find content where it resides, based on its business nature or properties.

In-place records management is not enabled by default, and you need to activate the feature at the Site Collection level.  You can also configure various options like:

• Restrictions imposed on in-place records:  Block Delete, Block Delete and Editing
• Availability of In-Place Records Declaration – if this feature is turn on, then Declare Record and Undeclare Record buttons appear in the ribbon bar for end users; if turned off, then records can still be declared in place but only by workflows or retention policies
• Declaration Roles – specifies the types of users that can declare and undeclare records; the options here are: all list contributors and administrators (any users with the edit items permission), only list administrators, only policy actions (only policies or custom code running as System Account can declare/undeclare records)

Once configured, it will be available for all sites and libraries throughout the site collection.  You can then restrict access to it on individual libraries and lists by configuring their settings in Library/List Settings.

The other great features mentioned for the Record Center Site are also available for In-Place Records management.

This type of in-place records declaration and the settings mentioned suggests that other individuals be enabled to make the decisions about declaring and undeclaring records.  Depending on the business need, enabling a broader range of end users to declare content as records may or may not make sense.  You tend to find that individual employees, those not typically designated as records managers, can be nervous or apprehensive about declaring content to be records for the enterprise because it implies a level of official accountability or legal declaration over that content.  So, there are some ways to make this simpler using some automated retention policies and metadata.

3. Retention Policies and Workflows

Retention Policies and Workflows in SharePoint can be used to automatically declare documents as records after a certain time period or based on certain metadata values.

Retention Policy

A retention policy can be configured so that certain actions are taken on documents after a certain period of time.  For example, a Retention Policy could be configured so that if a document has not been modified for 2 years it can then automatically be declared a record and moved to the Record Center Site.  Retention policies can also be multi-staged so that, for example:

• After a document has not been modified for a year then all previous versions of the document are deleted
• After a document has not been modified for 2 years then it is declared a record
• After it has been a record for 7 years it is automatically disposed

Retention policies can even be configured for non-records (active documents) and used to delete or dispose of outdated or expired content after certain periods of time.  In the same site or library you can have different policies for records than for non-records.

Retention Policies can be configured for a number of different circumstances:

• For content types and applied to all instances in the site collection
• For content types at the site level and applied to all instances in the site
• For individual libraries, lists or folders

There is some very good instructions found here on how to configure these policies:  http://office.microsoft.com/en-us/sharepoint-server-help/create-and-apply-information-management-policies-HA101631505.aspx

Workflows

Workflows are a very useful and widely used feature of SharePoint.  They are used to enable many different business processes across thousands of SharePoint deployments.  Some great things you can do when creating a workflow are:

• Configure it to send a document or item to another site
• Configure it with conditions so that it is triggered only when certain metadata fields are equal to specified values
• Configure it with additional actions like emailing users

By combining this condition with these actions, you can create workflows that will automatically trigger when a Status metadata column is set to ‘Final’ by an end user.  This can then cause the workflow to automatically send the document to the Records Center Site (causing it to become a record) and send an email to the Records Manager to approve the declaration of the record.  In addition, this and other workflows (that perhaps don’t involve metadata) could be triggered by a Retention Policy so that these actions automatically occur after a certain amount of time has passed.

What you accomplish with this type of configuration is that you’ve removed the need and any apprehension for end users to officially declare records.  You’ve also used metadata to determine when active documents are ready to automatically become records.  You’ve sent a notification to the Records Manager so that they are aware and can provide any approval if needed.  And finally, you’ve dealt with abandoned items where metadata is not updated  but the document can still become a record if needed.

Due in part to the rate at which content is growing in SharePoint, its easy to see why using automation to declare and manage records is a recommended strategy for consistently applying policies across your farm.

Security Implications

There are some security implications that you need to think about if you are taking sensitive content in SharePoint and declaring it as a record.  For example, if you are using the Record Center Site and a sensitive document with very specific item level permissions is declared a record it may be automatically moved to the Record Center, however its permissions will not be moved with it.  It will inherit permissions from the destination library within the Record Center.  This can be especially problematic if you have a very active Record Center which users refer to often

TITUS Metadata Security for SharePoint can automatically apply permissions to sensitive content in SharePoint, even within the Records Center Site.  It can ensure that specific item-level permissions are maintained on content when it is active, and after it has been declared a record.  It does this by using metadata to determine the security permissions that must be applied – the same metadata that can be used to trigger records management policies.

With In-Place Records Management, SharePoint can display a lock icon beside a document once it is declared a record.   This is a great feature which lets users know that they’re looking at or working with a record.  However, if the document is saved locally, emailed or used in other circumstances it can be difficult for end users to realize that they are working with an official corporate record.  Its important to ensure that end users are aware of when they’re dealing with official records.

TITUS Document Policy Manager for SharePoint can automatically apply visual labels to Microsoft Office and PDF documents in order to raise awareness about when end-users are dealing with official corporate records.  These labels take the form of headers, footers and watermarks within the document, so they travel with the record.  As well, they are completely configurable and make use of document metadata, so they can be formatted to conform to corporate document templates.  Finally, they can include security labels, information about the retention policy for the record and include disclaimers about how the record can be distributed.

To Sum Up…

Microsoft SharePoint can be used as a full-featured robust Records Management system.  It contains some great features that can be used to define the appropriate records and retention policies for the business.  Its key to use automation and leverage metadata to ensure that records management policies are applied consistently across all your SharePoint content.

Its also important to understand the security implications and ensure that records, like all sensitive content in SharePoint, have the appropriate permissions and the appropriate visual labels.  TITUS Security Suite for SharePoint can help automate these processes , so that end users only access the records they are permitted to access, and so that they understands what is a record and how to handle it.

-Antonio

The Benefits of Metadata in SharePoint

I read a great article recently on the benefits of using Metadata in SharePoint that I wanted to share. Its written by Michal Pisarek and can be found here: The Battle for Metadata in SharePoint 2010.

Whether government or military personnel are classifying documents, or whether people at home are sorting through digital music, metadata is becoming a fundamental part of our work and home lives. Within SharePoint itself, metadata is put front and center as an intrinsic component of the entire system. This article talks about how people have already been working with metadata for years, and how it can solve real business issues in SharePoint.

Enabling Governance and Collaboration in SharePoint

There are some things in life that just don’t seem to go together.

America and Soccer.

 

These two things don’t go together…or do they?  In the past, soccer has never been a first-class citizen in the world of American sports.  Even though soccer is the most popular sport in the world (based on number of fans), it is not even in the top ten most popular sports in America.  Despite these statistics, if you think back a few weeks, in a flurry of attention and fanfare, the 2011 US Women’s National soccer team made American history in their world championship game.  Not because they won (because they didn’t), but because they made Americans realize how much they valued the game of soccer.  Their game drew over 14 million American viewers, making it the second-most-watched women’s game in US television history, and ESPN’s most-watched and highest-rated soccer game ever.

Governance and Collaboration.

 

These two things don’t go together…or do they?  At first thought, these things seem completely opposite, and would almost hinder each other.  Both are very important in organizations, but both are very different concepts.  Governance has to do with disciplined handling of information with the goal of properly controlling that information.  Collaboration is about sharing knowledge without boundaries with the goal of freely sharing information with the right people.  In today’s organizations, information is exploding, and collaboration is becoming more and more mainstream.  Because of this explosion of information, governance on this information not only enhances collaboration, but has become a crucial component of a successful and secure collaborative environment.  In order for users to freely and successfully share information with each other, a comprehensive, high level data governance model must be put in place.  It could be said that the explosion information within collaborative environments has made organizations realize how much they need and value data governance.

Microsoft SharePoint is the world leader in enterprise collaboration and content management.  SharePoint is Microsoft’s fastest revenue growth product in company history, even faster than Windows and Office!  Mirroring this growth is the growth of information within each SharePoint environment.  Many of our customers express that their collaboration sites are quickly growing to a point where they are out of control.  SharePoint administrators, and subsequently SharePoint users, cannot properly control the information being shared, stored, and collaborated on within SharePoint.

Increased concerns regarding corporate accountability and compliance, as well as efficiency, are driving the need for organizations to maintain a consistent data governance policy.  The recent high-profile case of a Massachusetts hospital healthcare worker mishandling a sensitive document (resulting in a $1 Million penalty) is just another example that illustrates the need for data governance within organizations.

For proper data governance within SharePoint, organizations must put into place a set of processes, activities and procedures for ensuring that important data assets are formally managed throughout the enterprise, and throughout their lifecycles.  There are 8 steps to creating an effective data governance model for SharePoint:

1. Define Roles/Policies and Stakeholder Agreements
2. Apply Security Settings
3. Enforce Document Creation Rules
4. Control Access
5. Raise Awareness of Data Sensitivity
6. Promote End-User Accountability
7. Manage and Log Document Lifecycle Events
8. Audit and Report

For more details on these steps for how to successfully implement a data governance model within SharePoint, I urge you to read our whitepaper.  Please visit www.TITUS.com/software/sharepoint/ to learn how the TITUS family of products can introduce data governance to your SharePoint environment.  TITUS products automate technical security controls through consistent, automated enforcement of metadata generation, document conversion to PDF, and labelling of documents.

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.