SharePoint 2010 Claims and SAML

  • Security Token Service (STS): A specialized Web Services that issues security tokens.
    • RP-STS (Relying Party Security Token Service)
    • IP-STS (Identity Provider Security Token Service)
  • Relying Party: A ‘Consumer’ of Claims (i.e., SharePoint, ASP.NET, Web Site, etc.). Claims are provided through an STS (IP-STS only)
  • Windows Identity Foundation (WIF): A .NET library (set of APIs) that are used for consuming Identity Claims and building custom STSs, etc.
  • WIF is just a set of .NET classes. It is not an STS. We can go WIF -> IP-STS or WIF -> RP-STS -> IP-STS
  • SharePoint 2010/2013 STS: SharePoint Service Application developed using WIF that acts as 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.
  • The SP STS is RP-STS i.e. it does not have a credential store to authenticate against. That’s why we have to federate it with ADFS which is IP-STS i.e. it authenticates against an AD in its domain.
  • ADFS 2.0: A Windows role designed specifically for federating an organization against an Active Directory instance only. Exposes an IP-STS endpoint built using WIF. It doesn’t allow to ‘aggregate’ other Identity Providers – it just allows to authenticate against a specific AD instance that may not be local therefore needs to be federated in order to support SSO.
  • AD authentication is already supported as an OOTB Trusted Identity Provider option by the SharePoint STS and if we wanted to use ADFS 2.0 instead we could just add this in as a Trusted Identity Provider (IP-STS)
  • We can configure the SharePoint STS to use ADFS 2.0 a Trusted Identity Provider (IP-STS), as well as, or instead of local AD.
  • ADFS can be either RP-STS or IP-STS. i.e., SP App. -> SP STS -> ADFS (RP) -> ADFS (IP) -> AD.
  • ADFS can be federated with many different IP-STS. The user can choose which one to use for authentication.
  • ADFS supports both SAML2 and WS-Fed as federation protocols. SP RP-STS only supports WS-Fed.
  • The only STS’s that incorporate WIF are ADFS and IdentityServer. Others are Java based.
  • When we federate ADFS, we provide the ability to authenticate against multiple credential stores. But if we choose to authenticate against an instance of ADFS, it uses the AD repository. When we install ADFS it finds the instance of AD in its domain. That’s the one it uses.
  • Windows Azure ACS 2.0: A service specifically for federating any configured third-party Identity Providers (i.e. Microsoft account, Google, Facebook and 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.
  • We can configure the SharePoint STS to use Windows Azure ACS 2.0 a Trusted Identity Provider (IP-STS). This would make it very easy to support third-party authentication providers without developing our own IP-STS using WIF.
  • The IP-STS we federate with SP does not have to be ADFS – it can be anything that supports the WS-Federation protocol e.g. OpenAM, PingIdentity, Azure ACS. The main point is that at the end of the chain there has to be a credential store to authenticate against. This credential store does not have to be AD e.g. ADFS -> IdentityServer -> SQL Server.
  • ADFS and IWA: both authenticate against AD but only ADFS adds SSO and Federation functionality. Also ADFS provides all the claims-based plumbing – SAML token etc.
  • Never CHANGE the SharePoint RP-STS out for ADFS 2.0 running as an STS-RP. Never this: (Remove SP STS) SP app -> ADFS (RP-STS) -> Whatever Always something like this: SP app -> SP STS -> ADFS/ACS/OpenAM
  • ADFS 2.0 STS is built using WIF code. To perform the trust negotiation and claims exchange, RP-STS must talk to IP-STS.
  • Building a claims-based ASP.NET Web Application, i.e., Relying Party, using WIF, have develop/reuse and include an RP-STS into the App and configure this to have a trust relationship with an IP-STS. If not, we get Identity directly from an IP-STS using WIF.Like Azure ACS 2.0, ADFS 2.0 also used to federate against more IP-STSs.