Follow us on Twitter
Follow us in Facebook
Office Dev Content
SharePoint Dev Content
Blogs for Office developers > SharePoint dev blog
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:
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:
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.