Claims-Based Security in SharePoint 2010

The introduction of claims-based security support in SharePoint 2010 opens up several new doors with respect to managing the user accounts required to establish user identity. User identity is crucial in SharePoint Foundation and SharePoint Server 2010 because it provides the underlying infrastructure for essential services such as security, access control, auditing, and personalization and user profiles.

In SharePoint Portal Server 2003, user identity could only be established using a Windows identity, which forced companies to maintain an Active Directory (AD) account for each individual user. While this constraint was fine for intranet environments where all the users are employees of the same company, it was a painful fit for extranet environments and publicly-facing web sites.

SharePoint 2007 broke the dependency on AD for establishing user identity by integrating ASP.NET support for forms-based authentication (FBA). Today, many companies with SharePoint 2007 environments use FBA and an ASP.NET authentication provider to establish the identity of external users such as partners, vendors and customers. This approach typically involves creating user accounts and managing their credentials in a SQL Server database and removes the requirement to create a new AD account for each user.

Although the new FBA support in SharePoint 2007 was a step in the right direction, it did create a few new problems of its own. First, companies using FBA were forced to either build or purchase a user account management application in order to create new user accounts and to reset user passwords. That’s because the SharePoint platform never has and never will supply a UI or any of the code required to manage FBA user accounts.

A second problem is that companies usually create a separate implementation of FBA support behind each SharePoint farm and each ASP.NET application. This leads to scenarios in larger environments in which there are several redundant FBA databases that all track the exact same set of users. This causes extra work and potential confusion for users as well as the IT department.

SharePoint 2010 provides solutions to these problems with the introduction of claims-based security. The central concept is that a SharePoint 2010 farm isn’t hard-coded to a specific set of identity providers such as AD and ASP.NET authentication providers. Instead, you can configure trusts in a SharePoint 2010 farm and use any identity provider that you’d like. That is, as long as the identity provider has been designed and implemented in accordance with emerging Internet security standards that are collectively known as the WS-* Security Standards. The actual names of these standards include WS-Security, WS-Security Policy, WS-Trust and WS-Federation.

The good news is that there are already quite a few existing identity providers you can use to establish user identity in SharePoint 2010. For example, your company can outsource its identity management requirements to an identity service publicly available on the Internet such as Microsoft’s LiveID or Google’s OpenID.

This gives you the ability to track who your users are for the purposes of security, auditing, and personalization. This approach also lets you avoid the hassles of setting up a user database, storing credentials, and all of the associated password management headaches.

Let’s say you need to create and configure a SharePoint 2010 web application for your company’s public-facing web site. You are required to make this web site accessible using anonymous access, but you also need to make it possible for customers to log into the site to establish user identity. You can configure a trust within this SharePoint 2010 farm to the LiveID service and the OpenID service, then configure the web application to trust both of these identity providers.

When customers attempt to log into your web site, they will be redirected to the site for either LiveID or OpenID and prompted to enter their credentials. After they authenticate against the external identity provider, they will then be redirected back to your web site with an established identity. The best part about this approach is that it can be entirely accomplished through configuration, without having to write a single line of custom code.

Let’s say you work in an enterprise environment which suffers from the problem of redundant FBA databases containing the same set of users. You can leverage Active Directory Federation Services 2.0 (ADFS 2.0) to stand up your own custom identity provider that can be used across many different SharePoint farms and ASP.NET applications. This can provide a strategic approach in enterprise environments to create a centralized repository of user accounts for employees, partners, vendors and customers. In some scenarios this can be done without writing any custom code. In other scenarios, you can quickly adapt the FBA user management code you wrote for SharePoint 2007 with ADFS 2.0 in order to create and manage the user accounts in a far more reusable way.

Forrester: SharePoint, On Its Own, Isn't Cut Out for BPM

SharePoint as a Platform


Yes, we know that SharePoint (news, site) is a platform. And we know that the key use for it is business collaboration. But being a platform typically means you can extend and/or build onto it to do many different things.



One of those other things appears to be business process management. In a recent report, entitled SharePoint and BPM — Finding The Sweet Spot, Forrester (news, site) dives into how SharePoint has been extended to support BPM and where it has fallen short of being the solution most organizations typically need.



While SharePoint makes simple workflows easy to create, on its own it is not suitable for business process applications. A rich BPM experience is available using the SharePoint platform, but this will require the use of partner products to achieve optimum results.



And that is the gist of this research paper. Yes, you can try to build business process applications on top of SharePoint. No, you will probably not be satisfied with the results, unless you have integrated a third party BPM product.



