Finally! The signatures generated by the openinfocard id selector and the openinfocard STS are now accepted at relying parties that are based on Microsoft code. Mark Oluper from Microsoft's CardSpace team put the generated SAML assertions under his microscope and found the offending byte.
Axel,
The issue is that the key length doesn't match the signature length. The Windows CryptVerifySignature API verifies that the key length in bytes matches the signature length in bytes.
If you look at the modulus value for the Firefox identity selector generated assertion you will note that the value does not have the base 64 padding character whereas the signature value does. This results in a key length of 1032 bits (129 bytes) whereas the signature value is 1024 bits (128 bytes).
For the CardSpace generated assertion both the key length and signature length are equal to 2048 bits (256 bytes).
Regards,
Mark
So, what is the reason for this extra byte and why are the signatures accepted by relying parties that are Java based? Well, Java's BigInteger class introduces an extra null byte as the first byte when it converts a BigInteger into a byte array. I removed this extra null byte before base64 encoding the modulus of the signature key and now it works! AND the Java signature validation still works too!
Why does it work? Because Java just decodes the base64 encoded modulus and the constructor of BigInteger ignores extra null bytes but does not require them. There could be hundrets of null bytes and Java would still construct the same BigInteger modulus.
I did a quick check with self-issued and managed cards at several relying parties and all looks good.
- openinfocard RP (Java): local installation
- Bandit Project RP: https://wag.bandit-project.org/BanditIdP/index.jsp
- jinformationcard demo shop (Java): https://zeno.fokus.fraunhofer.de/MiniShop/home.jsp
- FuGen Solutions' Demo RP: Microsoft Code https://socialphotos.federationportal.com/
- FriendsWithCards RP: Microsoft Code https://www.cardspacedemos.com/FriendsWithCards/
The new - latest and greatest - version of the id selector is here in the openinfocard download area.
Thanks again to Mike Jones and Mark Oluper for helping with this issue!
2 comments:
I am having lots of issues with the selector. I have tried every downloadable version and am currently using 0.9.7. I had to add:
policy["chainLength"] = "0";
to the ok() method for both self-asserted and managed cards within the infocards.js file in order to get it working. This issue has been on-going since around 0.9.2 on both my Windows and Linux machines. Is there any environmental issues that might cause the selector to fail for me while it seems to be working for you? (I noticed that a similar issue was supposedly resolved back in January)
Also, have there been changes in the sites you tested against? I havent been able to get the selector working in any of them. Most of the sites fail to detect the selector (displays a nice big error), so selector is never kicked off. I see this more as an issue with the sites, but still wonder how they detected the selector on your system while failing to do so for me.
You can reach me via my i-name (http://xri.net/=rob.richards) if you need any detailed error information.
When Kevin Miller's id selector selector was published Chuck decided to support it. Starting from then the openinfocard id selector NEEDS Kevin's extension. Otherwise it won't be triggered. I am thinking of reversing this because Kevin's extension has some small issues too e.g. it does not handle the privacyUrl argument. I will document this dependency on the openinfocard project site right now.
Regarding the "chainLength"-issue: I will look into it. Your quick fix does not appear to be logical. Please contact me directly and describe what happens without the quick fix. axel at nennker dot de
Post a Comment