Summary: Learn how to dynamically assign claims to users in a WCM application such as when the user authorization model is being fully driven through business logic.

Applies to: Microsoft SharePoint Foundation 2010 | Microsoft SharePoint Server 2010

Contributors: Sanjay Arora, Pareshkumar Manjibhai Moradiya

The security in Forms Based Authentication (FBA) based WCM Web Applications is generally implemented using one of the following approaches:

  • The user is directly assigned to a SharePoint Security group(s) or through active directory groups, and then these Security Groups secure the content by using different permission levels. This approach requires that the administrator perform maintenance tasks to assign or un-assign users to or from the correct security group or active directory groups.
  • The user is directly assigned to the content with different permission levels. Although not the best approach, it is still used occasionally.
  • Another, rarely used, approach is to have specific roles assigned to the user through a role provider and then use these roles to grant privileges to the user.

This article extends the last approach; it eases administration by getting rid of the daily task of managing users in each and every security group or active directory group. This approach means that the user does not have to be added to a security group and that role(s) need to be assigned to the respective security group(s) only once. In addition, these roles can be dynamically assigned to users based on specific business logic. Thus, when a user logs into the application, based on specific business logic, the role for a user is determined and thereafter the applicable roles are assigned to users in the form of claims. And as roles have already been assigned to security groups, by virtue of that assignment, the user authorization is mapped to a security group.

Let us look at a specific scenario: Lucerne Publishing, an online book store, enables customers to download eBooks from their new WCM site built on SharePoint 2010. The business model that they use enables customers to pay for a class of subscription and then, based on the type of subscription, these digitally signed books are available for download. The book’s availability under various types of subscriptions changes based on various internally defined parameters and business rules.

To implement this requirement, you normally follow the model of adding users to various security groups, and thereafter, every time the subscription level of a customer changes, you change the security group of the customer. Additionally, whenever a book’s availability under a subscription type is changed, you change the security group securing the document. This approach has one major drawback however; it may not scale well because of limitations of security principals; approximately 5,000 per ACL (Access Control List) on any securable object’s scope. Thus, you will not be able to assign more than 5000 customers to a security group.

You can easily work around the limitations by following a different approach, as outlined previously in this article. In the suggested approach, whenever the availability of a book under a specific type of subscription changes, only the security group assigned to the book needs to be changed. The customer is assigned a role during login based on the subscription level of the user and, rather than adding the customer to the security group, you add only the role, for a specific subscription type, to the security group. This also removes the need to physically manage a customer’s security group based on the subscription type. This approach provides additional flexibility in the subscription level (read role) of a customer, driven fully through underlying parameters.

To summarize, this approach offers following benefits:

  • The authorization is fully driven through business logic, which implies that as soon as the underlying data for business rule changes, the user authorization will change immediately.
  • This approach requires less maintenance as it does not require explicitly maintenance of users in SharePoint, as long as the security group or groups have been assigned a role.
  • It is a scalable approach. It assigns users dynamically to a security group by virtue of a role, and prevents SharePoint from exceeding the following boundaries:
  • Number of SharePoint groups a user can belong to – max value 5000
  • Users in a SharePoint group - 5,000 per SharePoint group

Note: Given the dynamic nature of this authorization model, it is critical that the role provider logic be optimized and when a user logs into the system, the role assignment is performant. This can be achieved through multiple approaches; the key idea is to have an interim store (a user profile) which is updated periodically to optimize the login process.