Secure your REST-based WCF service with WIF, part 2

This is the second post in a series of blog posts on how to secure REST-based services built on WCF and ASP.NET. One possible use case would be that we are hosting an OAUTH resource server where a third-party client has been issued a token by an authorization server with the approval of the resource owner (user) and that the client uses this token to access the protected resources inside our service.

In part 1 the scene was set  by enabling WIF with a little help of a custom HTTP module. The module grabs the SAML token from the incoming request’s authorization header and hands it over to WIF, which in turn does its token validation job.

But how does WIF know what to do with the incoming SAML token? Well it doesn’t, not unless we tell it what to do. So this can be done programmatically or through configuration (or a combination of both).
In this case we will initialize the WIF configuration programmatically by giving it a reference to a service configuration element specified inside the web.config file (shown shortly). For this we first need to create a class that inherits from ServiceConfiguration:

With this class in place we can get a hold of the WIF configuration from inside the WIfEnablingModule defined in part 1

… and use it the way we did in the AuthenticateRequest method.


If we now shift our focus to the actual configuration part inside the web.config file, we first need to register the WIF configuration section:

And our WIF section goes like this:

By specifying an audienceUri as above we require the SAML token to contain a matching URI. That way we know that the token was indeed meant for our RP (relying party).

Next we use the built-in ConfigurationBasedIssuerNameRegistry which takes care of the heavy cryptographic work, validating the token’s digital signature against a list of trusted issuers (or their matching public keys that is). In this case we only have one. 

We also make use of the built-in Saml2SecurityTokenHandler which handles the deserialization from the SAML 2.0 assertion into a Saml2SecurityToken CLR object, validates it, checks that it has not yet expired and so on, and while it’s at it, also transforms the security token object into a ClaimsIdentityCollection.

Ok so now that we have the set of claims that corresponds to the assertion of the incoming token it’s up to us what we want to do with it. We can for example call a custom claims store to add some more claims to the collection or perhaps delete certain identifying claims that should not be passed all the way to the RP. It’s really up to the requirements at hand.

The way we can do this is by creating a customized ClaimsAuthenticationManager, and call its Authenticate method, which we pass the claims collection. This is exactly what the next configured element in our WIF section is, the CustomClaimsAuthenticationManager above. (See also the AuthenticateRequest method in part 1 on how to use it).

The next step in the WIF pipeline is to authorize (or deny) the incoming request before the claims finally are handed over to the RP. For this purpose we have configured the CustomClaimsAuthorizationManager that inherits ClaimsAuthorizationManager.

Summary: The focus of this post has been on how we can initialize the WIF configuration through code and configure the WIF pipeline through the microsoft.identityModel configuration section.

In the next post we will look closer on the implementation of the CustomClaimsAuthenticationManager and CustomClaimsAuthorizationManager classes. We will also go ahead and implement a simple REST service and a test client to try it all out.

This Post Has 5 Comments

  1. Good stuff! Can’t wait for part 3 :)

  2. Thanks Stefan for putting this together. I look forward to reading part 3…

  3. Where is part 3??? :(

  4. Hi,

    Can you please tell me from where i can download it?

Leave a Reply

Close Menu