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
StrictOwinAuthenticationModecompatibility 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.
An owin middleware can be configured either as passive or active. In active mode the middleware intercepts all requests and tries to authenticate them if needed. In passive mode it doesn’t do anything unless explicitly invoked. Typically the only active middleware in an application is the session cookie middleware. All others that are used for external authentication are typically passive. This is how AuthServices used to work, until Single Logout support was added. When Single Logout is used, the typical scenario is that AuthServices should intercept logout of any SAML2-initiated sessions, even if not explicitly invoked. Because of that, the Owin middleware was changed to be Active by default when Single Logout was added.
This turned out to create a lot of issues for the login functionality though with plenty of questions on the issue tracker that were answered with “switch to passive”.
To remedy this, the Owin middleware is now once again passive by default. But behaves as active during logout. This hybrid approach should work well for most scenarios. If it doesn’t there is a compatibility setting StrictOwinAuthenticationMode that can be used to switch it off.
Kentor.AuthServices has had support for incoming SHA256 signatures for long with the GlobalEnableSha256XmlSignatures() configuration method. With .NET 4.6.2 that is no longer required as the support is now built into the framework. This means that AuthServices now has switched to generating SHA256 signatures by default when run on .NET 4.6.2. This includes the StubIdp where this change has been live for some time already. The generated signature can be changed with the OutboundSigningAlgorithm option. A default can be set for all outbound messages (including AuthServices’ metadata). It’s also possible to override for each Identity Provider.
There’s also a setting MinIncomingSigningAlgorithm that sets the minimum accepted strength for incoming messages. By default that is set to SHA256 when run on .NET 4.6.2 and SHA1 otherwise.
There has been some improvements to the handling of the ReturnUrl query string parameter used with SignIn and Logout. Previously it has been doing som “clever” expansion of the ReturnUrl, trying to expand any relative Url into an absolute one. The intention with this was to allow redirects to work even though the redirect is effected from another path than where it is initiated. An example: With the owin middleware in active mode an authentication is initiated from . The ReturnUrl is set to LoggedIn. If a redirect is done directly from to LoggedIn it would be interpreted as https://example.com/Account/LoggedIn. But the actual redirect is effected in a request to so the redirect would end up at which doesn’t exist. We tried to be clever and handle that. But when PublicOrigin is involved with external termination of TLS sessions this became very complicated and error prone. So we dropped it entirely.
The ReturnUrl has also lacked validation, in effect creating an open redirect (which is a bad thing, it’s #10 on OWASP Top 10 2013). This has now been fixed so that the ReturnUrl is validated before being used. If redirects to another domain is required, there is a Notification ValidateAbsoluteReturnUrl that can be used.
Finally, the Notifications system has been expanded to allow for customisation of even more of the behaviour. Going forward we’ll try to keep from adding too many new concepts to the configuration system and instead offer Notifications where custom code can be hooked in.
Source link