ADAL, ADFS and emulating Windows Server 2012 R2 ADFS oauth endpoints


Stealing knowhow from the article at http://www.cloudidentity.com/blog/2013/07/30/securing-a-web-api-with-windows-server-2012-r2-adfs-and-katana/ that indicates how to make the ADAL library talk to the (oauth2) endpoints of an ADFS server, lets see if we make the project we built in the last memo talk to our own oauth endpoints, instead.

First, we  change the webAPI startup, to invoke ADFS specific middleware in the pipeline (and point it at our own metadata endpoint, nicely present in options.) Spying using fiddler shows the app does at download the metadata (and configure itself, presumably).

image

Of course, this basically configures the security token handler, given the metadata endpoints, names and certificates. Its up to the OWIN pipeline to invoke said handler (a subclass of the JWT handler, no doubt). We seem to be using “Katana” code presented here, whose options class does seem to allow us to specify our own “provider” (not that we do so, yet).

considering the sample of

image

we amend our WCF button event handler:

image

ok, so what we learn is that we get exceptions on invoking AquireToken during the “validation” of the addressed provider. The overloaded method is not supported! (or something equally vague). If one changes ones address to put “/adfs” on the end (requiring our endpoint to have the path “https://ssoportal.rapmlsqa.com/adfs….”, it stops whining about that (at least).

So, to emulate adfs and talk to an ADAL client, tell said client an address of a oauth endpoint with /adfs after the domain name. Oh, and host the handlers on the page path adfs uses for its oauthendpoints too (since the client libraries assumes these).

I wonder if I plugged in my own “provider” if it might use some cue word of my own, if detected in the address of the endpoint, to decide how to complete the paths? Or, perhaps, one doesn’t need the “Cue word” approach at all, if one specifies ones own provider on the context object since it defines its own “authenticationType” (PetersProvider)

we see this, for use later…

image

Looking at the Katana code smells very much like a certain persons coding style (and one sees lots of patterns, in common). Thus, to invoke my own “provider”, perhaps I ought NOT to be even using the ActiveDirectory subclass and extension methods, which are no doubt “per-provider” wrappers.

Anyways, I think Im getting confused between using ADAL on the client and OWIN in the server. This will all fall out in the wash later, by doing some simple coding experiments.

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in AAD, ADFS. Bookmark the permalink.