When creating Kentor.AuthServices the goal was to create a solution that as seamlessly as possible integrates with the security model of ASP.NET. This is a comparison of Kentor.AuthServices and Shibboleth, the existing open source solution that seems to be mostly used.
When I decided to write my own service provider for .NET I had done some research on ASP.NET and SAML2 and mostly found references to commercial packages, or to alternatives such as setting up an ADFS server to bridge between SAML2 and WsFederation that’s supported natively by .NET. To be honest, I hadn’t found Shibboleth but was made aware of it about a month later. My first reaction was “oh no, have I wasted my time writing something that already exists”, but when looking deeper, I don’t think I did waste any time, but rather have come up with something that is better from a .NET perspective.
With EntityFramework’s support for enums, there is no longer any need to include lookup tables in the model. But I do want to have them in the database for integrity, even with code first.
I’ve been thinking for some time about to handle enums with code first. The idea behind code first is to be able to write the code as close as possible to how object oriented code is normally written. For enums that means that the enum definition itself is the constraint that is used to ensure that only valid values are used in the code.
For databases it would be possible to use a column constraint, but the normal way is to use a lookup table where the valid values are present. Any column in the database mapped against the enum type is then a foreign key to the lookup table to ensure integrity of the data.
What I would prefer is a solution where the lookup table is present in the database, but not mapped against any entity in the code.
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
With .NET 4.5 a new base class for identities was introduced: the ClaimsIdentity class. The reason is that Windows Identity Foundation has been fully incorporated into the .NET framework and it has really improved the .NET identity model.
What is a Claim?
This might be a stupid question – but I’ve had a hard time to find a definition on what a claims identity is that feels natural. (It might be a language issue as I’m not a native English speaker and find the word claim somewhat hard to translate properly to Swedish).
I prefer to explain a claim as a piece of fact. A claims identity is a set of claims or facts, bundled together in an identity. Each claim is made up of a key and a value. An example identity for me could contain these claims:
| Type |
Value |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name |
Anders |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname |
Abel |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
[email protected] |
So far this is just a set of claims or facts. Being structured as a list of keys and values, it can contain pretty much whatever you want. In this case I’ve used the wellknown types for standard parameters, but you can define your own too. Thanks to the flexible structure, any kind of identity can be expressed as a claims identity. It is not only possible – it is used! The old identity classes have all been rewritten to inherit from the new ClaimsIdentity class.
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?
