I’m happy to announce an open source ASP.NET SAML2 Service Provider. SAML2 is a common standard for single sign on in enterprise environments. A Service Provider in SAML2 is a web site that allows log on through SAML2 Identity Provider (IdP). Implementing a Service Provider requires issuing authentication requests (AuthnRequest) and handling the returned response.
Please check the Kentor.AuthServices tag for the latest posts and news. The information in this post is quite old and mostly outdated.
At Kentor we have seen an increase in the demand for using SAML2 authentication from our customers. When doing a recent project we didn’t find any suitable component, so we had to roll our own. Knowing that we would need to do this more times for other applications we decided to write a more general, standalone component that we can reuse in other projects. We are now also releasing it as open source for anyone to use for free.
The Kentor.AuthServices Library
The library is hosted at github and is released under an LGPL license. We chose that license because while it should be possible to use the library in closed source and commercial solutions, we want the library itself and any improvements to it to remain open source.
The core part of the library is the
Saml2AuthenticationModule IIS module that handles the authentication. In the most simple case, it is possible to add the IIS module to configuration and get federated authentication without a single line of code to write. There is a sample ASP.NET MVC application available that uses the library and shows how to call it.
The library is available on NuGet and can be installed with the following command.
PM> Install-Package Kentor.AuthServices
Cshtml files are compiled by Razor into C# files. To track down some errors (or just to understand Razor) it might be useful to examine the C# code generated.
For testing I created a small Razor view in an MVC4 project.
string someString = "somestring";
var someBool = false;
Some other text and @someString.
The easiest way to view the generated C# code is by introducing a compile error to bring up the compilation error page. I uncommented the – on line 4 (which obviously is incorrect C# code). In the bottom of the error page, there is a link to display the compilation source.
EditorEntryFor helper makes the code DRYer and opens new possibilities, such as automatic indication of required fields. A small addition in one helper method will mark all required fields in entire MVC web application.
It’s more or less standard to indicate required fields in a form with a red * next to the label. Entering them one by one in the markup is tedious. Adding them to the description text is outright wrong and will look bad if the description is used in other places, such as validation messages.
They shouldn’t need to be handled at all, since the metadata already contains a property indicating if the field is required or not. If all form entries are created in the same way as I showed in the DRYing MVC Forms with an EditorEntryFor Helper post it’s easy to automatically add a required marker whenever a form field is required.
Instead of calling
LabelFor directly, I’ve created an own helper method that checks the
IsRequired flag on the metadata.
With DevOps bringing source control to configuration files and publishing to production servers being automated – bringing both code and configuration over on the same time, the difference between code and config has become less than ever (if it even exists).
A few weeks ago I reread Mike Hadlow’s brilliant post The Configuration Complexity Clock. As I’m also in the middle of setting up publishing routines for a web application I started to think about the difference between configuration and code. The more I think about it, the less clear the difference is.
A simple attempt to differentiate them would be to look at where they are stored.
- Everything in source files that are consumed by the compiler is code.
- Everything in configuration files that are read at runtime is configuration.
Unfortunately that is not the entire truth. For example the route config in an ASP.NET MVC application is a kind of configuration – but it is done in code. The same is true for the Entity Framework Code First mappings – it is done in code (either through attributes or a fluent API), but is a kind of mapping configuration. An example of the other way around is startup configuration scripts (think of *nix
.bashrc or the old
autoexec.bat on DOS systems). It is configuration, but is run as a script.
There are definitely cases where it is not that simple to define what is configuration and what is code.
And does it really matter?
When creating forms in ASP.NET MVC I use a small helper to keep the code DRY (Don’t Repeat Yourself). The
EditorEntryFor helper creates everything needed for a form field – the label, the input and the validation.
When creating line of business applications, a huge part of the coding is often to create forms. Each form can consist of a huge number of fields and each field requires some common formatting. It’s usually quite straightforward with a few divs surrounding a
label and the
input field. Running the default MVC scaffolding tooling, that’s exactly what’s generated:
@Html.LabelFor(model => model.TopSpeed)
@Html.EditorFor(model => model.TopSpeed)
@Html.ValidationMessageFor(model => model.TopSpeed)
In my opinion that code has two severe problems:
- It’s too verbose.
- It’s repeating itself for each form field, making the class name and div structure a pain to modify.
In my projects I usually create a small helper, so the above lines of code can be replaced with one single statement:
@Html.EditorEntryFor(model => model.TopSpeed)