{"id":3350,"date":"2015-08-26T01:55:07","date_gmt":"2015-08-26T08:55:07","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=3350"},"modified":"2015-08-26T01:59:29","modified_gmt":"2015-08-26T08:59:29","slug":"augmenting-the-set-of-incoming-claims-with-the-openid-connect-and-oauth2-middleware-in-katana-3-x","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2015\/08\/26\/augmenting-the-set-of-incoming-claims-with-the-openid-connect-and-oauth2-middleware-in-katana-3-x\/","title":{"rendered":"Augmenting the set of incoming claims with the OpenID Connect and OAuth2 middleware in Katana 3.x"},"content":{"rendered":"

\"image\"<\/a><\/p>\n

Here there\u2019s another (very) frequently asked question. I have the eerie sensation that I have already blogged about it, but a quick search did not yield any result post-WIF\u2026. so here you go.
\nSay that I have a web app or a web API secured with Azure AD (or any other provider, really). Say that in my app I maintain attributes about my user, and I would find it handy to have such attributes exposed in form of claims, alongside the ones I receive from the trusted authority at authentication (nee token validation) time. How do I make it happen with Katana 3.x, OWIN\u2019s implementation in ASP.NET4.6?<\/p>\n

OpenId Connect<\/h2>\n

Easy. Let\u2019s start with OpenID Connect (OIDC for brevity). The OIDC middleware graciously offer notifications at key stages of the validation pipeline. The last of those, SecurityTokenValidated<\/span>, offers you the chance to modify the ClaimsIdentity<\/span> obtained from the incoming token. Here there\u2019s an example, where \u201cRetrieveHairLenght\u201d is a hypothetical function that queries by local DB for the desired attribute.<\/p>\n

SecurityTokenValidated = (context) =>\r\n{\r\n    string<\/span> userID = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.NameIdentifier).Value;\r\n    Claim userHair =<\/pre>\n
      new<\/span> Claim(http:\/\/mycustomclaims\/hairlenght<\/a><\/span>,<\/pre>\n
                RetrieveHairLenght(userID),<\/pre>\n
                ClaimValueTypes.Double, \"LOCAL AUTHORITY\"<\/span>);\r\n    context.AuthenticationTicket.Identity.AddClaim(userHair);\r\n    return<\/span> Task.FromResult(0);\r\n},\r\n<\/pre>\n
Once you have added that to your Notifications property of the options you initialize the OIDC middleware with, you\u2019ll be able to read that claim from anywhere your app – just like any other \u201cofficial\u201d claim:<\/p>\n
var userHair = ClaimsPrincipal.Current.FindFirst(http:\/\/mycustomclaims\/hairlenght<\/a><\/span>);<\/pre>\n
 <\/p>\n
Preeeety neat. Note that this happens at token reception time, right before establishing the session. That means that whatever I\/O you performed for retrieving your extra attributes will be done only once, which is good; it also means that the resulting custom claims will end up in your session cookie\u2026 and if you add too much stuff, the effects might not be good: performance hits, cookie clipping if you exceed the browser limits, and so on. Keep all those considerations in mind as you plan your augmentation strategy.<\/p>\n
Web API<\/h3>\n
Now, say that you want to do the same for a web API.
\nIf you are on ASP.NET 5, good news! You do exactly like the above (module the ClaimsPrincipal.Current<\/span> part, topic for another post).<\/p>\n
If you are on ASP.NET4.6 and Katana, that is a bit trickier. The web API middleware in Katana3.x does not have a very rich notifications pipeline. However you still have a mechanism for injecting your custom claims, it\u2019s just a bit different. Given that this is a tad more exotic than just filling up a notification<\/p>\n
app.UseWindowsAzureActiveDirectoryBearerAuthentication(\r\n    new<\/span> WindowsAzureActiveDirectoryBearerAuthenticationOptions\r\n    {\r\n        Audience = ConfigurationManager.AppSettings[\"ida:Audience\"<\/span>],\r\n        Tenant = ConfigurationManager.AppSettings[\"ida:Tenant\"<\/span>],\r\n        Provider = new<\/span> OAuthBearerAuthenticationProvider()\r\n        {\r\n            OnValidateIdentity = async context =>\r\n            {\r\n                context.Ticket.Identity.AddClaim(\r\n                   new<\/span> Claim(http:\/\/mycustomclaims\/hairlenght, <\/span>\r\n                                   RetrieveHairLenght(userID),                \r\n                                   ClaimValueTypes.Double, \r\n                                   \"LOCAL AUTHORITY\"<\/span>);));\r\n            }\r\n        }\r\n    });<\/pre>\n
OnValidateIdentity<\/span> gives you a last chance of modifying the ClaimsIdentity<\/span> before it gets passed to the app, in analogy to what you have seen for OIDC.<\/p>\n
Note that in this case there is no cookie to remember the authority-issued claims and your custom attributes \u2013 the nature of the web API is that you\u2019ll get the token at every. single. call.
\nYou\u2019ll probably be well served by some inmemory caching strategy, so that the call to RetrieveHairLenght does not have to query slow persistent storage all the time.<\/p>\n
Short and sweet, especially because it\u2019s 2:00am here \"Smile\" have fun with your custom claims!<\/p>\n","protected":false},"excerpt":{"rendered":"
Here there\u2019s another (very) frequently asked question. I have the eerie sensation that I have already blogged about it, but a quick search did not yield any result post-WIF\u2026. so here you go. Say that I have a web app or a web API secured with Azure AD (or any other provider, really)….<\/p>\n","protected":false},"author":1,"featured_media":3348,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3350","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3350","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=3350"}],"version-history":[{"count":2,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3350\/revisions"}],"predecessor-version":[{"id":3352,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/3350\/revisions\/3352"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media\/3348"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=3350"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=3350"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=3350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}