A rogue SP x impersonating a principal Z to SP y?

I read 'Formal Analysis of SAML 2.0 Web Browser Single Sign-On:
Breaking the SAML-based Single Sign-On for Google Apps'
(http://www.ai-lab.it/armando/pub/fmse9-armando.pdf) by Armando et al.

The paper shows, that an old version of Google Apps was vulnerable for a federated SP x impersonating an 

Now I am wondering, what exactly should I check in a given SAML implementation, to ensure that SP x impersonating a principal Z to another SP y is not possible?

It looks like the 'Audience restriction' in a signed, integrity ensured assertion can be used by the iDP to signal, that this assertion should not be used outside of SP x. Now the SP y will also have check it. Is this the canonical way to do it? 

Anssi Porttikivi
Senior ICT Advisor
KPMG Finland
tel GSM +358 (0)40 750 5155 (call me any time!)
email  



The information in this e-mail (and any attachments) is intended exclusively for the addressee(s). Any use by a party other than the addressee(s) is prohibited. The information may be confidential in nature and fall under a duty of non-disclosure. If you are not the addressee, please notify the sender and delete this e-mail. KPMG cannot guarantee that e-mail communications are secure or error-free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. Any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing KPMG client engagement letter. Please consider the environment before printing this email.