wordpress registration settings, and administration role assignment
To avoid the issues discussed in http://yorkporc.wordpress.com/2012/10/17/google-account-chooser-api-projects-x-509-certs-and-wordpress-integration/, on creating a wordpress instance in webmatrix do set the “anyone can register” setting. And, initially, set the administrator default too – so as to bind all newly created (federated) account to the administrator role.
Now, having assigned the client secret (and updated the port number of the localhost instance of this new instance of webmatrix/wordpress), we get
accelerate signin, remembering
Is this correct behavior? After all, this is the first time this site has ever been visited. What cookies or other means are informing the UI of that name?
But, let’s see if we get to wordpress, now. We do indeed get to a registration process (with username initially set to Peter, coming from the assertion presumably)
registering a new account
We see that, perhaps reasonably, only new users can bind the google names (current users cannot). And, we see that it will be the google-managed/registered mailbox that will be used to deliver a password. Hmm….remembering that in the US all email is stored… for real-time police access. Does one really want a password in an email?!?
binding names to only new accounts (no account reuse)
We get what seems like a wordpress logon, having done auto-account creation.
Could not find the password email (which is not surprising, since the mailer feature of wordpress is not active – and will not be in the azure hosted version of this, either). Also, despite that comment in the UI I cannot actually find the password field to update in the membership account record (though this may just reflect my lack of skill…). I note that logout/signin never uses a local cookie (it always requires a round-trip to google to get a new assertion).
Since we presumably have the right API key for Google’s account chooser service, we try out the Account Chooser service’s yahoo option (since the Hotmail option doesn’t work, for unknown reasons).
trying a multi-vendor hookup…
Lets use “google” signin feature (to help create an assertion with a yahoo id). Confused?
Anyways, after authentication (again) at Google (which presented no consent screen, probably because I consented before), we get a consent screen authorizing Yahoo to now assert to wordpress on this localhost instance.
meaning presumably that Account Chooser (or its proxy policy enforcer in the wordpress code) is not happy about the flow I used. At verification time, it is enforcing ITS ideas of who is verified (and Yahoo is evidently no longer the “confirming” party despite being the asserting party).
Hmm. Why do I want this “verified email” anyways as a wordpress site? Perhaps account chooser is only for sites that want some kind of “national” assurance attached to identities and accounts – that a TTP is controlling their quality.
I don’t like all the policy choices and biases being made for or imposed on me, as an RP site. Its all too “fussy”. I just want what we had in SAML – an asserted name, asserted by an IDP. If the assertion has a “confirmation” element attached to it affirming that name, then fine. And my code can choose to use it (or not).
Ok. So HOW many records now exist of this association attempt? how many places is a little bit of my internet behavior being recorded (for spying/monitoring purpose) DURING the very act of associating/logon using federated logon? Can I assume I have no privacy rights in the information about those (site) with whom I associate?
But to be a bit more positive, at least I was able to get a kind of account chooser based logon to work, with a wordpress hosted instance, at least when Google is the IDP.
Is it a great leap forward over the Azure Access Controls service (that also helps me list some IDPs in a popup)? No. Is there strong evidence that this is more than helping list IDPs in a popup – and is bundled together with a policy engine that addresses what SAML calls confirmation assurances? (yes!)