Nicolas Guelpa's Blog

ASP.NET Identity passwords requirements configuration

Sun, 30 Dec 2018 00:00:00 +0000

Using ASP.NET Core Identity is great out of the box to manage users in a web app. The default configuration give pretty standard requirements for passwords when users are creating accounts.

The most simple way to change the settings can be found in the documentation

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddIdentity<ApplicationUser, IdentityRole>();
    
        services.Configure<IdentityOptions>(options =>
        {
            // Default Password settings.
            options.Password.RequireDigit = true;
            options.Password.RequireLowercase = true;
            options.Password.RequireNonAlphanumeric = true;
            options.Password.RequireUppercase = true;
            options.Password.RequiredLength = 6;
            options.Password.RequiredUniqueChars = 1;
        });
    }
}

This is great and will be enough in many cases. You could also move the settings in a seperate method to avoid cluttering the ConfigureServices method.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
         services.AddIdentity<ApplicationUser, IdentityRole>(SetIdentityOptions);
    }

    private static void SetIdentityOptions(IdentityOptions options)
    {
        options.Password.RequireDigit = true;
        options.Password.RequireLowercase = true;
        options.Password.RequireNonAlphanumeric = true;
        options.Password.RequireUppercase = true;
        options.Password.RequiredLength = 6;
        options.Password.RequiredUniqueChars = 1;
    }
}

Now if we want to make something a bit more complex, for example making sure that the password doesn’t contain the username, we’ll have to implement the IPasswordValidator interface.

public class MyPasswordValidator : IPasswordValidator<ApplicationUser>
{
    public Task<IdentityResult> ValidateAsync(UserManager<ApplicationUser> manager, ApplicationUser user, string password)
    {
        return Task.FromResult(Validate(user, password));
    }

    private IdentityResult Validate(ApplicationUser user, string password)
    {
        if (password.Contains(user.UserName, System.StringComparison.OrdinalIgnoreCase))
        {
            return IdentityResult.Failed(new IdentityError
            {
                Code = "UserNameInPassword",
                Description = "Passwords cannot contain the account's username"
            });
        }

        return IdentityResult.Success;
    }
}

We also need to set it up in the Startup.cs to have it called on password validation.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
         services
            .AddIdentity<ApplicationUser, IdentityRole>()
            .AddPasswordValidator<MyPasswordValidator>();
    }
}

This works and is easy enough to put together but what if we want to have all of our password validation in one place to make maintenance easier? For example, let’s add the length validation to our MyPasswordValidator class.

public class MyPasswordValidator : IPasswordValidator<ApplicationUser>
{
    public Task<IdentityResult> ValidateAsync(UserManager<ApplicationUser> manager, ApplicationUser user, string password)
    {
        return Task.FromResult(Validate(user, password));
    }

    private IdentityResult Validate(ApplicationUser user, string password)
    {
        if (password.Length < 6)
        {
            return IdentityResult.Failed(new IdentityError
            {
                Code = "PasswordTooShort",
                Description = "Passwords must be at least six characters"
            });
        }

        if (password.Contains(user.UserName, System.StringComparison.OrdinalIgnoreCase))
        {
            return IdentityResult.Failed(new IdentityError
            {
                Code = "UserNameInPassword",
                Description = "Passwords cannot contain the account's username"
            });
        }

        return IdentityResult.Success;
    }
}

Now if you run this code and send the password pass123, you will get a validation error saying that you must provide a password with at least 8 characters. This is because the default validator still runs when you use the AddPasswordValidator to set up your custom validator.

Let’s find out why.

When we call AddIdentity in our Startup class, it is actually an extension method calling a bunch of other methods (as you can see here https://github.com/aspnet/AspNetCore/blob/master/src/Identity/src/Identity/IdentityServiceCollectionExtensions.cs#L38). But the one that is of interest to us is services.TryAddScoped<IPasswordValidator<TUser>, PasswordValidator<TUser>>(); This method is trying to register the default PasswordValidator into the services if it isn’t already present.

Knowing that, it’s easy to skip the default validation. Registering the IPasswordValidator before the AddIdentity method does it will do the trick.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.TryAddScoped<IPasswordValidator<ApplicationUser>, MyPasswordValidator>();
        
        // This line must come after
        services.AddIdentity<ApplicationUser, IdentityRole>();
    }
}

We have basically replaced AddPasswordValidator so we do not need it anymore. We actually could not use it for this purpose since it’s an extension method for the IdentityBuilder type.

The C# parameterless default constructor - second edition

Wed, 25 Apr 2018 23:00:00 +0000

Back in 2015 I wrote an article about the C# default parameterless constructor and how it goes away if you write one with default values for the parameters.

I have since seen this behavior more and more and I actually spent more time understanding what was going on.

