{"id":2541,"date":"2013-11-04T09:35:59","date_gmt":"2013-11-04T16:35:59","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=2541"},"modified":"2013-11-04T09:38:42","modified_gmt":"2013-11-04T16:38:42","slug":"call-a-web-api-without-knowing-in-advance-its-resource-uri-or-what-authority-it-trusts","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2013\/11\/04\/call-a-web-api-without-knowing-in-advance-its-resource-uri-or-what-authority-it-trusts\/","title":{"rendered":"Call a Web API Without Knowing in Advance Its Resource URI or What Authority It Trusts"},"content":{"rendered":"

Courtesy of the daylight saving switch, which made the weekend just a tad longer, here there\u2019s a quick post to show a relatively small but powerful feature of ADAL, the AuthenticationParameters class.
In a nutshell: I\u2019ll show you how you can write a client to consume a Web API secured by AD – knowing nothing at development time about the Web API\u2019s security requirement.<\/p>\n

Resource-Driven Authority Discovery<\/h2>\n

Most of the ADAL code samples you have seen here follow the same (hopefully easy) pattern:<\/p>\n

    \n
  1. Create an AuthenticationContext instance to represent in your code the authority (Windows Azure AD tenant\/ADFS instance) trusted by your target resource<\/li>\n
  2. Use the AuthenticationContext instance to obtain a token (via any of the AcquireToken overloads) for the target resource<\/li>\n
  3. Use the token to call the service<\/li>\n<\/ol>\n

    That pattern assumes that you already know #1 the authority you want to work with, and 2# the identifier by which the target resource is known by that authority. That is often a sound assumption (after all, as of today you do have to explicitly configure permissions between a client and a resource, at least in AAD) but it does not always hold. You might have created a generic client, meant to be downloaded from some central store and used by multiple tenants that are unknown at development and publication time.
    Sometimes, all you know are the coordinates of your client app itself (id, returnURI) and the physical URL (not the URI) of the resource you want to access.<\/p>\n

    Well, good news everyone! The Bearer Token Usage P.S.<\/a> from the Oauth2.0 Authorization Framework defines a mechanism through which a protected resource can – upon receiving a request without adequate authentication credentials \u2013 challenge the caller by passing back information that the client could use to obtain the necessary credentials. Trivializing things a bit: you could say that if you call a Web API without including the token it expects, the Web API will reply back with the necessary data (usually the authority it trusts and the Web API\u2019s identifier) for you to obtain the right token and retry. This handily takes care of the aforementioned case: who cares if you don\u2019t know the authority and the id of the Web API in advance, when the Web API itself can tell you the first time you call it!<\/p>\n

    The challenge format is super simple and you could easily parse it manually, however we decided to make things absolutely frictionless for you and baked support for it directly in the library\u2019s object model.<\/p>\n

    The responsibility of generating the challenge is on the resource developer: that means that if besides the client app you also own writing the Web API, it\u2019s up to you to inject the necessary logic.
    The     main ADAL sample on code gallery<\/a> does demonstrate this approach. However we wrote that sample in the pre-OWIN era, when you had to handle all the resource side code (JWT interception, validation, ClaimsPrincipal creation, etc) by hand. I wanted to make sure you know how to take advantage of this feature also when you are creating your Web API with the VS2013 templates (AAD tutorial here<\/a>, ADFS tutorial here<\/a>) and OWIN middleware. As of today that entails customizations that might not immediately clear, or at least weren\u2019t for me: luckily I had the help of David Matson<\/a>, a developer on the ASP.NET team that knows this stuff inside out and also happens to be the fastest typist I\u2019ve ever seen working in the VS IDE \"Smile\" Thanks David!<\/p>\n

    Here there\u2019s how I am going to break this down: first I\u2019ll walk you though the code you need to add to the Web API project to generate the challenge, then I\u2019ll show you what parts of ADAL you can use on the client to make sure your app understands the challenge. That done, we\u2019ll give it a spin and then we\u2019ll make some larger scope considerations.<\/p>\n

    Emitting a Challenge From Your Web API<\/h2>\n

    Let\u2019s start by creating a Web API project configured to work with organizational accounts, as described here<\/a>.
    That will provide us with the perfect starting point, a Web API project already provisioned in Windows Azure AD and already configured with the necessary OWIN middleware to validate JWTs from the Windows Azure AD tenant we used for creating the project.<\/p>\n

    The goal is to modify the behavior of the authentication OWIN middleware to produce a suitable Challenge message whenever a 401 response is warranted.<\/p>\n

    To do that, we will need to play a bit with the lower level components that ASP.NET uses for working with OWIN in Web API projects. Go to the Solution Explorer, right click on the Web API project and choose Manage NuGet Packages. Search for Microsoft.AspNet.WebApi.Owin and once you find it install it.<\/p>\n

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

    Excellent. That done, go to the Controllers folder and open the ValuesController.cs. We are going to use the default code generated by the template. Take a look at the controller declaration:<\/p>\n

    [Authorize]\r\npublic<\/span> class<\/span> ValuesController : ApiController\r\n{\r\n    \/\/ GET api\/values<\/span>\r\n    public<\/span> IEnumerable<string<\/span>> Get()\r\n    {\r\n        return<\/span> new<\/span> string<\/span>[] { \"value1\"<\/span>, \"value2\"<\/span> };\r\n    }\r\n<\/pre>\n