Why Not SharePoint for BPM?

Forrester offers several reasons why SharePoint offers limited features for BPM, including:



Out of the box, SharePoint processes are simple, so you can't create seamless business processes without a lot of custom coding.

Yes, to build a real business process application, there's a lot of custom coding you will have to do and that of course takes time, costs money and introduces a number of problems related to the flexibility of the application.

Site collections, while great for helping organize content and information, can be a major problem when developing business processes that cross organizational boundaries.

Governance issues rear their ugly head in this instance as well. A well-governed SharePoint implementation will go a long way towards supporting effective business process apps. Unfortunately Forrester tell us that organizations still have a ways to go in this area.

The big culprit that limits SharePoint for BPM solutions is its underlying architecture. SharePoint uses Windows Workflow Foundation (WP), which supports only two process patterns: sequence and machine state. This results in SharePoint working best on the procedural end of the process spectrum, while most SharePoint deployments are focused on on the opposite end — as practices:

SharePoint and Business Processes

Partners Can Provide Added Capabilities

Forrester points out that because SharePoint can only offer procedural-based processes without a ton of complex coding, it can't easily offer the ability to adapt processes to handle the exceptions that would be required in typical SharePoint implementations.



Most people new to BPM tend to think that standardization of all work and activities is the end goal. However, depending on the type of process, more and more exceptions emerge, with process developers building in workarounds and redeploying models. After a while, one discovers that longterm TCO is closely related to the ability to elegantly handle exceptions.



And this why even Microsoft encourages finding an integrated partner application to fulfill the BPM requirement. Some of the vendors that offer solutions include AgilePoint, Global 360, K2 and Nintex. All offer different ways to resolve the challenges that SharePoint offers out of the box. Some are better than others.



A Platform Must be Leveraged Properly

What this all boils down to is the reality that platforms can't do everything, and that includes SharePoint. Yes we understand that certain amount of customization doesn't hurt, otherwise what's the point of a platform really — just build it as an application.



But, SharePoint was not built to provide business process management on its own. So check out the available third party tools if you want to add some business process capabilities to your SharePoint implementation and spend your SharePoint development effort on something it does do well.

Top 6 New Features for SharePoint Designer 2010 Workflows



What are my favorite new features for SharePoint Designer workflows?
1. Reusable workflow
This new feature allows you to create a workflow that can be applied to as many lists or libraries on the site as you need. The reusable workflow can be attached to a list or library using both SharePoint Designer or using the workflow settings page in the UI. In addition, the reusable workflow can be associated with a particular site content type. The workflow can then only be activated only on lists or libraries containing that content type, which eliminates the need to build a check content type action into the workflow itself.

2. SharePoint Designer ribbon allows easy access to workflow building blocks
The SharePoint Designer ribbon is your one-stop-shop for all the tools and parts you need to create your workflows.

3. Workflow action prompt
You can now type your workflow logic directly into the workflow. SharePoint Designer will prompt you with the possible actions that match what you are typing. This makes creating each step in your workflow much more efficient.

4. Customize out of the box workflows
Using SharePoint Designer, you can now customize the out-of-the-box workflows that come with every SharePoint site. This means that you can make small tweaks and adjustments to the pre-configured workflows without having to create your own custom workflow from scratch.

5. Impersonation step
The impersonation step allows the workflow to perform all actions within that step with the permissions of the author of the workflow, not the person who initiates the workflow. This means that the workflow can perform actions the user would otherwise be restricted from doing on the site – for example copying an item or document to another library to which the user has only visitor access.

6. Two-way import/export between SharePoint Designer and Microsoft Visio Premium 2010
This new feature allows SharePoint workflows to be built visually using tools in Visio 2010 and exported directly into SharePoint Designer. Using the Microsoft SharePoint Workflow template in Visio (found in the “Flowcharts” template section), you will get access to all the actions and conditions available within SharePoint Designer. The screenshot above is only a small sample of those available. In addition, workflows already created within SharePoint Designer can be imported into Visio for visual representation.
Bonus! Workflows no longer have to be tied to a list item

Although not specifically a feature of SharePoint Designer, there is a new feature for 2010 and I believe it is worth mentioning: Workflows in 2010 do not have to run on a single list item or document. The new Document Set feature of SharePoint Server 2010 allows you to bundle together different types of documents into groupings that make sense for your business. Rather than having to run a workflow on each individual document within the set, you can now run a single workflow on the entire Document Set.