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.
- 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
<identityProviders> <add entityId="http://idp.example.com/Metadata" allowUnsolicitedAuthnResponse="true" loadMetadata="true" /> </identityProviders>
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
<federations> <add metadataUrl="http://localhost:13428/federationMetadata" allowUnsolicitedAuthnResponse="true" /> </federations>
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
AuthServices 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
discoveryServiceResponseUrl on the
<kentor.authServices assertionConsumerServiceUrl="http://localhost:17009/SamplePath/Saml2AuthenticationModule/Acs" entityId="https://github.com/KentorIT/authservices" returnUri="http://localhost:17009/SamplePath/" discoveryServiceUrl="http://stubidp.kentor.se/DiscoveryService" discoveryServiceResponseUrl="http://localhost:17009/SamplePath/Saml2AuthenticationModule/SignIn">
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.
Some bugs have been fixed as well.
- Fixed incorrect casing of
entityIDin the service provider metadata.
- Fixed SAMLRequest query string not always being correctly URL Encoded when redirecting to Idp.
- Fixed invalid format of
cacheDurationin service provider and StubIdp metadata.
- Fixed null reference exception on missing
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
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.