Kentor.AuthServices 0.7.2 SAML2 for ASP.NET Released

Last week we released version 0.7.2 of the Kentor.AuthServices SAML2 Service Provider for ASP.NET. With this release and the 0.6.0 the week before (that I never blogged about) we’ve introduced some new features to better support SAML2 in federation setups. The first is that we now can load and parse federation metadata. No more manual configuration of peer identity providers. The second is that we now support using a discovery service to let the user select an identity provider to authentication with.

The core AuthServices, MVC and Owin packages are all available for download on Nuget. The source and issue list are on GitHub.


  • Idp metadata support.
  • Federation metadata support.
  • Discovery service support.
  • Http Redirect binding preferred.
  • Bug fixes.

Idp Metadata Support

Until now, configuring AuthServices with an idp has meant to provide a lot of details about the idp, including information on the certificate used by the idp to sign it’s responses/assertion. With the Idp metadata support it is now possible to let AuthServices download metadata directly from the idp and extract the information it needs from there. To configure and idp by using metadata, the following sections are added to the <kentor.authServices> section in the web.config.

  <add entityId="" allowUnsolicitedAuthnResponse="true" loadMetadata="true" />

AuthServices will interpret the entityId as a url (which is recommended by the SAML metadata specification) and download metadata from there. It is also possible to add a <signingCertificate> child element to the <add> node to manually specify a certificate. That information will override any information found in the metadata.

Federation Metadata Support

AuthServices also supports loading a set of identity providers from federation metadata. To configure a federation, add the following to the <kentor.authServices> section in the web.config.

  <add metadataUrl="http://localhost:13428/federationMetadata" allowUnsolicitedAuthnResponse="true" />

The allowUnsolicitedAuthnResponse setting applies to all identity providers in the federation. When using a federation, the certificate information of the idps must be present in the metadata, there is no way to add it manually.

Discovery Service Support

2014-09-30 21_36_20-Kentor.AuthServices Stub IdpAuthServices now has got support for using a SAML2 Discovery Service for selecting which identity provider to use when authenticating. Idp Discovery Services is an extension to SAML2. The StubIdp have also been updated with a stub discovery service that can be used either together with the StubIdp itself, or to select another Idp.

The usage of a discovery service is configured for the entire AuthServices instance through the new additional attributes discoveryServiceUrl and discoveryServiceResponseUrl on the <kentor.authServices> node.

<kentor.authServices assertionConsumerServiceUrl="http://localhost:17009/SamplePath/Saml2AuthenticationModule/Acs"

Http Redirect Binding Preferred

When loading configuration from metadata multiple bindings are often offered by a single Idp. Instead of choosing whatever binding comes first AuthServices now prefers to use the Http Redirect binding if it is offered by the Idp.

Bug Fixes

Some bugs have been fixed as well.

  • Fixed incorrect casing of entityID in the service provider metadata.
  • Fixed SAMLRequest query string not always being correctly URL Encoded when redirecting to Idp.
  • Fixed invalid format of cacheDuration in service provider and StubIdp metadata.
  • Fixed null reference exception on missing discoveryServiceResonseUrl in configuration.


There are quite a huge number open issues for AuthServices, so there is no lack of work to do.

Up next to add is functionality for refreshing Idp and federation metadata based on the validUntil and cacheDuration attributes in the metadata. This will allow a service provider to automatically discover and use new identity providers while running. We are also planning to extend the service provider metadata with some more information.

Another major effort will be to redesign the entire configuration system. The configuration options in the web.config will be simplified. A base Url for AuthServices will be used to generate all other Urls of the service provider. The base Url will even have a sensible default value of AuthServices meaning that it in most cases can be completely left out. This change will not only make it more simple to configure but also reduce the possibilities to mix incompatible configuration options.

The new configuration options will also give possibilities to keep the configuration entirely in code, leaving the web.config behind. This will make the owin middleware more well behaved as well as offering better support for integrating AuthServices in applications where the configuration is dynamically loaded from e.g. a database.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.