Share via

SharePoint 2010: Claims Authorization and Authentication in SOA-Based Architecture

  • Article

Role Management system in SharePoint 2010 and SOA based architecture.

Let start with some of the challenges we faced in any organization if there is a role based access to any system in an organization. Whether the system is CRM, legacy, Stand alone applications, portals etc.

Every system has there one roles and ways to manage those roles. Every systems/tools manages the roles in their own way and pages/forms are accessible to the user based on their roles.  

Real challenge here is how we can have signal system in place which will manage roles from single source and every system will get authorizations based on these roles. How Sync between exiting systems and this system should happen.

Let’s take some real business and technical requirements/challenges:

·         How to provide Role synchronization for different systems? 1 System will get different roles from different system like CRM, TMS, portals etc. How these roles will be managed, if we create AD Hierarchy for these roles in each department. How we can provide synchronization between roles of 1 system with multiple system?

·         How you will provide role based access to the Services if you have SOA enabled architecture?

·         Inefficient request processes result in prolonged waiting time for business user requesting access rights to SharePoint sites?

·         Difficult to enforce governance policies and administration procedures using SharePoint Groups?

·         How to handle maximum users in each Role (Group)? What if users on one roles grows more then 40,000 and many more.

With the SharePoint groups we realize that one SharePoint group (Like “Contributor”) will have limitations to handle 15,000 + users. Transactions and access to the SharePoint sites will some time crash. If we manage this using AD groups, this limitations can be avoided. However still does it make sense to create so many roles in AD and provide transactions to the AD group? I sure it is not.

With SharePoint there are three ways to handle roles:

1.       SharePoint Groups

2.       AD Groups

3.       Claim based authorization

SharePoint’s security boundaries are of four ways –

  •  Individual User: From any system perspective, giving individual permissions is not feasible, considering the amount of users it has.
  • SharePoint Group
  • Active Directory (AD) Group.
  • Claim based Authorization

Claim based authorization: This feature is really new and it is more flexible to use. In your organization if roles are handled differently then claims can be created for those roles and login user (Windows or form based) can get access to the sites, sources based on this claims. Further at the SharePoint items level, folder level, Web parts level permission can be assigned based on this role.

There all real time business scenarios which can be handled using Claim based authorization.  

  • Providing role based access to different systems in an organization based on claims.
  • Providing role based access to the Services if you have SOA enabled architecture
  • Syncing between multiple ((like CRM, Task Management, PeopleSoft, SAP etc) role based system in an organization. In any system with different groups and hierarchy.

SharePoint 2010 claims:

SharePoint Claims can be created by writing custom claim provider to create claims for all roles defined in different system and provide access to the Site based on this claims. Existing restricted Roles can be migrated to Claims in SharePoint i.e. only those roles which are really required by SharePoint UI.

Claims provider in SharePoint 2010 is can be used for to do claims augmentation (adding more attributes to claims) and to provide name resolution. 

Web Service vs Claims based authorization:

Same way Web service access can also be made restricted based on roles. And these roles can be claims created using claims provider. One layer of security i.e. role based access can be provided to the Web services.

  1. Generally people do have technical requirements on integration of SharePoint/ASP.NET portal with SAP, PeopleSoft application.
  2. Integration can be done safely using SOA based architecture by exposing Web services to talk to a legacy applications like SAP, PeopleSoft etc.
  3. Here security plays a vital role if call is going through Web service to the legacy application.
  4. Claims can play vital role to provide claims based access to these legacy system using Web service

 

Claims - Process flow

Figure below shows the process flow diagram for claims implementation.

 

 

Figure 1 Activity flow for claims

1.       Step 1(Authentication): User enters credentials(Form/Windows)

2.       Step 2: Claims policy will be fetched for the user belongs to particular role(claim)

3.       Step 3: Security Token service will provide the assertions for the claims(augmentation)

4.       Step 4: Token is passed and claim is authorized

5.       If user has access to the claims, then user will be redirected to the requested page/resource

Implementation steps for claims in SharePoint 2010

You need to perform following implementation activities to provide claims in SharePoint.

1.       Create Claim provider

2.       Consumed services in claims (if claims are required to be fetched from different systems).

3.       Populate claims inside SP People Picker

4.       At Web application given permissions depends on claims 

Objective Create Provider class for generating claims
  Design

1.       Create custom class that inherits from SPClaimProvider class.

2.       To add claim in SharePoint for login user, need to implement FillClaimsForEntity method, this method will consume the RHMS service and retrieve roles and this roles acts as claim in SharePoint.

3.       To Populates all the claims in People picker, need to implements FillSearch method, this method fetch all the roles from RHMS and show in people picker depend on search criteria.

4.       To resolve all the claims in People piker, need to implements FillResolve method, this method fetch all the roles from RHMS and show in people picker depend on search criteria.

5.       Link for claim based implementation http://myspserver:8587/sites/CRM/Pages/HRWorkspace2.aspx

Custom Claim provider Class Diagram:
Alternative Design N/A
Assumptions (specific to this use case) Used roles in RHMS as claims
Challenges Converting exiting Classic mode Web App to the Claim based Web App

 

Claims in Landing Portal / Root site collection:

Following are few sample claims gets created for portal. Claims in few Site Collections:

·         CRM Site Collection

o   HR_Employee_Administrator  – Contains HR Employee with Full permission

o   HR_Employee_Contributor  – Contains HR Employee with Contribute permission

o   HR_Employee_Reader  – Contains HR Employee with Read permission

o   HR_NewHire_Administrator  – Contains HR NewHire with full permission

o   HR_NewHire_Contributor  – Contains HR NewHire with Contribute permission

o   HR_NewHire_Reader  – Contains HR NewHire with Read permission

 

To add Claims to SharePoint in CRM site collection, site admin has to do following:-

1.       Click on Site Actions àSite Settings àPeople and Groups

2.       Select the appropriate claims HR/BFS

3.       Click on New àAdd Users to Group

4.       Give Appropriate Permissions