Last year I left Kentor for new adventures as an independent consultant. I got the Kentor.AuthServices project with me, but of course need to rename it as it is not associated with Kentor any more. So how does one rename a library and nuget packges with 100k+ downloads and users all over the world? Simply releasing new versions under the new Sustainsys.Saml2 name will leave a lot of users stale on the last version with the old name. So what I did was to release dummy packages that kicks off the migration process.
The last release with functionality in the Kentor.AuthServices name was 0.22.0. I then did a huge renaming operation and published new packages named Sustainsys.Saml2 with version 0.23. Finally I published dummy Kentor.AuthServices 0.23 packages that brings in the Sustainsys.Saml2 0.23 packages and shows a readme with migration instructions.
After more than 8 years at Kentor the time as come to move on. I’m leaving Kentor and starting my own business. I will continue to work with identity and access management, especially SAML2 on .NET. I will do consulting, open source development and training, both on site and remotely. The Kentor.AuthServices project will be transferred to my new company, Sustainsys
Kentor.AuthServices 0.21.2 has just been released to NuGet. It is a security release fixing three issues.
- XML External Entity Injection (affecting .NET 4.5 only)
- Malicious IdP can cause write to arbitrary file
- Flawed ReturnUrl validation leads to Open Redirect
The first two issues were reported by John Heasman, Morgan Roman and Joshua Estalilla from DocuSign. While I have dreaded the day when I would get a security issue I am extremely happy with the professionalism of the disclosure. I got the report privately, including detailed descriptions, reproduction steps and solid recommendations on how to fix it. I am very grateful you took the time to review AuthServices and find the issues and for the detailed reports.
More details on the vulernabilities will be published later.
Half a years worth of pull requests with great features have finally been baked into an official release of Kentor.AuthServices which is now available on Nuget. The most important fixes are improved active/passive handling for the Owin middleware and full support for SHA256/384/512 as it is time to leave SHA1.
First of all I would like thank all contributors and users that have had to wait for this while I’ve been on parental leave. A special thanks to Explunit who has made a lot of valuable contributions as well as reviewing pull requests and taken part in design discussions.
The public API of AuthServices is getting more and more stable, but nevertheless there are some breaking changes.
- The Owin Middleware is now once again Passive by default
- The Owin Middleware will act as Active during Logout, even if it is configured as passive. This can be disabled with the
StrictOwinAuthenticationMode compatibility setting.
- On .NET 4.6.2 and later AuthServices now by default generates SHA256-based signatures and only accepts SHA256 or stronger signatures.
- The “clever” ReturnUrl expansion has been removed as it proved to create more problems than it solved.
- ReturnUrl open redirect issue fixed.
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.