Claims Based Authentication, Item Based Permissions & Managed Metadata Solution

What I used for my project is ‘Claims Augmentation’ which means that for my authentication provider I still use AD accounts. These accounts however are enriched with user-specific claim information on the moment they log in on the SharePoint website. After that it is possible to base your security on the augmented claims.

Claims Augmentation

In my project ‘Case management’ plays an important role. I have created a Document Library and in that document library Document Sets are created of which each represents a different case. The most important aspect of these cases is that they are all of a certain type. Some users should have only access to cases of type 1, some users should only have access to cases of type 2 and some users should have access to both type 1 and 2. You get the picture 

View of the Document Library

My solution is to use Item based security combined with claims based authentication. In my solution the claims are based on all possible case types. So for every case-type, there is a corresponding claim. On the moment of Document Set creation I break the role inheritance of the item (which is the Document Set), delete all other role assignments and add the role assignment of the claim that corresponds with the case-type. After that only users who possess the same Case-type claim have access to the Document Set and the underlying documents.

Item based permissions for documentset 1001 (Dutch language pack...)

Remains the problem where I keep my list with all possible case-types (which is of course the same list that produces the claims). I decided to use Taxonomy feature of the Managed Metadata service for that. So now both the Case-type taxonomy metadatacolumn of my Document Set and the custom claims provider gets their list of claims/case-types from the Managed Metadata Service.

Taxonomy termset for casetypes and claims

The custom claims provide uses a sql server table to determine which user has which claims. This table is queried each time a user logs in on the SharePoint website. It has a very simple structure with only 2 columns: username and claim.

The complete solution looks like this:

Solution overview

More Here

Courtesy:http://robertsep.wordpress.com/2011/01/16/claims-based-authentication-item-based-permissions-managed-metadata-solution/

Connecting to SharePoint with Claims Authentication

In a nutshell, the process of connecting to SharePoint happens like this; Make a request, re-direct to an STS for login, post token from login to SharePoint’s STS (‘_trust’ site), post token from SharePoint’s STS to SharePoint, and then capture and store the ‘FedAuth’ cookie generated by the site. Then and only then, can you start accessing the data from the site by providing the ‘FedAuth’ cookie. The diagram below outlines the process in a slightly more detail…




The new SharePoint Client objects accessing SharePoint and most of its information much easier than before. Unfortunately; they are new, and new things have very little support. Fortunately, this fact didn’t keep us from long hours with Microsoft Tech Support (naturally calling me back right as I was about to walk out the door).


Now on to the good stuff…


The primary component of using the SharePoint Client objects is the ClientContext class. This class manages all of the interaction with your application and the SharePoint site. You tell the ClientContext what you want it to do and then tell it to execute. All-in-all, it makes the code much cleaner when pulling information from SharePoint.



Instead of muddying up my code, I decided to extend the ClientContext class and make it able to connect to a Claims-based site on its own. The key to extending the class, was in utilizing the ‘ExecutingWebRequest’ event. Here is where I was able to do all of my work and setup the connection with SharePoint.


But; before I continue, one warning. This is beta code and should be used at your own risk. I currently only having it working by retrieving authentication by impersonating the local context. So, it will not pass on any Claims Based credentials if used from a website (Windows Identity Foundation).