It turns out that my assumption was wrong (see the older article) and the explanation is actually simpler:

When a default value is set to a parameter, it is actually replaced at compile time where the calls don’t set the parameters.

So now the IL looks like you wrote the code by setting the default values where you call the empty construcors/methods.

We will take the following example:

class Foo
{
    private readonly int _bar;

    public Foo(int bar = 22)
    {
        _bar = bar;
    }
}

Fairly straight forward example. Let’s look at the IL for the constructor:

.method public hidebysig specialname rtspecialname 
        instance void  .ctor([opt] int32 bar) cil managed
{
  .param [1] = int32(0x00000016)
  // Code size       16 (0x10)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  call       instance void [System.Runtime]System.Object::.ctor()
  IL_0006:  nop
  IL_0007:  nop
  IL_0008:  ldarg.0
  IL_0009:  ldarg.1
  IL_000a:  stfld      int32 sandbox_console.Foo::_bar
  IL_000f:  ret
} // end of method Foo::.ctor

What’s going on here? Well, the CLR is given a hint that the parameter bar is optionnal with [opt]. And the default value is given on the following line: .param [1] = int32(0x00000016) (0x00000016 is 22 in base 10)

As we can see, the compiler does not create a new parameterless constructor calling the other one with the default value.

The reason was explained by Eric Lippert over here (the 4 posts are definitely worth a read): https://blogs.msdn.microsoft.com/ericlippert/2011/05/16/optional-argument-corner-cases-part-three/

I already mentionned how it was kind of annoying with AutoMapper (in the previous article) and I actually have a case that I run into more often that is equally annoying.

Let’s say you have a class like this:

class ItemFactory<T> where T : new()
{
    public T GetNewItem()
    {
        return new T();
    }
}

The IL for the GetNewItem method will look like this:

