Google Account Chooser , “API projects”, X.509 certs and wordpress integration

Lest I be called an identity bigot (unwilling to contemplate the ideas of others, spewing bile stating why nothing other than my own preferred technology and approach to websso and national infrastructure could even be pertinent), I went through the exercise of installing wordpress (in webmatrix), upgrading to the latest version, installing the Google “Account Chooser” plugin, and configuring the API keys in a google hosted “API Access” project.


webmatrix hosted wordpress

We use the marked link to get to an administration portal -bound to a google account I already happen to have (homepwrap).



Clearly, the screen is about “APIs” – which is good news – even though I thought it was going to be about Account Chooser (and the openid connect mechanisms for choosing IDPs). But, let’s see where it goes.

Compared to other material on the web, the OAUTH2 writeup  is well done. So, well done Google. You made your case (for the general architecture). Whether OAUTH2 is worth something over OAUTH v1… is yet to be determined. My gut feeling is that OAUTH2 is architected for trust brokering, in addition to the OAUTH v1 benefits. And, I’m not sure opening that window is in my interests – as operator of cloud services to several RP communities to be honest. It feels like someone is attempting to hijack the value I bring (using easy to integrate technology to obtain the competitive entrypoint). As a simple competitor, one must be mindful of typical American infrastructure marketing methods. To be fair, one must also laud the attempt to make things ever better, simpler and easier!

Well my first quandary is determining how to assess Google’s own plugin to wordpress, when creating configuration items! Is wordpress a web app or service account type clientid? I don’t know! Let’s go with web app:


ok so my client id is “”, bound to my URI for the wordpress instance hosted in webmatrix – and lots of other data as shows nicely in a JSON configuration artifact:


So what is my API key? Presumably, one day, the wordpress plugin will consume that object (and avoid all this confusion). Let’s create a service account too; and see if anything more obvious turns up. In this case, the UI says:


Is that my wordpress API key? Surely not! So what do I do!!? Anyways, we store it publicly here. It seems like a useful little service to make .p12 files, if nothing else. Of course, Google knows the private key (which means the FBI already knows it by now, too, in my case!)

This gives a smaller JSON config artifact of


where we have


This URI gives a JSON response as quoted below – which is kind of fun.

…SaSx3nQaEzm7tOYw==\n-----END CERTIFICATE-----\n" }

We store the —–BEGIN….CERTIFICATE—– text to a skydrive file called 48308ce69ae0feb61a81c10ea3ca91ea00f74005.cer, and we get something familiar (a .cer file to accompany the .p12 file, presumably!)

Clearly, X509 is not dead!


One does wonder about those who choose sha1, RSA of 1024 for client authentication and a 10 year expected validity period for crypto material that is already declared compromised by none other than Microsoft!

But, we are digressing, we still have not found the API key for that wordpress plugin.

Perhaps its time to give up as the omens from the oracle are not good.

Let’s have one more try, using the client secret from the “client id” page, for the webapp’s API key.


wordpress settings, saved

It’s really hard to figure what to do next (since no change appears on the login form, or the membership profile).. But APPARENTLY (from the readme), there may be widget one can add (not that I can find out how to see it or activate it using widget settings UI in wordpress!)

So, let’s open wordpress source code itself in visual studio 2012 IDE, creating an empty solution and then importing the (existing) wordpress website listed in the iisexpress web server:


I wonder if this code assumes a particular webserver (Apache), and thus this is entirely a waste of time?

= 1.0 = Initial Version.

== Installation ==
1. Turn on apache mod_rewrite module in your apache config file. Otherwise, the Google Identity Toolkit plugin will not work properly.
  Enable the mod_rewrite for apache method
   a. Enable the apache config file http.conf, found:”# LoadModule rewrite_module modules /”
      and Remove the front of the line “#”
   b. restart apache
2. Unzip and copy the installation package “” to the WordPress root directory “wp-content/plugins/”, Or copy the google-identity-toolkit directory to  “wp-content/plugins/”.
3. Go to “Settings/Google Identity Toolkit”, enter “APIKey” which you can get from Google Developer Console (, then click the “Save Changes” button to save your configuration.
4. Refresh your WordPress website and you will see there is a login button on the top-right of the page.

Though it does not show, it is clear that the logon form issued by wordpress is indeed being given account chooser javascript – with the right parameters. No button popup shows though.


At the same time, there is clear evidence of  API activity :


If we restart the webmatrix process… we do now see (durr), a login button (top right). It is not on the login form! It is on the main page. Well call me stupid, stupid. It also now on the logon form (hmm.. I restarted the process several times, before now…which is a little worrisome.)


which gives


Use of the main form’s “top-right logon” button is less successful (in wordpress 3.4.2 on IE10, desktop mode).


Clearly we have made SOME progress, and got to about where we were with the Azure project that allowed us to render a similar popup in joomla – using a trivial bit of javascript/jquery script. Obviously, this is a bit more advanced … since its setting up a security context (for API access), and not just orchestrating routing of IDP requests and responses, using ws-fedp “whr” chaining.

When using the hotmail button, the Account Chooser didn’t work. But, then do I have the right API key!!? I still don’t have any certainty even on that point!

Using google’s own IDP seems to do better, nicely doing what our  own IDP design does too (have multiple login/email contexts for an IDP session). Given in the email box , it is able to bind to and say


producing, after various redirects…


and a nice bit of classical commercial spying:


Does this mean I have the right API key?

Anyways, arming “registration” seems to require admin access to wordpress. But there is now NO LOCAL LOGON (admin) to change the administration settings! Only the federated logon method (that doesn’t work yet) can log me on as admin!

What a (wordpress plugin) piece of architectural rubbish. A total waste of time; with a failure at the last step …all due to being doctrinaire – stripping folks of local control. What a shame Google.

All I can do I suppose, is discard the entire wordpress instance, and start again (with registration preset). Can’t be bothered. I don’t believe in this showcase wordpress integration-model.



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

One Response to Google Account Chooser , “API projects”, X.509 certs and wordpress integration

  1. Pingback: Registering federated accounts with admin role in wordpress (With Google Identity Toolkit plugin v1.0) « Peter's ruminations

Comments are closed.