Claims Based Authentication - SharePoint and generally

All,

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).

My understanding of various pieces of technology terminology is as follows:

• WIF (Windows Identity Foundation) - a .NET library (set of APIs) that are used for consuming Identity Claims and building custom STSs etc.

• Relying Party - a 'Consumer' of Claims (i.e. SharePoint, ASP.NET Web Site etc.). Claims are provided through an STS (an IP-STS only?).

• 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?

  • RP-STS (Relying Party Security Token Service)
  • IP-STS (Identity Provider Security Token Service)

• Trusted Identity Provider (SharePoint terminology) - AKA. IP-STS.

• 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.

• 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.

• 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.

SharePoint 2010/2013 questions:

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 replacing the built-in SharePoint 2010/2013 STS with ADFS 2.0! This is hopefully just my reading, but it confused my understanding.

1. 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?
2. Why WOULD you want to do this?

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.

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?

Statements:

• 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.
• 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.

ASP.NET WIF questions:

1. 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?
2. 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?

Just writing this helped me get this out of my head, but any help on inaccuracices/over simplications/outright untruths would be gratefully appreciated!

Regards,

Michael Taylor

The SP STS is an RP-STS i.e. it does not have a credential store to authenticate against. That's why you have to federate it with ADFS which is an IP-STS i.e. it authenticates against an AD in it's domain.

ADFS can be either an RP-STS or an IP-STS e.g. you could have the path - SP app. -> SP STS -> ADFS (RP) -> ADFS (IP) -> AD.

The IP-STS you 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 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. The SP RP-STS only supports WS-Fed.

The previous version of ADFS (i.e. 1.0) is the version that is installed on Windows Server 2008. You have to download ADFS 2.0. Unfortunately, there are a number of blog posts which uses the term ADFS but which refer to ADFS 1.0. Beware - ADFS 1.0 is a completely different beast.

WIF is just a set of .NET classes. It is not an STS. You can go WIF -> IP-STS or WIF -> RP-STS -> IP-STS etc.

Hopefully this answered some of your questions but fire away if anything is still not clear.

Update:

The only STS's I know of that incorporate WIF are ADFS and IdentityServer. Most of the ones mentioned above are Java based.

The reason that you would choose ADFS over IWA is that both authenticate against AD but only ADFS adds SSO and Federation functionality. Also ADFS provides all the claims-based plumbing - SAML token etc.

When you federate ADFS, you provide the ability to authenticate against multiple credential stores. But if you choose to authenticate against an instance of ADFS, it uses the AD repository. When you install ADFS it finds the instance of AD in its domain. That's the one it uses.