What library does the ACS use for relaying and validating OpenID responses?

Question

I read this research paper that discusses flaws in OpenID implementations. http://research.microsoft.com/apps/pubs/default.aspx?id=160659  

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.

Answer 1

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.

Answer 2

ACS uses its own internal OpenID implementation, which correctly validates all signed elements. Rest assured that we are aware of this report.

Answer 3

Thanks Oren

Are there any outstanding threats I should track on my threat models on the IDP side?  Are all default IDPs protected (which are/arent)?

Lastly, since I can add my own OpenID IDP to Azure, is there any guidance on which FOSS or closed source versions are safe?

Answer 4

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.