I would like to know how the Azure ACS team was affected, what implementations did they use, and how did they correct it?
I'm trying to see if "outsourcing" ACS authentication also gives me additional security that I otherwise would not have had (suppose I relied on a buggy implementation and was waiting for some FOSS to be patched.
I haven’t read through the document. But I noticed the following argument regarding Google Open ID’s flaw:
Does the RP check whether the email element in
BRM3 is protected by the IdP’s signature, even though
the protection has been explicitly required by BRM1?
If the problem is RP doesn’t check whether the email element is protected by IDP’s signature, then it is the RP’s fault. ACS should check identity providers’ signatures. But you also need to check ACS’s signature in your own service. Never forget to validate
a token using the key shared between your service and ACS, and never send the key to anything else, such as a client application.
There are no known ACS security vulnerabilities or bulletins as a result of this paper.
I can't give you any guidance on which external providers or libraries to use. What I can say is that this paper is well known in the industry and any providers or library developers with these vulnerabilities should be aware of them by now.
Marked As Answer byChrisLaMontTuesday, March 27, 2012 9:23 PM