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 open SAML2 testing (or stub) Identity Provider (Idp) at http://stubidp.kentor.se has been improved and now answers any incoming
AuthnRequests. The answer will automatically be sent to the Assertion Consumer Service URL contained in the
When working with applications using SAML2 authenticaiton we’ve found that handling authentication for the test and development environments is often troublesome. Existing Identity Providers, even if one is set up for test, requires registering of every Service Provider (i.e. web application) that is allowed to use it. Furthermore, a real identity provider provides real, controlled identities. That’s kind of the point of it, but when developing and testing, I want to be able to use a number of different accounts, without having to keep a stack of smart cards issued with with test identities on my desk.
When testing it is also a good idea to be able to trigger some errors, to verify the user experience in case the SAML response isn’t valid – what error messages is presented to the user in that case? In a real environment there will be an error eventually, confusing users. But it can be hard to trigger an error at will with a real identity provider doing it’s best to provide correct responses.
That’s why we created the Kentor.AuthServices StubIdp. The stub idp will respond to any incoming
AuthnRequest. It provides a simple form, where you can see and adjust the response before sending it. If you e.g. want to check error handling, you can reuse the same
InResponseTo id and make sure that your service provider recognizes and reject that.
The stub idp is part of the Kentor.AuthServices package, which is licensed with LGPL and hosted over GitHub. You can download and install your own local instance, or even better, help us improve the existing free instance with new features through pull requests.
I do get quite a lot of mails and phone calls from you. It is flattering to be offered new opportunities weekly, but that also means that the competition between you and the other recruiters is devastating. Fortunately for you who are reading this, there are a few quite simple things you can do that would set you apart from the rest of the lot. Oh, by the way, most of the items in this post also applies to software consultancy sales, so if you’re into consultancy sales, please continue reading.
I quite often get unsolicited mails on LinkedIn from recruiters. That’s great, because that’s what LinkedIn basically is about and as my profile on LinkedIn is quite complete it is possible to get a basic understanding of what I’m doing and what I’ve done even before sending a mail. Yet, every now and then I get a mail from a recruiter that looks something like this:
I have a very exciting opportunity for a skilled developer at XYZ corp. If you are interested in discussing this opportunity, please send me your Resume (or CV).
Those mails go straight down the drain because my LinkedIn profile already is a complete resume. So the first advice to set you a apart from the other recruiters is to actually read my profile before mailing me.
Reading my profile includes reading the “Advice for Contacting Anders” section at the bottom where I’ve actually stated quite clearly what I expect. Out of all the mails I do get, I remember the one that followed the advice. As far as I could find out, he hadn’t even read the advice. He just did what I expect because he was a professional.
So to set you apart from 80% of your competitors, just read my LinkedIn profile before mailing me. That’s quite simple, isn’t it? So let’s move on to some more advanced and slightly more demanding skills.
To reach 100% testing coverage is a dream for many teams. The metric used is code coverage for tests, but is that enough? Unfortunately not. Code line coverage is not the same as functional coverage. And it is full functional coverage that really matters in the end.
Look at a simple method that formats a string.
public static string Format(int? value)
const int defaultValue = 42;
value = defaultValue;
return "The value is " + defaultValue + ".";
There is a correct test for this method, that pass and gives 100% code coverage. Still there is a severe bug in there. Can you spot it? (If you don’t, just keep reading on, it will be obvious when another test is added later.)
Adding functionality to a library, without touching the existing code should be safe for clients, shouldn’t it? Unfortunately not, adding another overload to a library can be a breaking change. It might work when the library is updated, but suddenly break when the client is recompiled – even though no code was changed. That’s nasty, isn’t it?
When working with Kentor.AuthServices I’ve had to think through versioning more in detail than I’ve done before. When is the right time to go to 1.0? What is the difference between going from 0.8.2 to 0.8.3 or 0.9.0? When researching I found that the answer to all versioning questions is Semantic Versioning.
A version is on the form Major.Minor.Patch.
- Major is increased if there are breaking changes. The other numbers are reset.
- Minor is increased if there is added functionality that is non breaking. The patch number is reset.
- Patch is increased for backwards compatible bug fixes.
The terms breaking changes and backwards compatibile are keys to the definitions, so to use semantic versioning requires keeping tight control of what changes are breaking and not. In most cases it is quite simple, but there are a few pitfalls that I’ll explore in this post.
The background to this post is that I listened to Scott Meyers’ NDC talk Effective Modern C++ and was reminded on how C++ programmes have to keep track of all kinds of nastiness in the language that might turn into hard to track-down bugs. C# is a lot easier in many ways, with way fewer pitfalls, but sometimes I think we make it to simple to ourselves. C++ developers are often quite good at the language details because they have to. Being a C# developer it is possible to survive for much longer without knowing those details, but being ignorant of them will eventually result in nasty bugs. That eventuality will probably not happen on a lazy Tuesday morning with a lot of time to fix it. It will happen a late Friday afternoon, right before the important production deployment scheduled for the weekend…
As C# developers I think that we should have a look at the C++ community and see what we can learn from them. So let’s dive into some code and see how we can break things.