The knowledge base blog

Using cloudscribe with Identity Server 4 with a SQL Server store on .Net Core 2 MVC securing APIs

() — Fri, 03 Nov 2017 22:14:00 GMT

Well that’s a bit of a mouthful of a title – but it does describe what I was trying to do, and I didn’t find it easy. It’s not that complicated when you know how, but there are an awful lot of options and it wasn’t clear (to me at least) which ones to pick, so I hope this saves others some time.

Aim

I wanted a cloudscribe site running allowing users to be able to logon as usual using cookies, but I also wanted to have an API that could be secured for clients external to the site without having to use the cookie login and I wanted to use Identity Server 4 with a SQL data store.

Starting setup

Server

I used Joe Audette's excellent cloudscribe Visual Studio template https://www.cloudscribe.com/blog/2017/09/11/announcing-cloudscribe-project-templates and selected use MSSQL Server and the Include Identity Server integration option. Also selecting the 2 options in the “Expert Zone” gave me an example API to test with.

This gave me the basic website and was the one I wanted to add the secured API into. The VS project has a weather forecast API as an example.

Client

I then setup a separate MVC project using a basic template to act as the client application. This was all done using Visual Studio 2017 and .Net Core 2.

Server application

By default, the weather forecast API is accessible to all users. Try: http://localhost:35668/api/SampleData/WeatherForecasts

You can secure this by adding the [Authorize] statement to the API on the SampleDataController.cs page e.g.