.method public hidebysig instance !T  GetNewItem() cil managed
{
  // Code size       11 (0xb)
  .maxstack  1
  .locals init (!T V_0)
  IL_0000:  nop
  IL_0001:  call       !!0 [System.Runtime]System.Activator::CreateInstance<!T>()
  IL_0006:  stloc.0
  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end of method ItemFactory`1::GetNewItem

As you can see, the compiler is also using the Activator.CreateInstance<T>() (because new T() wouldn’t be correct) in this case so the parameterless constructor is required. (it wouldn’t let you compile if it wasn’t the case anyway since the constraint new() forces you to have a parameterless public constructor).

I’ll write the next few articles about features I wish C# was handling differently.

Setup Travis CI to compile a .NET CORE project, run the tests and package it for NuGet

Mon, 15 Jan 2018 00:00:00 +0000

3 years ago, I wrote a short post about setting up Travis CI with .Net 4.5 (including running the tests with NUnit) and now is time for an update.

I have upgraded the library in the example (MTAServiceStatus on Github) and it is now targeting .NET Standard. The test framework this time around is xUnit (MSTest is still not supported with Travis).

The Travis CI configuration file is now pretty straigthforward and looks like this:

1
2
3
4
5
6
7
8
9
10
language: csharp
mono: none
dotnet: 2.0.0

install:
- dotnet restore

script:
 - dotnet build
 - dotnet test MTAServiceStatus.Tests/MTAServiceStatus.Tests.csproj

The only part that might requires an explanation is mono: none. By default Travis uses the latest mono release but we do not need it anymore with .NET Core. Setting mono: none tells Travis CI to disable it and on the next line we can set the version of the .NET Core SDK that we want to use: dotnet: 2.0.0. All the information about this requirement is here: https://docs.travis-ci.com/user/languages/csharp/#.NET-Core.

Since setting up Travis CI was easier than last time, I took the opportunity to setup AppVeyor to package the library and upload it to NuGet. It will also create a release in GitHub with a zip archive of all the build files and a copy of the NuGet package. This is a little bit more involved than setting up only the Travis CI process but you can find all the information below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
version: 1.0.{build}
skip_tags: true
image: Visual Studio 2017
configuration: Release
dotnet_csproj:
  patch: true
  file: '**\*.csproj'
  version: '{version}'
  package_version: '{version}'
  assembly_version: '{version}'
  file_version: '{version}'
  informational_version: '{version}'
before_build:
- cmd: nuget restore
build:
  publish_nuget: true
  verbosity: minimal
deploy:
- provider: NuGet
  api_key:
    secure: buTns+OxOaxT6NLivjBNcBXweOlxv9y512TP605PAE0OQRhUzjv4B99Suga/R5Eq
  on:
    branch: master
- provider: GitHub
  tag: v$(appveyor_build_version)
  release: v$(appveyor_build_version)
  auth_token:
    secure: ocqFamtfZzSNeNzuwUODEg8Xvjtgsui2P1ban6Gm4UMBpisfJkqVYScfYb7UPRCC
  artifact: /.*\.nupkg/
  on:
    branch: master

I’m using the version number from AppVeyor which is increased every time a build is triggered. You’ll find all the information about the settings here: https://www.appveyor.com/docs/.

I also had to switch from setting the parameters up in the web interface to using a yaml configuration file to get everything working.

ASP.NET Core MVC and Service Fabric

Wed, 22 Nov 2017 00:00:00 +0000

Hosting a website in service fabric has many advantages but it comes with a cost: you need to build your code around it which ties your project to the hosting plateform.

Once your project depends on the Service Fabric sdk, you will need a local cluster even just to debug the project. This is less than ideal, specialy when your frontend developers need to make changes and they run on a system that doesn’t work with Service Fabric… And having your project depend on the hosting plateform becomes a problem if you have to switch to a different one.

Starting with the version 6 of the sdk, you can create a Service Fabric project that runs exclusively on .net core 2.0 It will help a lot to solve the issue but it doesn’t remove the requirement for a local cluster to run the project on your machine.

We are going to solve this issue by separating the hosting from the actual ‘real’ project.

Let’s start by creating a ASP.NET Core MVC project using the version 2.0 of the framework:

If you start the app you should get the default standard template:

The idea here, is that we will be using this project as a regular ASP.NET Core MVC project. So that when someone without the Service Fabric SDK wants to run the project, they can. That’s where all our ‘real’ code will live. It doesn’t mean that all your business logic must be in this project, it only means that this will be the main project for the website.

We can now create a folder Hosting in our solution that will contain all the hosting related projects:

Now is time to add the Service Fabric project. We will choose a Stateless Service:

We can choose an empty template since it will ve replaced by our MyWebApplication anyway:

Now if you run the MyWebApplication.ServiceFabric in debug, you should see the “Hello World” defaut app we just created:

As a side note, you could definitely use a Guest Executable (even using a .cmd to avoid having to compile against a plateform) and be pretty much done.

But this comes with a few disadvantages versus using a stateless service (not an exhaustive list):

You will need to publish the web project before publishing the service fabric one (one more step)
Debugging once running in service fabric will be more complex
Using the configuration from Service Fabric would not be as easy

We will now add the reference to the ‘real’ project and use its Startup class.

Right click on the MyService -> Dependencies -> Add Reference...:

A little bit of cleaning will make everything easier to read and maintain. You can remove the Startup.cs file and the wwwroot folder from the MyService project.

At this point, if you run MyWebApplication it will still work of course. But if you want to run it through Service Fabric…you will need to follow a few more steps.

First, we have to make sure that the Views and wwwroot from MyWebApplication folders make their ways into the MyService project.

We will be using Link content to avoid having multiple copies of the same files/folders:

<ItemGroup>
  <Content Include="..\MyWebApplication\Views\**\*.*" Link="Views\%(RecursiveDir)%(Filename)%(Extension)">
    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
  </Content>
  <Content Include="..\MyWebApplication\wwwroot\**\*.*" Link="wwwroot\%(RecursiveDir)%(Filename)%(Extension)">
    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
  </Content>
</ItemGroup>

You can definitely add more than just this two folders and even files (for example the appsettings.json could be a good candidate if you don’t use the Service Fabric settings).

We also need to update the the folder where the web host is going to be looking for the content (this is only if you want/need debug for the Service Fabric project) in the MyService.cs file:

return new WebHostBuilder()
            .UseKestrel()
            .ConfigureServices(services => services.AddSingleton(serviceContext))
            // this is where you have to update the content folder
            // if you want/need debug for Service Fabric
            .UseContentRoot(AppDomain.CurrentDomain.BaseDirectory)
            .UseStartup<Startup>()
            .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
            .UseUrls(url)
            .Build();

One last step that will be required, is to make sure that the file containing the depedencies to your MyWebApplication project is copied over to the other projects. This is the deps.json file, and as far as I know, this is currently a bug and these steps will probably not be needed once it’s fixed.

Edit the MyService.csproj file and add this section:

<!--
  Work around https://github.com/NuGet/Home/issues/4412. MVC uses DependencyContext.Load() which looks next to a .dll
  for a .deps.json. Information isn't available elsewhere. Need the .deps.json file for all web site applications.
-->
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
  <ItemGroup>
    <DepsFilePaths Include="$([System.IO.Path]::ChangeExtension('%(_ResolvedProjectReferencePaths.FullPath)', '.deps.json'))" />
  </ItemGroup>
  <Copy SourceFiles="%(DepsFilePaths.FullPath)" DestinationFolder="$(OutputPath)" Condition="Exists('%(DepsFilePaths.FullPath)')" />
</Target>

You’ll also need this section in the MyWebApplication.ServiceFabric.sfproj:

<!--
  Work around https://github.com/NuGet/Home/issues/4412. MVC uses DependencyContext.Load() which looks next to a .dll
  for a .deps.json. Information isn't available elsewhere. Need the .deps.json file for all web site applications.
-->
<Target Name="AfterPackage" AfterTargets="Package">
  <ItemGroup>
    <DepsFilePaths Include="$([System.IO.Path]::GetDirectoryName('%(_ResolvedProjectReferencePaths.FullPath)'))\*.deps.json" />
  </ItemGroup>
  <Copy SourceFiles="@(DepsFilePaths)" DestinationFolder="$(PackageLocation)\MyServicePkg\Code" />
</Target>

Note that in the second file, you need to specify the DestinationFolder with the name of the project we created earlier.

And that’s it, you should now be able to run your project in Service Fabric both in debug mode and published:

Of course this will work for a local cluster as well as a hosted one.

So here you have it:

MyWebApplication contains all your important code and can run anywhere .NET Core 2.0 is available
MyService is the stateless service application referencing MyWebApplication
MyWebApplication.ServiceFabric contains the artifacts for publishing the MyService project to a Service Fabric cluster

You can find the source code of the solution here: https://github.com/cheesemacfly/ServiceFabricWebApplication

I hope this makes sense and that it will be useful for people who want to use Service Fabric but do not want to commit 100% to it.

Google Tag Manager and React/Redux

Sun, 30 Jul 2017 00:00:00 +0000

The Google Tag Manager dataLayer is one of the nicest thing when it comes to analytics for the developers. But there’s one major issue when you start having custom dimensions: you need to reset the dataLayer between your pages or you will be sending the same data for a specific propery over and over again.

Let’s take for example the following dataLayer:

dataLayer.push({
  userType = 'customer',
  productType = 'food',
  foodName = 'burger'
});

And now your user goes to the next page that is not a product of type food anymore:

dataLayer.push({
  userType = 'customer',
  productType = 'drink'
});

If your page hasn’t been reloaded between the 2 push(), the following data will be sent to Google Tag Manager:

{
  userType = 'customer',
  productType = 'drink',
  foodName = 'burger'
};

This will not be an issue if your website isn’t a single page app (each page reload will flush the dataLayer since it gets recreated) but it can be a huge problem if you build your website using react and redux which are commonly used for single page applications.

I’ll show you how to create and use a middleware that solves this issue using a hidden method of the GTM library.

First we have to find a way to reset the dataLayer. The Google documentation is not helpful here…so I reached out to Simo Ahava on Twitter to get the answer:

google_tag_manager[“GTM-XXXX”].dataLayer.reset() will clear GTM’s internal data model.
— Simo Ahava (@SimoAhava) January 24, 2017

We are going to create a very simple reducer to handle the data that we want to push to the dataLayer.
It will handle 3 cases:

adding data to the state (ADD_TO_DATALAYER)
adding data and pushing it to the gtm dataLayer (PUSH_TO_DATALAYER)
reseting the gtm dataLayer (RESET_DATALAYER)

Here’s the reducer contained in one file:

export const Types = {
  ADD_TO_DATALAYER: 'app/analytics/ADD_TO_DATALAYER',
  PUSH_TO_DATALAYER: 'app/analytics/PUSH_TO_DATALAYER',
  RESET_DATALAYER: 'app/analytics/RESET_DATALAYER'
};

const DEFAULT_STATE = {
  dataLayer: null
};

export default function reducer(state = DEFAULT_STATE, action = {}) {
  switch (action.type) {
    case Types.ADD_TO_DATALAYER:
      return {
        ...state,
        dataLayer: {
          ...state.dataLayer,
          ...action.data
        }
      };
    case Types.RESET_DATALAYER:
      return {
        ...state,
        dataLayer: null
      };
    default:
      return state;
  }
}

export const addToDataLayer = (data = {}) => {
  return {
    type: Types.ADD_TO_DATALAYER,
    data
  };
};

export const pushToDataLayer = (data = {}) => (dispatch) => {
  dispatch(addToDataLayer(data));
  return dispatch({
    type: Types.PUSH_TO_DATALAYER
  });
};

export const resetDataLayer = () => {
  return {
    type: Types.RESET_DATALAYER
  };
};

export const getDataLayer = (state) => {
  return state.dataLayer;
};

Now that we have a way to reset the dataLayer and our reducer we can move on to our next step: creating a middleware.

import { Types, getDataLayer } from 'app/redux/analytics'; //assuming this is the path to the reducer we just created

// the name of the container for GTM, usually 'dataLayer'
const DATA_LAYER_CONTAINER = 'dataLayer';

const _dataLayer = window[DATA_LAYER_CONTAINER] || [];
const _gtm = window.google_tag_manager['GTM-XXXX']; //replace with your container Id

export default ({ getState }) => {
  return (next) => (action) => {
    const returnValue = next(action);

    if (action.type === Types.PUSH_TO_DATALAYER) {
      _dataLayer.push(getDataLayer(getState()));
    } else if (action.type === Types.RESET_DATALAYER) {
      _gtm[DATA_LAYER_CONTAINER].reset();
    }

    return returnValue;
  };
};

The last step will be to plug in the middelware:

//somewhere in the file that creates your store
const store = applyMiddleware(analyticsMiddleware/*, thunk, routerMiddleware...*/)(createStore)(myReducer);

This is not a complete solution and using an undocumented feature from Google Tag Manager can be risky but it does work. Also note that you can simplify the reducer even more if you only use action creators and types (skipping the state).
I’m also not including the interaction with React but it should be pretty straight forward following the doc: http://redux.js.org/docs/basics/UsageWithReact.html

.NET Core LDAP authentication

Wed, 15 Feb 2017 00:00:00 +0000

.NET Core unfortunately doesn’t yet come with a native LDAP implementation…but you can use a third party library that will do the job for you: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

We will see how to integrate this third party library with a .NET Core website to authenticate the users with the cookie middleware and make the website only accessible to authenticated users members of the “Admins” group.

We are going to first create a very simple user class and an interface for the authentication service:

public class AppUser
{
    public string DisplayName { get; set; }
    public string Username { get; set; }
    public bool IsAdmin { get; set; }
}

public interface IAuthenticationService
{
    AppUser Login(string username, string password);
}

The goal is to be able to use the IAuthenticationService later in our DI container and inject our LDAP implementation.
We will also assume that you have a configuration object defined as follow (example of the corresponding json format at the end):

public class LdapConfig
{
    public string Url { get; set; }
    public string BindDn { get; set; }
    public string BindCredentials { get; set; }
    public string SearchBase { get; set; }
    public string SearchFilter { get; set; }
    public string AdminCn { get; set; }
}

If you need more information about the configuration object I would recommend this part of the official documentation: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration#using-options-and-configuration-objects

Next we create the LDAP implementation for this service inspired by this example from the repository:

class LdapAuthenticationService : IAuthenticationService
{
    private const string MemberOfAttribute = "memberOf";
    private const string DisplayNameAttribute = "displayName";
    private const string SAMAccountNameAttribute = "sAMAccountName";

    private readonly LdapConfig _config;
    private readonly LdapConnection _connection;

    public LdapAuthenticationService(IOptions<LdapConfig> config)
    {
        _config = config.Value;
        _connection = new LdapConnection
        {
            SecureSocketLayer = true
        };
    }

    public AppUser Login(string username, string password)
    {
        _connection.Connect(_config.Url, LdapConnection.DEFAULT_SSL_PORT);
        _connection.Bind(_config.BindDn, _config.BindCredentials);

        var searchFilter = string.Format(_config.SearchFilter, username);
        var result = _connection.Search(
            _config.SearchBase,
            LdapConnection.SCOPE_SUB,
            searchFilter,
            new[] { MemberOfAttribute, DisplayNameAttribute, SAMAccountNameAttribute },
            false
        );

        try
        {
            var user = result.next();
            if (user != null)
            {
                _connection.Bind(user.DN, password);
                if (_connection.Bound)
                {
                    return new AppUser
                    {
                        DisplayName = user.getAttribute(DisplayNameAttribute).StringValue,
                        Username = user.getAttribute(SAMAccountNameAttribute).StringValue,
                        IsAdmin = user.getAttribute(MemberOfAttribute).StringValueArray.Contains(_config.AdminCn)
                    };
                }
            }
        }
        catch
        {
            throw new Exception("Login failed.");
        }
        _connection.Disconnect();
        return null;
    }


}

We now add the configuration for LDAP and the LdapAuthenticationService object in the DI container:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<LdapConfig>(Configuration.GetSection("ldap"));
        services.AddScoped<IAuthenticationService, LdapAuthenticationService>();
        
        // ...
    }
}

The controler handling the user authentication will be containing 2 routes: one for login and one for logout. The view model used in this example should contain 2 fields: Username and Password.
(Make sure to include the AllowAnonymous attribute because later we will apply a default filter that will require authentication on all requests)

public class AccountController : Controller
{
    private readonly IAuthenticationService _authService;
    public AccountController(IAuthenticationService authService)
    {
        _authService = authService;
    }
    
    [HttpPost]
    [AllowAnonymous]
    public async Task<IActionResult> Login(LoginViewModel model)
    {
        if (ModelState.IsValid)
        {
            try
            {
                var user = _authService.Login(model.Username, model.Password);
                if (null != user)
                {
                    var userClaims = new List<Claim>
                    {
                        new Claim("displayName", user.DisplayName),
                        new Claim("username", user.Username)
                    };
                    if (user.IsAdmin)
                    {
                        userClaims.Add(new Claim(ClaimTypes.Role, "Admins"));
                    }
                    var principal = new ClaimsPrincipal(new ClaimsIdentity(userClaims, _authService.GetType().Name));
                    await HttpContext.Authentication.SignInAsync("app", principal);
                    return Redirect("/");
                }
            }
            catch (Exception ex)
            {
                ModelState.AddModelError(string.Empty, ex.Message);
            }
        }
        return View(model);
    }
    
    [Authorize(Roles = UserRoles.Everyone)]
    public async Task<IActionResult> Logout()
    {
        await HttpContext.Authentication.SignOutAsync("app");
        return Redirect("/");
    }
}

To setup the cookie authentication we call the UseCookieAuthentication method on the IApplicationBuilder object. We have to define our /login and /logout routes as well:

public class Startup
{
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            Events = new CookieAuthenticationEvents
            {
                // You will need this only if you use Ajax calls with a library not compatible with IsAjaxRequest
                // More info here: https://github.com/aspnet/Security/issues/1056
                OnRedirectToAccessDenied = context =>
                {
                    context.Response.StatusCode = (int)HttpStatusCode.Forbidden;
                    return TaskCache.CompletedTask;
                }
            },
            AuthenticationScheme = "app",
            LoginPath = new PathString("/login"),
            AutomaticAuthenticate = true,
            AutomaticChallenge = true
        });

        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "login",
                template: "login",
                defaults: new { controller = "Account", action = "Login" }
            );
            routes.MapRoute(
                name: "logout",
                template: "logout",
                defaults: new { controller = "Account", action = "Logout" }
            );
        });
    }
}

And finally we can use a default filter applied to all routes that will require the users to be authenticated and in the “Admins” group (unless we specify the AllowAnonymous attribute on the controller/action):

public class ApplyPolicyOrAuthorizeFilter : AuthorizeFilter
{
    public ApplyPolicyOrAuthorizeFilter(AuthorizationPolicy policy) : base(policy) { }

    public ApplyPolicyOrAuthorizeFilter(IAuthorizationPolicyProvider policyProvider, IEnumerable<IAuthorizeData> authorizeData)
        : base(policyProvider, authorizeData) { }

    public override Task OnAuthorizationAsync(AuthorizationFilterContext context)
    {
        if (context.Filters.Any(f =>
        {
            var filter = f as AuthorizeFilter;
            //There's 2 default Authorize filter in the context for some reason...so we need to filter out the empty ones
            return filter?.AuthorizeData != null && filter.AuthorizeData.Any() && f != this;
        }))
        {
            return TaskCache.CompletedTask;
        }
        return base.OnAuthorizationAsync(context);
    }
}

// and in the Startup.cs:
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // default access requires admin access
        var isAdminUserPolicy = new AuthorizationPolicyBuilder().RequireRole("Admin").Build();
        services.AddMvc(options =>
        {
            options.Filters.Add(new ApplyPolicyOrAuthorizeFilter(isAdminUserPolicy));
        });
    }
}

Lastly here’s a sample of what the LDAP section of your config file could look like:

 "ldap": {
    "url": "ldap.local",
    "bindDn": "CN=user,OU=branch,DC=contoso,DC=local",
    "bindCredentials": "secret_password",
    "searchBase": "DC=contoso,DC=local",
    "searchFilter": "(&(objectClass=user)(objectClass=person)(sAMAccountName={0}))",
    "adminCn": "CN=Admins,OU=branch,DC=contoso,DC=local"
}

.NET Core cookie authentication middleware, load balancing and the data protection system

Wed, 11 Jan 2017 00:00:00 +0000

Edited on 2017-09-21:
I have added a couple notes since the version 2.0 of .NET Core works slightly differently.

Using the .NET Core cookie authentication middleware as well as a load balanced environment usually makes the user’s authentication “reset” between server hits. That’s because the data in the cookie is encoded using a key that might only available in the server’s memory (typically in a unix environment it will be the case). So when the first server encryptes the cookie to send it back to the client it will use a key that is not shared and other servers will not be able to decrypt the cookie on subsequent calls.

You could solve this by using sticky sessions on the load balancer or by moving this key to a file system location using:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
       .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));

    // don't forget the rest of your ConfigureServices
    // for example:
    // services.AddMvc()
}

But sometimes you cannot share a directory between your web servers or you just want to use SQL to store the encryption key. And that’s exactely what we are going to do.

Before going further there is one very important point that needs to be quoted from the documentation:

If you specify an explicit key persistence location, the data protection system will deregister the default key encryption at rest mechanism that the heuristic provided, so keys will no longer be encrypted at rest. It is recommended that you additionally specify an explicit key encryption mechanism for production applications.

And since that’s what we’re doing here, your keys are going to be stored not encrypted in your database (unless you’re using .NET Core 2.0 as I’ll show at the end of this post). More information on that subject here: https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-encryption-at-rest.

With that out of the way, let’s start!

Prepare the storage

First, we need to create a table in our database that will hold the keys for our app:

CREATE TABLE [dbo].[DataProtectionKeys](
	[FriendlyName] [nvarchar](max) NOT NULL,
	[XmlData] [nvarchar](max) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

The FriendlyName field is the actual id of the key and the XmlData will contain the XML data of the key deserialized in a string.

We can now create the model matching this table in our project:

public class DataProtectionKey
{
    [Key]
    public string FriendlyName { get; set; }
    public string XmlData { get; set; }
}

And add it to the context:

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

    public DbSet<DataProtectionKey> DataProtectionKeys { get; set; }
}

Creating the repository

We can now write the repository (we must implement IXmlRepository).

That’s the most important part since that’s where the write/read actions for the keys are going to happen.

public class DataProtectionKeyRepository : IXmlRepository
{
    private readonly AppDbContext _db;

    public DataProtectionKeyRepository(AppDbContext db)
    {
        _db = db;
    }

    public IReadOnlyCollection<XElement> GetAllElements()
    {
        return new ReadOnlyCollection<XElement>(_db.DataProtectionKeys.Select(k => XElement.Parse(k.XmlData)).ToList());
    }

    public void StoreElement(XElement element, string friendlyName)
    {
        var entity = _db.DataProtectionKeys.SingleOrDefault(k => k.FriendlyName == friendlyName);
        if (null != entity)
        {
            entity.XmlData = element.ToString();
            _db.DataProtectionKeys.Update(entity);
        }
        else
        {
            _db.DataProtectionKeys.Add(new DataProtectionKey
            {
                FriendlyName = friendlyName,
                XmlData = element.ToString()
            });
        }

        _db.SaveChanges();
    }
}

Configure the app to use the new repository

Now we can simply use dependency injection to setup the new repository (in the Startup.cs file):

For .NET Core 1.x:

public void ConfigureServices(IServiceCollection services)
{
    // make sure you have the AppDbContext setup
    services.AddDbContext<AppDbContext>(
        options => options.UseSqlServer(Configuration.GetConnectionString("AppDbContext")));

    // custom entity framework key repository
    services.AddSingleton<IXmlRepository, DataProtectionKeyRepository>();

    // don't forget the rest of your ConfigureServices
    // for example:
    // services.AddMvc()
}

For .NET Core 2.x:

public void ConfigureServices(IServiceCollection services)
{
    // make sure you have the AppDbContext setup
    services.AddDbContext<AppDbContext>(
        options => options.UseSqlServer(Configuration.GetConnectionString("AppDbContext")));
    
    // custom entity framework key repository
    services.AddSingleton<IXmlRepository, DataProtectionKeyRepository>();
    
    // this part is needed in 2.0
    // I'll update the post once/if I find a better way to get the repository instance
    var built = services.BuildServiceProvider();
    services.AddDataProtection().AddKeyManagementOptions(options => options.XmlRepository = built.GetService<IXmlRepository>());

    // don't forget the rest of your ConfigureServices
    // for example:
    // services.AddMvc()
}

We are using Entity Framework to persist/retreive the data because it’s fast to setup and easy to use but you can replace the data access layer by anything else.

There’s also no exception handling or logging but that’d be a good improvement in a real world project!

Bonus for .NET Core 2.x:

There is now a ProtectKeysWithCertificate() method that can be used to encode the key before it is stored in the database. Assuming that you have a export.pfx file in the root of your project:

public void ConfigureServices(IServiceCollection services)
{
    // remember to replace the password with your real value
    services.AddDataProtection()
        .AddKeyManagementOptions(options => options.XmlRepository = built.GetService<IXmlRepository>())
        .ProtectKeysWithCertificate(new X509Certificate2("export.pfx", "password"));

    // don't forget the rest of your ConfigureServices
    // for example:
    // services.AddMvc()
}

IIS double authentication

Sun, 31 May 2015 00:00:00 +0000

Setting up double authentication for a website running on IIS 7+ running in “Integrated mode” can be a very hard task.
If you want, as an example, to have a “Basic authentication” to password protect your website and use the “Forms authentication” to allow your users to log in on this same website, it could take a lot of work.
There’s already a solution here: http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/ but it requires code changes and add dependencies to your project.

If you want to get this done by only tweaking up your server’s configuration (to password protect a stage environment for a limited time for example) there is a solution.

Before we go further, I want to be clear that this is not a pretty solution and you should not be using it on production. And even tho it doesn’t require code changes, it will most probably require that you install some IIS modules.

The general idea is that we will create a gate website to password protect the real application.
All the requests will have to go through the gate and you’ll be able to apply any authentication you want (“Basic authentication” in the following example).
Once the user has successfully authenticate, we will rewrite every request to the real website.

It only takes 5 steps to get this done:

Change the binding of your website to a port that is not being used on your server (for example 8888)
Create a second website (we will call it gate) and setup the binding so that all the traffic of your real website is directed to this one. That’s the website where you will want to setup your second authentication (usually the “Basic authentication”)
Install the “URL Rewrite” and “Application Request Routing” modules (using web platform installer makes it easy)
Enable the proxy on the ARR module (this is the key part to be able to rewrite the content)
- Open ARR from the root of the server and go into the proxy settings (from the right column in “Server Proxy Settings…”)
- Enable the proxy option (you don’t need to change the other parameters)
Add the following rewrite rule to the gate website (select the gate website, go into ‘URL Rewrite’ and select ‘Add Rule(s)…’) This will produce the following XML code in the gate website’s web.config:

<rule name="gate">
  <match url=".*" />
  <action type="Rewrite" url="http://localhost:8888/{R:0}" />
</rule>

http://localhost:8888 is your real website and {R:0} is the requested path. You can find more information about the rewrite module in the post IIS Rewrite Redirect Back-references.

This solution will get you up and running with 2 different authentications in no time and with very little requirements.
You can now have a password protected dev environment without breaking your website authentication.

uTyped Umbraco package

Thu, 23 Apr 2015 00:00:00 +0000

At Deep Focus we released our first NuGet package. It is called uTyped and it solves a problem we’ve had with many projects when using Umbraco.

When we need to have API endpoints to return parts of our data, there is no direct support from the CMS; no easy way to get a C# model mapped to the values available in the backoffice.

You could of course create a controller inheriting from UmbracoApi and then query your content with Umbraco.TypedContentAtXPath().

As fine as this solution is, the IPublishedContent object you get from your query doesn’t have strongly typed properties. You have to query them one by one providing the type and name of the property (content.GetPropertyValue<int>("ProductId")).

Definitely not ideal…

That’s where we’ve come up with a solution we have packaged in a library. Using the TypedContentAtXPath method and AutoMapper, we are able to do:

public class MyController : UmbracoApiController
{
    private readonly UmbracoRepository _repo;

    public TestController()
    {
        _repo = new UmbracoRepository(Umbraco);
    }

    public IEnumerable<Product> GetAll()
    {
        return _repo.GetAll<Product>();
    }

    public Product Get(int id)
    {
        return _repo.GetById<Product>(id);
    }
}

Granted you have setup AutoMapper using the provided profile:

protected override void ApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
{
    Mapper.AddProfile<UmbracoProfile<Product>>();
}

And of course created your expected model where the properties name match those setup in the backoffice:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string ShortName { get; set; }
}

This is a fairly simple example but the library can do much more so make sure to check out the documentation: https://github.com/DeepFocus/uTyped.

The C# parameterless default constructor

Sun, 29 Mar 2015 22:00:00 +0000

There’s not many things in C# that I wish were different, but this is one of them. If you define a class, it comes with a default parameterless constructor if you don’t define one:

Unless the class is static, classes without constructors are given a public default constructor by the C# compiler in order to enable class instantiation.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/using-constructors

So this class:

public class Foo
{
    private string Bar;
}

is equivalent to this one:

public class Foo
{
    private string Bar;
    public Foo() : base() { }
}

So far so good. Now if you have a constructor with a parameter taking a default value, this rule doesn’t apply anymore.

In the following example, the parameterless contructor is not automatically provided:

public class Foo
{
    private string Bar;
    public Foo(string bar = null)
    {
        Bar = bar;
    }
}

In most cases, you would be creating an instance using new as in var foo = new Foo() and shouldn’t care much about the missing default constructor. But if you are using reflection as in var o = Activator.CreateInstance(typeof(Foo));, you will be out of luck. Doing so will give you a System.MissingMethodException, No parameterless constructor defined for this object.

This is a problem I often run into when creating a custom resolver for AutoMapper (implementing the IValueResolver interface) for example.

Your only option is to recreate the parameterless constructor:

public class Foo
{
    private readonly string Bar;
    public Foo(string bar = null)
    {
        Bar = bar;
    }
    public Foo() : this(null) { } //default constructor
}

The reasoning behind this is probably that the default parameterless constructor calls the base class one and for consistency it shouldn't call anything else (because this is how it was defined). Still would be a nice to have...

Updated in April 2018:

I have posted a new post about why the last line was actually a wrong assumption. You can read it here.