For some times there’s been bug reports to Kentor.AuthServices, IdentityServer3 and System.IdentityModel.Tokens.Jwt about enabling SHA256 XML signature support sometimes breaks JWT signing. It fails with an error of System.Security.Cryptography.CryptographicException: Invalid algorithm specified.
This has been one of those annoying bugs where everyone’s solution works perfectly by itself, but combined they fail. I closed this issue in AuthServices with a comment that “works for us, has to be IdentityServer3/System.IdentityModel.Tokens doing something strange.”. I’ve finally had some time to look deeper into this thanks to IRM that asked me to do this as a consultancy service. Without someone paying for the time, it’s hard to spend the hours needed to find the root cause of a problem like this. When I started out on this I looked at all three systems/components involved to try to understand what triggers the problem. I ended up fixing this in Kentor.AuthServices for now. The fix could also have been done in the .NET Framework, IdentityServer3 or System.IdentityModel.Tokens.Jwt. Doing it in Kentor.AuthServices was mostly a matter of convenience because I control it myself.
That means that the TL;DR of all of this is that if you update to Kentor.AuthServices 0.19.0 or later this problem is solved. If you’re interested on how to solve it if you add SHA256 support yourself, please read on.
.NET offers the simple
string.Join() methods for joining and splitting separated strings. But what if there is no suitable separator character that may not occur in the string? Then the separator character must be escaped. And then the escape character must be escaped too… And this turns out to be quite an interesting algorithm to write.
I thought that this functionality would be built in, but as far as I could find out it isn’t. If there is a built in way, please leave a comment to educate me. This being a string manipulation, there is a possibility to use Regular Expressions too, but…
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
Solving this through a Regular Expression would require some black magic double look-behind assertion which I wouldn’t understand even when I wrote the code, much less later when I came back to fix some bug. So I went for implementing it myself.
Today we released Kentor.AuthServices 0.18.1. It contains a number of bug fixes, but also a couple of breaking changes to a mostly internal API and logout handling.
You are affected if…
- you build a
HttpRequestData yourself, instead of using a build in
ToHttpRequestData() extension method.
- you are using Single Logout and…
- you have a
- you manually create a
- you filter out claims that are persisted
Most users should not be affected, but if you match any of the above please read on.
With Coveralls.IO it’s possible to get code coverage on all pull requests submitted. For Kentor.AuthServices I’ve set up AppVeyor builds that uses Coveralls.Net to upload coverage numbers to Coveralls.IO.
When I set up the code coverage I already had AppVeyor builds running. I wanted something that worked together with AppVeyor. I tried out a few options and quickly found out that I also wanted something that used the Visual Studio Code Coverage engine. The project had 100.00% coverage in Visual Studio when I started and when I tried another coverage engine it showed some lines as skipped. I wanted consistency with the Visual Studio Code Coverage, which coveralls could give me.
Earlier this month, Microsoft released MS16-035 that addresses issues I previously reported in SignedXml. They did not only fix the duplicate Id vulnerability I reported though, they also fixed a number of other issues – introducing some breaking changes. This post is an effort to document those and changes and the registry switches that can be used to revert back to the old behaviour.
These are the breaking changes I know about. If you know of any more issues, please leave a comment or drop a mail and I’ll try to update the post.
- Duplicate Ids for reference elements no longer allowed (applies to both
- Id values must be a well formed NCName (which is required by the XML standard, applies to both
- External references disabled by default
- XPath Transform disabled by default
- XSLT Transform disabled by default