[Authorize]
[HttpGet("[action]")]
public IEnumerable WeatherForecasts()
{
    var rng = new Random();

but you will find this presents the standard cloudscribe logon screen to access it – not exactly what’s wanted for an API.

In order to solve this we need to use JWT authorisation alongside the standard cookie authentication, but tell the API to only secure using the JWT authorisation . This is done by filtering the authentication scheme used by the Authorize statement as below (you will probably have to add the following assemblies to your code)

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Authentication.JwtBearer;

and then add the filter to the authorize statement.

[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
[HttpGet("[action]")]
public IEnumerable WeatherForecasts()
{
    var rng = new Random();

We have now told the API to authenticate using JWTBearer but we haven’t yet added JWT authentication to our applications pipeline. So in the startup.cs page we need to add in some assemblies:

using Microsoft.AspNetCore.Authentication.JwtBearer;

and then add the JWT service into the ConfigureServices method. (I added the statement below just above services.AddCors(options =>)

services.AddAuthentication(options =>
{
    options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
})

.AddJwtBearer(options =>
{
    options.Authority = "http://localhost:35668"; //No trailing /
    options.Audience = "api2"; //Name of api
    options.RequireHttpsMetadata = false;

});

Where:

.Authority is the address of the website with the api (note no trailing slash)

.Audience is the name you have given to the api in the Identity server 4 security setup (see more details below)

And then we need to tell our pipeline to use Authentication. So add the app.UseAuthentication() into the end of the ConfigureServices method just above the UseMVC call

app.UseAuthentication();
UseMvc(app, multiTenantOptions.Mode == cloudscribe.Core.Models.MultiTenantMode.FolderName);

Now if you try and access the api - http://localhost:35668/api/SampleData/WeatherForecasts - you should get an unauthorised message - even if you are logged onto the cloudscribe site using cookie authentication.

Identity Server 4 configuration (through cloudscribe)

Identity server has many options – which can be bewildering to start with. Full documentation is here: https://identityserver4.readthedocs.io/

For our purposes here – I’m outlining the bare minimum that we need to setup security for our API, either using:

· A client credential using a secret

· A username and password

API resources

Under the admin menu in cloudscribe select security settings / API resources and create a new API record giving it a name (e.g. api2) making sure it matches the name you entered as the .Audience in the startup.cs .

Then we need to add a single scope record – called “allowapi2” in this example.

Client resources

Under the admin menu in cloudscribe select security settings / API Clients and create a new client (I’ve called it client2 – remember this name for when we make the call from the client application). Edit the new client record and add:

· Allowed Scope record – e.g. allowapi2 – this must match the scope we entered for the api and is used to specify which apis this client can access

· Client Secrets – the value is the SHA56 value of the secret we wish to use (in this example secret2) ~~– at the moment the cloudscribe interface doesn’t do this conversion for us so we have to do it manually somewhere (e.g. I used string s = "secret2".ToSha256();)~~

I added the secret using the web page and then pasted the converted secret direct into the relevant field in the record in the csids_ClientSecrets table in the database - but I think it would work equally well just pasting the converted value into the web page.

.ToSha256() is a string extension method in the IdentityModel assembly - this seems to do more than simply convert to sha256 - see https://github.com/IdentityModel/IdentityModel/blob/master/source/IdentityModel.Net45/Extensions/HashStringExtensions.cs.

~~It’s important that we set the secret type as well – in our example here it must be “SharedSecret”~~

Joe Audette has updated his nuget packages so saving a client secret now gives you a range of options for the secret type - in our example we need to pick "SharedSecret" and select to encrypt using Sha256 (see Joe's post in comments below for other options) which should make things easier.

· Allowed Grant types – we are entering “password” and “client_credentials”. These determine how we can authenticate from the client app as we see below in the next section. Password means that authentication can use a username / pwd combination (i.e. a cloudscribe login). Client_credentials means we can login using a client secret and don’t have to be a known user on the site.

Client application

To connect securely to the API using a client connection with a secret use:

var tokenClient = new TokenClient(disco.TokenEndpoint, "client2", "secret2");

To connect using a username and password use:

var tokenResponsePassword = await tokenClient.RequestResourceOwnerPasswordAsync("admin", "admin", "allowapi2");

Note that the user name is the user name not the email which can be used to login interactively.

The whole method in the controller looked something like this – the rest of the code is deserializing the JSON return from the API and putting it into an object that can be displayed on a view page

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using ESDM.Models;
using System.Net.Http;
using Newtonsoft.Json;
using IdentityModel.Client;
using IdentityServerClient.Models;
using IdentityModel;

and then

//Hosted web API REST Service base url  
string Baseurl = "http://localhost:35668";

public async Task Index()
{
    List ans = new List();
     using (var client = new HttpClient())
    {
        // discover endpoints from metadata
        var disco = await DiscoveryClient.GetAsync(Baseurl);
        var tokenClient = new TokenClient(disco.TokenEndpoint, "client2", "secret2");
        var tokenResponse = await tokenClient.RequestClientCredentialsAsync("allowapi2");

//Example getting alternative token if you want to use username / pwd 
        var tokenResponsePassword = await tokenClient.RequestResourceOwnerPasswordAsync("admin", "admin", "allowapi2");

        // call api - change for tokenResponsePassword if you want to use username / pwd
        client.SetBearerToken(tokenResponse.AccessToken);

        var response = await client.GetAsync(Baseurl + "/api/SampleData/WeatherForecasts");
        if (response.IsSuccessStatusCode)
        {
            var content =  response.Content.ReadAsStringAsync().Result;
            ans = JsonConvert.DeserializeObject>(content);
        }
        return View(ans);
    }

The model for the forecast data was:

namespace ESDM.Models
{
    public partial class WeatherForecast
    {
        public string DateFormatted { get; set; }
        public int TemperatureC { get; set; }
        public string Summary { get; set; }

        public int TemperatureF
        {
            get
            {
                return 32 + (int)(TemperatureC / 0.5556);
            }
        }
    }
}

And my view contained

@model IEnumerable

    
        @foreach (var forecast in Model)
        {
            @forecast.Summary
        }

...

Making our mojoPortal sites even more secure

crispin.flower@idoxgroup.com (Crispin Flower) — Thu, 10 Apr 2014 18:31:00 GMT

I’ve just run a couple of our mojoPortal web sites through the test on https://asafaweb.com and thought I’d write up some notes on how to get the best possible test results (and therefore presumably the most secure sites!). We are starting from a point where all the basic security measures are in place – folder permissions, custom machine key, running the site under SSL.

The tests that did not immediately pass were:

Request validation: Fail

OK so we find

But we are assured this is deliberate and acceptable in mojoPortal because, as Joe Audette explained,

validateRequest is false because we do our own validation of inputs and setting it to true causes problems/errors when posting back html content from a wysiwyg editor.

Excessive headers: Warning

So our IIS server and site are revealing several pieces of information about the technologies behind the site, and we are better concealing these http headers.

Specifically we have:

Server which can be turned off with URLscan by setting RemoveServerHeader=1 in UrlScan.ini (there are other ways, but this is by far the simplest).
X-Powered-By which can be turned off in IIS Manager: select the web site, then open HTTP Response Headers and remove this one.
X-AspNet-Version which can be suppressed by adding this attribute to the httpRuntime setting in web.config: enableVersionHeader="false" />

Secure cookies: Fail

In line with the mojoPortal documentation on SSL we already had the attribute in bold:

requireSSL="true" />

but we were still failing the test until we also added this into the system.web section:

Joe Audette said:

Adding the

So I think we were secure anyway, but it’s nice to pass the test.

Clickjacking: Warning

This was easily blocked by preventing our site from being run in an iframe. This is achieved in IIS Manager: select the web site, then open HTTP Response Headers, and add a new one as follows:

If we are using an iframe within the site, for something like a keep-alive, another value for this setting is "SAMEORIGIN" - this allows iframes in the site to host content that is within the same domain. If we want our site to be displayed in an iframe within a known other site, we can use "ALLOW-FROM uri".

View state MAC: Not tested

Not tested apparently because the viewstate is encrypted in mojoPortal, but it turns out versions of mojoPortal before 2.4.0.2 had enableViewStateMac="false" which is not what we want. This has been removed, meaning it is set to true by default, in version 2.4.0.2, but if running an earlier version we should ensure this setting has only the following attributes:

So on sites running mojoPortal 2.4.0.2 or later, no change needed.

Summary

So we needed to make two changes in web.config, remove one http header and add another one. Plus install and configure URLscan if it's not already present. These are one-off changes for a server and/or site except the web.config settings. mojoPortal upgrades generally involve overwriting the web.config, so it’s important to keep separate notes about what default settings need to be changed again after an upgrade. We always keep these notes for each site in a UpgradeNotes.config file in the root folder of the site.

* UPDATE *

Further testing of some sites with ZAP and https://securityheaders.com identified two more http headers (in italics below) that should be set to improve security. Overall the header settings can be wrapped up by including this section in system.webServer:

...

And it also pointed out that auto-complete was not disabled on the login screen (which leaves accounts vulnerable where more than one user may share a machine). This can be suppressed with the following in user.config:

Crispin Flower ...