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).
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
we amend our WCF button event handler:
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…
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.