One missing piece in Katana security/authentication is claims transformation. Fortunately, this is easy to add:
public class ClaimsTransformationMiddleware : OwinMiddleware
{
ClaimsAuthenticationManager _claimsAuthenticationManager;
public ClaimsTransformationMiddleware(
OwinMiddleware next,
ClaimsAuthenticationManager claimsAuthenticationManager)
: base(next)
{
if (claimsAuthenticationManager == null)
{
throw new ArgumentNullException(“claimsAuthenticationManager”);
}
_claimsAuthenticationManager = claimsAuthenticationManager;
}
public override Task Invoke(IOwinContext context)
{
if (context.Authentication.User != null)
{
context.Authentication.User =
_claimsAuthenticationManager.Authenticate(
context.Request.Uri.AbsoluteUri,
context.Authentication.User);
}
return Next.Invoke(context);
}
}
This leverages the .NET built-in ClaimsAuthenticationManager class. The corresponding AppBuilder extension method would look like this:
public static IAppBuilder UseClaimsTransformation(
this IAppBuilder app,
ClaimsAuthenticationManager claimsAuthenticationManager)
{
app.Use(typeof(ClaimsTransformationMiddleware), claimsAuthenticationManager);
return app;
}
And last but not least, this is how you would wire it up in the Katana pipeline:
app.UseClaimsTransformation(new ClaimsTransformer());
Place the claims transformation middleware after all your authentication middleware. This will allow it to see all identities.
The full sample can be found here.
leastprivilege.com 
I ran into some issues with ‘context.Authentication.User != null’ the other day and wanted to share, if the identity have not been set, then Authentication.User throws an exception. I took it from the Request.User instead. Let me know if this is not a problem for you and i have revise my code.
Not sure – I had Microsoft review it and they said it is OK.
Pingback: OWIN Claims Transformation Middleware–Take 2 | www.leastprivilege.com
Hi Dominick,
Would this get executed on each request?
The WIF implementation (from memory) executed the ClaimsAuthenticationManager after the user was authenticated but before the cookie token was written in the response. This meant that claims augmentation was only executed once when the user was logged in rather than for each request.
Cheers,
Rory
This implementation gets called on each request. It was primarily made for Web API scenarios where you don’t have cookies. So you need to do your own caching.
Thanks, that makes sense. I have another question. Can you get web api with OWIN to support multiple authentication types?
In my scenario, the web api is consumed via javascript/ajax for which the user is already authenticated and the cookie token is passed to the api.
I also want the same api to be consumed directly by an external client. In this scenario the client would require some other authentication mechanism and presumably a different token type. In my specific scenario, I am using ACS as the STS.
How would this fit together? Is it even possible?
Well – the problem is not the authentication. The problem is CSRF protection. For the cookie based part you want CSRF protection on the API. Do you have that?
This most probably will prevent external callers.
No I don’t think I do. It is just a matter of whether you have a token (issued via wsFederation originally). I don’t recall anything in the web api stack (or my implementation) that would verify this.
I thought the token already contained information about the trusted source of the token.
CSRF is an attack against implicit browser based auth mechanisms, e.g. cookies. Did you watch my latest PS course on Web API security?
I didn’t. I’ll have a look :)