When Visual Studio 2013 came out, it introduced a new class and simplified methods for obtaining a ClientContext to use with the Client Side Object Model (CSOM) to access SharePoint 2013 sites.  A new SharePointContext class was added to simplify the programming model, but internally it still called the TokenHelper class that originally shipped with Visual Studio 2012. 

Shortly after SharePoint 2013 shipped, I provided an additional class – the ClaimsTokenHelper class – to be used when your SharePoint sites are secured using SAML authentication (http://blogs.technet.com/b/speschka/archive/2013/07/23/3539509.aspx).  Neither the original TokenHelper class nor the new SharePointContext class provides a means to properly identify a SAML claims user.  I decided to take a fresh look at the ClaimsTokenHelper implementation and see if I could find a way to update things to keep it more closely aligned with the development model used in the new SharePointContext class.  What I ended up doing is creating a new SharePointContextExtensions class, and it allows you to use virtually the same exact programming model as you do now with the SharePointContext class. 

Here’s an example of the code you use to access a site title using the SharePointContext class:

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);

using (var clientContext =

spContext.CreateUserClientContextForSPHost())

{

clientContext.Load(clientContext.Web, web => web.Title);

clientContext.ExecuteQuery();

Response.Write(clientContext.Web.Title);

}

Now, here’s an example of using the new SharePointContextExtensions class:

var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);

using (var clientContext =

               spContext.CreateUserClientContextForSPHost(TokenHelper.IdentityClaimType.SMTP))

{

clientContext.Load(clientContext.Web, web => web.Title);

clientContext.ExecuteQuery();

Response.Write(clientContext.Web.Title);

}

As you can see, literally the only difference between the two now is that you need to specify which OAuth identity attribute you want to use as the identity claim – SMTP, SIP, or UPN.  Also, there is a corresponding method for getting a ClientContext for an App Only token.  Here’s the out of the box syntax:

spContext.CreateAppOnlyClientContextForSPHost();

And here’s the corresponding method when using SAML:

spContext.CreateAppOnlySamlClientContextForSPHost();

In this case I had to actually change the method name, because it would otherwise have the same exact method name and signature as the SharePointContext class.  I’ve attached the SharePointContextExtensions and ClaimsTokenHelper classes to this posting.  Using them is pretty straightforward:

1. Add both classes to your project
2. Change the “namespace” declaration at the top of each class to match the namespace you are using in your project.
3. As with the original ClaimsTokenHelper class you also need to do the following; you can find more details on both of these steps in the original blog post at http://blogs.technet.com/b/speschka/archive/2013/07/23/3539509.aspx#pi47623=1:
   1. Add the “partial” modifier to the TokenHelper.cs class that Visual Studio adds to your project, i.e. it should read public partial class TokenHelper. 
   2. Add the “TrustedProviderName” property to your appSettings section in web.config and put in the name of your SPTrustedIdentityTokenIssuer as the value.
   3. Start coding.

That’s it – you should be up and running in no time!