[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 anssi.porttikivi@kpmg.fi 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]