Not yet

Google's demo page for their SAML-based SSO does not yet reflect whatever fix they've implemented to address this vulnerability.

You can tell because the generated <Response> still doesn't include an InResponseTo attribute.

Of course, it is not Google that actually creates the <Response> message, they consume it. It is the partner IDPs that create the response (which, if they use Google's reference implementation of SAML won't avail themselves of the mechanisms SAML provides to scope an assertion to the intended audience.)

I wonder how the Google SP would deal with a <Response&g; from a conformant implementation?

The necessary conditions for the attack are not quite as simple as I first imagined

Now, any other SP offering the very same SAML SSO solution as Google and attractive enough to convince the AI-Lab to include one of its remote services (e.g. free access to online scientific books) is able to mount the above attack and thus to impersonate any user of the AI-Lab IdP that accesses its resources at any Google Application.

So, the attacker has to set themselves up as a SAML SP (using Google's library) and then convince a good IdP to send some assertions its way with (as Conor points out and Jeff castigates him for) a name identifier within that Google wll recognize (and not expect only to see coming from the good IDP).

Related, Andreas lists SAML messages from a variety of implementations.