Create a custom WS-Federation Identity Provider using a WCF service

Question

This relates to, but I'm quite sure does not duplicate, my question: Looking for a secure and robust STS implementation

Since asking that, some input from business, and some research, has led me to believe that instead of implementing a secure token service to wrap my custom identity provider, I can delegate the issuing of tokens to the identity provider itself.

The identity provider is a WCF service that returns a collection of claims when it successfully authenticates a user, based on some identifying data for the user. E.g.

[ServiceContract(Namespace = "http://namespace")]
public interface IIdService
{
    [FaultContract(typeof(IdServiceFault))]
    [OperationContract]
    ICollection<Claim> Authenticate(string idDatum1, string idDatum2);
}

where Claim is Microsoft.IdentityModel.Claims.Claim. I am currently stuck with a an example only quality STS implementation, as a web site project, but if at all possible, I would like to simply move the task of issuing and signing tokens into the identity provider, and eventually qualify it as a WS-Federation Identity Provider, that I can later include in my Azure Access Control's providers.

If this is possible, what do I need to do in the WCF service?

Answer 1

"One doesn't just knock together a WS-Federation Identity Provider" - there are a lot of necessary complexities involved, mostly to ensure the security, integrity and provability of the claims being asserted.

You do NOT want to get this stuff wrong - look at what happened at Target, Home Depot, Sony and others of late!

I strongly encourage you to read and re-read Michele Leroux Bustamante's "Building A Custom Security Token Service" article until you thoroughly understand the role of an STS and the various complexities involved in doing so.

Note that in order to build a secure STS you'll need to support SAML, WS-Security, WS-Trust, WS-Federation and use SSL for secure transport of tokens and data. You'll need to carefully implement the various stages of the communication protocol necessary to permit the federation of identity information.

Once you've deeply grokked the subject matter, you'll have a much better understanding of why it's likely a good idea to build an STS as a façade service that sits alongside/in-front-of your existing Identity service - rather than "pollute" your existing service with the considerable complexities involved in building an STS.

If this all seems like a heck of a lot of work, it is (and it should be - security is really, REALLY hard!).

I would strongly recommend you consider using Thinktecture's Identity Server instead of building your own. The awesome Dominick Baier & team have done an awesome job of building a robust, well engineered, open-source Identity Server that supports WS-Fed as well as OpenID, OAUTH, etc.