Kentor.AuthServices SAML2 Owin Middleware Released
I just pushed the first version of our Owin SAML2 middleware to nuget and github as part of Kentor.AuthServices 0.5.2. Kentor.AuthServices is a SAML2 Service Provider implementation for ASP.NET, offering an HTTP Module, drop in MVC controllers and (now) an Owin middleware. The intention with the library is to approach SAML2 from a .NET perspective, making a component that fits seamlessly into the existing .NET security infrastructure.
Kentor.AuthServices is now made up of four main packages.
- The core Kentor.AuthServices library which contains all the SAML2 functionality and the classic http module. The library exposes a public API for working with SAML2 authentication requests and responses, that can be used to e.g. build an identity provider.
- The Kentor.AuthServices.Mvc library which is a drop in MVC controller that enables SAML2 authentication to an MVC application without writing a single line of code. Just install the nuget package and add the needed configuration to web.config to get going.
- The Owin middleware that offers SAML2 authentication in the same way as existing providers for external authentication (e.g. Google, Facebook) and integrates with ASP.NET Identity.
- The Stub idp for testing, that is available for free and answers to any incoming AuthnRequests.
All the source is hosted in a GitHub repo, including sample applications.
What’s new in 0.5.2?
There are three major improvements in 0.5.2 over previous versions.
- Basic Service Provider metadata with the data that is mandatory according to the SAML2 specification is generated and published.
- There is now support for one instance of AuthServices to work with multiple identity providers. This is a first step on the road to full federation support.
- We’ve created a brand new owin middleware that is compatible with ASP.NET Identity and works the same way as existing external authentication providers such as Google and Facebook.
For the full list of implemented features, please see the GitHub Milestone for 0.5.0
The Road Ahead
We’re not done yet, there is more to do on the way to a 1.0 release. The features that are planned to be implemented next relates to federation support.
- Reading and handling of Idp metadata, enabling a relation to an idp to be configured by just stating the Idp’s metadata address in the configuration.
- Reading and handling of federation metadata, enabling a relation to a number of idps to be configured by just stating the federation’s metadata in the configuration.
- Handling of discovery services for federation, enabling choosing of the idp to use through an external discovery service.
The long term goal is to make the service provider compatible with the SP Lite features in section 3.2 in the Conformance Requirements.
All the details on the development decisions and discussions are available in our GitHub issue list.
Right now, the configuration for AuthServices is done in the
app.config) file. That is the case also for the owin middleware, which is not the same as how other owin middleware works. Looking at other middleware, using
web.config looks like a legacy approach. I’m not completely convinced by putting the configuration in code though, mostly because the way we use AuthServices at Kentor we need separate configurations for different environments – a perfect fit for
web.config files. There are probably scenarios though where offering a code based approach would be required, such as if including AuthServices in a product that offers configuration in a user interface and saves it somewhere else than in the
If you have any opinions on the configuration, please take part of the discussion in issue #101 on GitHub.
Danfer Habed López on 2015-08-05
Great article and product you have built at Kentor. We are currently using the SAML 2.0 middleware with success to integrate external IdP.
I have a question, for the Sign out we are using:
And this effectively signs the user out not allowing access to any authorized page. Nevertheless, if user clicks the sign in button again, it will be logged in with the last authorized user. Of course, if close browser an open again user will be asked for username and password. There is any option at the middleware to tell the IdP to always show log in page?
Anders Abel on 2015-08-09
There is a proper single sign out implementation on the way, see Pull Request #217. With that implemented, a sign out from the SP will also cause a sign out on the Idp.
Danfer Habed Lopez on 2015-08-13
Thanks Anders, we look forward for the sign out solution. In the meantime we are making use of the IdP sign out URL (plus SP sign out).
Francis Dhaenens on 2015-08-27
Hi Danfer and Anders,
I am currently using the Kentor library as well to implement a service provider for an application. This application is a webforms ASP.NET application. I’m currently struggling to complete the signout procedure. Could you specify which is the IdP sign out URL (plus SP sign out) you are referring to?
Thanks in advance,
Anders Abel on 2015-08-28
The pull request with single sign out is still not merged, so for now the only way to sign out is to do a local signout. If you create a new web project and choose individual accounts you will get sample code that you can copy to do that.