[OpenID] Google Apps, dependencies, failover and UCI

[Peter Williams]

Hans:

Re: Per your memo (enclosed below)

In defense of Google, I've had only sterling success with their websso to Google Apps. In engineering terms, we can perhaps analyze it, and perhaps glimpse at their openid services for their SPs (as they evolve, them).

The Google SP optionally administers with a local id (allowing administrative failover, when the sso links break), and users can (SAML2) websso into it as an entirely standards-based SP once the SP->IDP link is manually configured. As an SP, it aggregates several applications into its local session. However, they can be targeted individually as resources when performing websso, since the websso service hooks up nicely with the complementary DNS naming and service mappings for the hosted domains.

All in all, it's well thought through -  through its very, very expensive at $50 per annum, per user. I've no doubt there are major price breaks for volume of n0,000 users... in which case it would be viable for integration with our realty "MLS", for example,once down to $0.50-$1 a month. A large percentage of our users choose gmail anyways (where we send about 100G of data to gmail accounts every night, after running the users' custom data-crawls!)  I'm sure individuals would authorize $0.50 cents a month for the convenience of websso to their gmail from their main console. They already do that to websso to a dozen other sites, after all. If now paid for by search ads on the websso UI, that src of funding might even overcome the current, total-resistance to (Google) ads.

Technically, Google Apps performs sp-initiated websso flow (essentially like openid1), and has been tuned so that one IDP aggregator/endpoint can host n IDP tenants (all on the same switching entityID/cert). This allows an approximation of the OpenID-style delegation, where the level1 IDP acts as a delegation/proxy resolver. That first line IDP known to Google performs rerouting (though Google are not exploiting SAML2 grade security signed requests), and vectors the request upstream to a 2nd-level IDP delegated by the user or selected interactively (in our implementation). These upstream failover dynamics can all hidden from the SP (unlike in the control system design used by OpenID2.) but are clearly intended by the Google architecture.

It's by no means all as cute as a real openid2 SP->OP, with user-controlled (signed) XRDS being accessed directly by SPs. But it's the best SAML2 SP I've personally seen on a consumer-grade website, where all sso/dns configuration can be done without needing specialized engineers. Hey, even I could do it.

WebSSO is all about dependencies. The trick (having managed this kind of integration for 2 years now  with a variety of sso folk with a wide range of security engineering training) is to ensure all the failovers work - for when the public web/internet breaks. This is why I personally  focus on failopen, loosely-coupled, user-centered control system designs.. as its very orientation has side-effect that take care of vast majority of inter-system dependencies. By getting the intelligent human being involved in failover (only) early on, we avoid the support phone call that we cannot afford to service.

So, I give Google an A- on websso design and execution (as I've seen it). They can go for optional extra credit and be awarded an A, if they would sign the auth requests.


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Hans Granqvist
Sent: Sunday, December 07, 2008 10:25 PM
To: openid-general General
Subject: Re: [OpenID] We Need Less Bureaucracy But Also More Transparency

Google groups are broken. I can't sign up to groups with any email address I want.
My main domain is hosted by Google Apps and I cannot sign up with any email
address on this domain. Though I suppose I should be able to, the Google reps
I've spoken or emailed to (several) can't fix it. I wonder how many else
would be in the same situation.

Regardless, you cannot have dependencies if you want to stay open, right?

If there is more money needed to keep mailman and servers going, and OIDF is
unable to pay (are they?), why not politely request a cut from the conferences
making money around the standard?


On Fri, Dec 5, 2008 at 5:36 PM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:
Does the foundation resolve to deem acceptable google's privacy practices (since thats the indirect endorsement).

Can't whine about janrain without doing the same to all.

has anyone even reviewed them yet for political correctness (while facebook meantime cleansup).

Satire.

-----Original Message-----
From: SitG Admin <sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com>>
Sent: Friday, December 05, 2008 6:31 PM
To: David Recordon <drecordon at sixapart.com<mailto:drecordon at sixapart.com>>
Cc: general at openid.net<mailto:general at openid.net> <general at openid.net<mailto:general at openid.net>>
Subject: Re: [OpenID] We Need Less Bureaucracy But Also More Transparency


>I keep wanting to see us move to Google Groups

So long as we can make clear that it isn't an endorsement? ;)

I understand that Google has an interest in *their* system being
used, and offering a mere publicly searchable archive (open Gmail
account subscribed to the list) wouldn't stop users from using their
*other* systems, but the topology of such a solution resembles the
idea of UCI: instead of going with a single central interface, users
go with the list (their 'open' choice) and can login to Google with
their OpenID's to see an aggregated dataset (or, if they like what
Google is marketing, opt to upgrade to a Gmail account so they can
begin integrating their private messages with that dataset, too).

-Shade
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081208/e4c6286d/attachment-0002.htm>