If anyone reading this can figure out a clean way to pass on the user’s token, please let me know. Thanks!
view source
print?
001 using System;
002 using System.Linq;
003 using System.Net;
004 using System.Net.Security;
005 using System.Security.Principal;
006 using System.ServiceModel;
007 using System.ServiceModel.Channels;
008 using System.Text;
009 using System.Web;
010 using System.Xml;
011 using Microsoft.IdentityModel.Protocols.WSTrust;
012 using Microsoft.SharePoint.Client;
013
014 namespace SharePointLibraries
015 {
016 public class ClaimsClientContext : ClientContext
017 {
018 // store this info at the class level for access by the ExecutingWebRequest event
019 private string SharePointRootUrl
020 {
021 get
022 {
023 // return (new Uri(_sharePointSiteUrl)).GetComponents(UriComponents.Scheme | UriComponents.Host, UriFormat.SafeUnescaped).ToString();
024 var siteUri = (new Uri(_sharePointSiteUrl));
025 return string.Format("{0}://{1}/", siteUri.Scheme, siteUri.Host);
026 }
027 }
028 private string _sharePointSiteUrl;
029 private string SharePointSiteUrl
030 {
031 get { return _sharePointSiteUrl.EndsWith("/") ? _sharePointSiteUrl : _sharePointSiteUrl + "/"; }
032 set { _sharePointSiteUrl = value; }
033 }
034 public string SharePointSiteRealm { get; set; }
035 private string _loginStsUrl;
036 private string LoginStsUrl
037 {
038 get { return _loginStsUrl.EndsWith("/") ? _loginStsUrl : _loginStsUrl + "/"; }
039 set { _loginStsUrl = value; }
040 }
041
042 // store the Saml token so that it can be used by successive requests
043 private static string IssuedSamlToken { get; set; }
044 private static DateTime IssuedSamlTokenExpireDate { get; set; }
045
046 ///

047 /// Public constructor for all three being strings
048 ///

049 ///
050 ///
051 ///
052 public ClaimsClientContext(string sharePointSiteUrl, string sharePointSiteRealm, string loginStsUrl)
053 : base(sharePointSiteUrl)
054 {
055 if (sharePointSiteUrl == null) throw new ArgumentNullException("sharePointSiteUrl");
056 if (sharePointSiteRealm == null) throw new ArgumentNullException("sharePointSiteRealm");
057 if (loginStsUrl == null) throw new ArgumentNullException("loginStsUrl");
058
059 // save the settings
060 SharePointSiteUrl = sharePointSiteUrl;
061 SharePointSiteRealm = sharePointSiteRealm;
062 LoginStsUrl = loginStsUrl;
063
064 // specify the default credentials to use
065 Credentials = CredentialCache.DefaultCredentials;
066
067 // add a handler for the ExecutingWebReques event to provide the SAML token
068 // this.ExecutingWebRequest += new EventHandler(ClientContext_ExecutingWebRequest);
069 ExecutingWebRequest += ClientContext_ExecutingWebRequest;
070 }
071
072 ///

073 /// Public constructor for Site Url being a Uri
074 ///

075 ///
076 ///
077 ///
078 public ClaimsClientContext(Uri sharePointSiteUrl, string sharePointSiteRealm, string loginStsUrl)
079 : base(sharePointSiteUrl)
080 {
081 if (sharePointSiteUrl == null) throw new ArgumentNullException("sharePointSiteUrl");
082 if (sharePointSiteRealm == null) throw new ArgumentNullException("sharePointSiteRealm");
083 if (loginStsUrl == null) throw new ArgumentNullException("loginStsUrl");
084
085 // save the settings
086 SharePointSiteUrl = sharePointSiteUrl.ToString();
087 SharePointSiteRealm = sharePointSiteRealm;
088 LoginStsUrl = loginStsUrl;
089
090 // specify the default credentials to use
091 Credentials = CredentialCache.DefaultCredentials;
092
093 // add a handler for the ExecutingWebReques event to provide the SAML token
094 ExecutingWebRequest += ClientContext_ExecutingWebRequest;
095 }

More Here

Courtesy:http://fredericloud.com/2011/01/11/connecting-to-sharepoint-with-claims-authentication/

Leverage and Extend Claims based identity in SharePoint 2010

Windows Identity Foundation (WIF) is the platform on which SharePoint 2010 claims authentication is based. WIF, which is fully supported in SharePoint 2010, ADFS 2.0, ASP.NET, Windows Communication Foundation (WCF), and any other .NET application you care to develop, provides the infrastructure necessary to generate, transmit, and process claims-based identity in a simple and straightforward manner. It removes the roadblocks imposed by legacy authentication schemes like NTLM and Kerberos and puts control directly into the hands of developers, users, and IT security professionals. long story short, it’s a framework written to help solve identity issues common in the of cloud computing and service-oriented architecture.


The idea of claims based identity is one that many people are willing to try. Getting accurate information out there to the public though does take time.

The important point is this is based on industry standards. Many different entities are on board along with Microsoft in this matter. The digital world continues to give us new opportunities and those involved believe that this will help all of us to get the most out of it. There is a strong foundation in place to continue building upon. The use of AD FS v2, CardSpace, and Windows Identity Foundation are all important pieces of this puzzle.


As a demonstration of these capabilities, I’ll show how SharePoint 2010, WCF,and WIF can be put together to solve the identity delegation problem. In this demo session part 1 I start establishing the trust relationship between ADFS 2.0 and SharePoint with PowerShell and demonstrate how the claims get into SharePoint.Then we build and deploy a claims viewer Webpart with WIF programming model. In part 2 We start with a web service that is front-ending line-of-business information stored in a SQL database. Then, we’ll configure it to use WIF to request the calling user’s claims from SharePoint and process the token so that authorization decisions can be made. we’ll surface this information in SharePoint 2010 as an External Content Type using Business Connectivity Services (BCS).

More Here

Courtesy:http://sptechpoint.wordpress.com/2010/11/23/whats-new-in-sharepoint-2010-security/