wordpress, jetpack.me and blogging adoption of oauth2


It’s been my assumption for a while that the main mission of the cloud – in public policy – was to change how the internet is governed. First, the policy would be to nationalize it; and second to ensure that a few TTPs could seize control (when needed). Only by this means can the internet – as the core of a service economy – allow post-industrial powers like the UK (and US) grow (and thus keep up). Otherwise, as manufacturing job transfer from high cost economies to low cost economics (with 300 million recent middleclass joiners to embrace), one loses.

And its in that context we write this blog – mostly to play with all the tools: since tool making is actually a service!

Now, blogging is still evolving (as shown by the evolution of the toolware). And slowly, Im easing off the PC-era blogging tools and onto the newer paradigms – built into windows 8 and related devices (my windows phone, and android kindle). And so we get to play with “jetpack” – to understand where wordpress.com (that evil cloud player, now) is going with its OAUTH2 strategy for a post-imperial US role in world domination.

Hmm. Starting to sound like Cryptome, now. Best get off that shared joint, before I catch the American disease of gushing continual depressed rantings as a (middle-aged – actually old-aged) “geezer”. Oh well. Lets not rant but merely bloviate a bit (and forgive me if its has insufficient bloviation; I’m still learning how to be a depressive operating at the end of the American empire – one of the shortest-lived history will note. But fortunately, having caught the tail end of the end of the British empire, I have *Something* to guide me…).

So on installing wordpress app onto my windows 8 PC, I used what I learned from my android tablet: the share button, available after a suitable gesture. Up pops the wordpress “addon” to the browser. ANn, Im invited to “connect”” to the wordpress.com services – I.e. my (hosted) blogsite. I get to use either my (old and boring) wordpress.com account at the (hosted) login screen or use “my jetpack” – whatever that is.

Well, it turns out that jetpack is a hookup between my self-hosted blog (that I will now create) and wordpress.com – the evil “cloud vendor”, recall – who will support my “self-hosting”. Presumably, it will exercise “Continuing governance”, so that “self-hosting’ won’t delegate too much power (to me, the evil, non-exceptional foreigner playing the role of the visigoth, at the fall of Rome). Of course, since all this “Connection” information is “metadata” – one assumes wordpress.com will give it straight to NSA!

But lets get back to computers (since they are just as much fun as annoying folk by proxy).

image

I have an MSDN paid up subcription in Azure bound to me home_pw@Msn.com login account. But, I also have a 3 month subcription (free) bound to home_pw@outlook.com (to which I made home_pw@msn.com a co-administrator). Thus, from home_pw@msn.com’s console, I can provision an azure website with wordpress installed into “my” free subscription. (doesn’t this sound like a loophole!?). This is the first step before I get to use “jetpack” – I assume.

So, from the scaffolding, we initialize wordpress itself;

image

once I get a site (and logon classically to the self-hosted site) I access the site admin area, which allows me to install jetpack:

image

 

Note what Im going to get (in addition the things highlighte above) is the avility in the windows 8 to use the “share button” between IE and my blogging tool (an app loaded onto the PC) that in turn will use my Hosted site (jetpack.azurewebsites.com) membership system and associated login processes. If I understand the billing properly, this will connect up to the wordpress.com’s oauth for-cloud-subscriptions endpoints – that will enable my hosted site to expose APIs (guarded by tokens minted by wordpress.com).

That is… this is wordpress.com equivalent to the Google IDPs and Azure ACS namespaces! Anyone, enough theory. Let’s see what works when we “activate” the plugin:

image

Not surprisingly, we have to bind our site immediately to the equivalent of a new Azure ACS namespace… and hopefully learn what wordpress.com call such OAUTH2 tenants.

So let’s get passed the first hurdle (ssl certs):

image

Now, the whole reason I selected azure websites was so that the SSL provisioning problem got solved as in:

image

So, what’s up (and what induces wordpress.com to object to the chain above)? Well my conclusion is that the host environment of azure websites cannot process the wordpress.com trust chain (and never will, be a shared hosting platform). So we turn off https:

 

image

 

getting us to a “tenant authorization” screen:

 

image

 

Using some SSL magic id get shot if I tell you about, we get passed a blockage and onto:

image

…after a classical sso handshake and  request for and delivery and then use of an authorization_code:

image

image

We see that the JSON API component (of our self-hosted site) is now active, due to jetpack, and that wordpress.com offers a client-id/password registration site (for third party apps wanting to connect up to my new hosted site, courtesy of the offloading between jetpack and the wordpress.com cloud):

image

http://developer.wordpress.com/docs/oauth2/

Let’s play more , once I’ve stopped laughing about an NSA contractor’s “pillow countermeasure” – the all-American grandmothers’ defense of the right to think only about apple pie.

OK. Back to something important (like making an authenticated internet work right):

Let’s create an OAUTH client record (intending to authorize some webapp-client (foo) – trying to access the new wordpress server at jetpack.azurewebsites.net:-

giving

image

id: 3955

secret: k60ViyceYPCNynguCfHLIifaQUM7Sywil6fCconKBgfBUlw3fqUTDjFmOZnwvMn5

giving an authorize URI of:

https://public-api.wordpress.com/oauth2/authorize?client_id=3955&redirect_uri=http://foo.azurewebsites.net/&response_type=code

 

using this authorize URI at a browser gives

image

after selecting “jetpack” (from my choice of this “connected” site and my hosted wordpress site “yorkporc”):

image

we get a challenge (to logon at the server’s IDP – which is the server itself):-

image

delivering a code (ready for a token client to use at the wordpress cloud’s token issuing endpoint).

image

ok. I think we see how things work. What we need to do is try again, later, now with a decent client (perhaps built into a second install of wordpress). It can consume this API.

Anyways, where we started was merely using a share button… that invokes the wordpress IDP (that we just proved work.)

image

giving us a sharing link:

image

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 oauth. Bookmark the permalink.