title: Claims Based Authentication - SharePoint and generally
body: <p>All,</p>
  
  <p>I've been doing a lot of reading around Claims Based Authentication and am still a bit confused. I'm trying to solidify my understanding, specifically relating to SharePoint 2010/2013, but also generally (i.e. ASP.NET).</p>
  
  <p>My understanding of various pieces of technology terminology is as follows:</p>
  
  <ul>
  <li><p>WIF (Windows Identity Foundation) - a .NET library (set of APIs) that are used for consuming Identity Claims and building custom STSs etc.</p></li>
  <li><p>Relying Party - a 'Consumer' of Claims (i.e. SharePoint, ASP.NET Web Site etc.). Claims are provided through an STS (an IP-STS only?).</p></li>
  <li><p>STS (Security Token Service) - a specialised Web Services that issues security tokens. Comes in two flavours, and some STSs are possibly both flavours at the same time?</p>
  
  <ul>
  <li>RP-STS (Relying Party Security Token Service)</li>
  <li>IP-STS (Identity Provider Security Token Service) </li>
  </ul></li>
  <li><p>Trusted Identity Provider (SharePoint terminology) - AKA. IP-STS.</p></li>
  <li><p>SharePoint 2010/2013 STS - an SharePoint Service Application developed using WIF that acts as an RP-STS only. Acts as a pluggable aggregation point for a number of user configurable Trusted Identity Providers (IP-STSs). These could be hand built using WIF if required.</p></li>
  <li><p>ADFS 2.0 - a Windows role designed specifically for federating an orgnanisation against an Active Directory instance only. Exposes an IP-STS endpoint built using WIF. My understanding of ADFS 2.0 is that it doesn't allow you to 'aggregate' other Identity Providers - it just allows you to authenticate against a specific AD instance that may not be local to you and therefore needs to be federated in order to support SSO.</p></li>
  <li><p>Windows Azure ACS 2.0 - a service specifically for federating any configured third-party Identity Providers (i.e. Microsoft account, Google, Facebook, ADFS 2.0). Acts as a pluggable aggregation point for other Identity Providers for which it acts a bit like a Relying Party. Exposes an IP-STS endpoint built using WIF. The Identity Providers it aggregates are not necessarily IP-STSs but ACS 2.0 exposes everything through Claims using its built-in IP-STS.</p></li>
  </ul>
  
  <p>SharePoint 2010/2013 questions:</p>
  
  <p>My main issue is that I have seen a few articles talking about ADFS 2.0 and SharePoint which almost read as if you are <em>replacing</em> the built-in SharePoint 2010/2013 STS with ADFS 2.0! This is hopefully just my reading, but it confused my understanding.</p>
  
  <ol>
  <li>Can you actually do this? I see no reason why you couldn't if you really wanted, but I assume you need to disable the SharePoint STS and do lots of manual config?</li>
  <li>Why WOULD you want to do this?</li>
  </ol>
  
  <p>2.1. AD authentication is already supported as an OOTB Trusted Identity Provider option by the SharePoint STS and if you wanted to use ADFS 2.0 instead you could just add this in as a Trusted Identity Provider (IP-STS) for which I have seen blog posts.</p>
  
  <p>2.2. Based on my description of ADFS 2.0, changing it out for the SharePoint STS would actually give you a less flexible solution?</p>
  
  <p>Statements:</p>
  
  <ul>
  <li>You can configure the SharePoint STS to use ADFS 2.0 a a Trusted Identity Provider (IP-STS), as well as, or instead of local AD.</li>
  <li>You can configure the SharePoint STS to use Windows Azure ACS 2.0 a a Trusted Identity Provider (IP-STS). This would make it very easy to support third-party authentication providers without developing your own IP-STS using WIF.</li>
  </ul>
  
  <p>ASP.NET WIF questions:</p>
  
  <ol>
  <li>My understanding is that in order to perform the trust negotiation and claims exchange an RP-STS must talk to an IP-STS. Is this correct? </li>
  <li>Therefore in the context of building a claims-based ASP.NET Web Application (Relying Party) when using WIF would you therefore have develop/reuse and include an RP-STS into the App and cnfigure this to have a trust relationship with an IP-STS? If not can you get Identity directtly from an IP-STS using WIF?</li>
  </ol>
  
  <p>Just writing this helped me get this out of my head, but any help on inaccuracices/over simplications/outright untruths would be gratefully appreciated!</p>
  
  <p>Regards,</p>
  
  <p>Michael Taylor</p>