We all know the AI landscape is moving fast. Building a solid foundation requires more than just reading headlines—it demands hands-on experience and a guided approach to the core concepts.

For some context, I’m no stranger to Machine Learning, I remember building my first Neural Network to predict weather back at university (with some success) and even attempted to classify clinical coding data prior to modern advancements in the field. I’m very aware that due to the clients I work with my knowledge is a bit historic and my hands on experience has been limited.

To tackle this, I recently dedicated a couple of learning days to diving deep into modern AI principles. My goal was simple: build foundational AI knowledge, get hands-on experience with multiple tools (like Claude, Gemini, and CoPilot), and ultimately, produce a set of resources to help others get started.

What follows is the curated list of resources and topics that formed the backbone of this deep dive.



1. Getting Started: Foundational Knowledge

For a solid introduction, I began with a course on Agentic AI—a great entry point for anyone new to modern AI concepts. It provides a good overview of the topic with practical, non-coding-based examples.

• Course: Agentic AI for Developers (Pluralsight)

I’m very aware that not everyone uses Pluralsight, as such here is a non subscription alternative from Udermy that covers similar topics.

• Course: Intro to AI Agents and Agentic AI (Udemy)
  
  

2. Essential Modern AI Concepts

The following topics have been highlighted as crucial areas for any AI enthusiast or developer to understand. I've compiled the video resources that I've found useful and alternative text references for those that learn better from reading.

 
Model Context Protocol: An open API standard for connecting to components in an AI system.

• Videos: How to build a model context protocol
• Text Resources: Model Context Protocol: Getting Started
  

Vector Databases: Specialised databases used to store and manage vector embeddings for efficient similarity search.

• Videos: What is a Vector Database?
• Text Resources:  What is a Vector Database?
  

RAG (Retrieval-Augmented Generation): A technique linked with vector indices that improves model output by retrieving facts from external knowledge bases.

• Videos: What is RAG?
• Text Resources: What is Retrieval-Augmented Generation?
  

Prompt Patterns: Structured approaches and best practices for engineering effective prompts to guide an AI model.

• Videos: Prompt Patterns Playlist
• Text Resources: 21 Prompt Patterns You Should Know
  

Tool Use / Function Calling: The ability of an LLM to identify and execute external functions or tools to complete a request.

• Videos: Tool calling for LLMs, OpenAI function calling
• Text Resources: Function Calling Guide
  

Embeddings: Vector representations of text, images, or other data that capture their semantic meaning.

• Videos: Turning words into vectors, Embeddings
• Text Resources: What are Embeddings?
  

Context Limits / Tokenisation: Understanding the maximum amount of input an LLM can process and how text is broken down into tokens.

• Videos: Most devs don't understand how Context Windows work, Most Devs don't know how AI Tokens work
• Text Resources: The Context Window, What is Tokenization?
  

Guardrails and Safety Layers: Mechanisms and policies implemented to ensure AI systems operate safely and ethically.

• Videos: AI Guardrails, Security and AI Governance
• Text Resources: What are AI Guardrails?, AI Safety Layer Enhanced Classification

Next Steps

Building knowledge is just the first step. The true learning comes from hands-on work. My next steps involve getting Claude up on running on my local machine and diving into developing a tool idea for career monitoring—a tool that I’ve been wanting to develop for some time.

If you're on your own AI learning journey, I hope this curated list gives you some solid resources to understand the fundamentals. Happy learning!

Now for the final part of the Quest for Identity posts, how to configure an API to work with Identity Server 4.

RESTful Service configuration

Firstly let's create a new ASP.Net Web application project within our solution. Make sure it's a created with the Web API template so it can act as a RESTful service. I've named mine IS4REST. So how can we now implement IS4 Authentication within our project?

Surprisingly this is the easiest stage of the IS4 configuration process. Within the Startup class in ConfigureServices(), add in the following CORS configuration and authentication with your own port configurations:

services.AddMvc();

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
services.AddCors(options =>
{
    options.AddPolicy("default", policy =>
    {
        policy.AllowAnyHeader()
            .AllowAnyMethod()
            .AllowAnyOrigin();
    });
});

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        // base-address of your identityserver
        options.Authority = "https://localhost:44392/";

        // name of the API resource
        options.Audience = "https://localhost:44392/resources";
    });

Then enable them in the Cofiguration() call below:

 app.UseCors("default");
 app.UseAuthentication();

Finally, since this is a new project, our Identity Server needs to know about this as a client setting. Add the following to the clients' section of the Identity Server 4 Config file:

new Client 
{
    ClientId = "rest",
    ClientName = "REST API",
    AllowedGrantTypes = GrantTypes.HybridAndClientCredentials,

    RequireConsent = false,
    AllowAccessTokensViaBrowser = true,
    ClientSecrets =
    {
        new Secret("secret".Sha256())
    },

    RedirectUris = {"https://localhost:44305/signin-oidc"},
    PostLogoutRedirectUris = {"https://localhost:44305/signout-callback-oidc"},

    AllowedScopes =
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile,
        "api1"
    },
    AllowOfflineAccess = true
}

This is exactly the same as our MVC configuration except it has a different ID and we are Allowing Access Tokens through a Browser. That's all we need to do this side, over to the Angular set up using the project from the previous post.

Angular Client Set Up

We're going to need a new page and service to call our new API Service run the following:

ng g c components/api-test
ng g s shared/services/api-test

Register the component in the app module and the service in the shared providers. Then we need to fill them in with the following:

#api-test-component.ts
import { Component, OnInit } from '@angular/core';
import { ApiTestService } from '../../shared/services/api-test.service';

@Component({
    selector: 'ac-api-test',
    templateUrl: './api-test.component.html',
    styleUrls: ['./api-test.component.css']
})
export class ApiTestComponent implements OnInit {

  response: any = null;
  constructor(private _apiTestService: ApiTestService) { }

  ngOnInit() {
      this._apiTestService.GetValues().subscribe(response => {
      this.response = response;
  });
}

#api-test-component.html
<p>
    api-test works!
</p>

{{response}}

#api-test-service
import { Injectable } from '@angular/core';
import { HttpClient, HttpErrorResponse, HttpHeaders } from '@angular/common/http';
import { Observable } from 'rxjs/Observable';
import 'rxjs/add/observable/throw';
import 'rxjs/add/operator/catch';
import 'rxjs/add/operator/do';

@Injectable()
export class ApiTestService {

    apiRoot : string = "https://localhost:44329/api/"

    constructor(private _http : HttpClient) { }

    GetValues(): Observable<any> {
        return this._http.get(this.apiRoot + "values")
        .do(data => {
        })
    .catch(this.handleError);
    }

    private handleError(err: HttpErrorResponse) {
        console.log(err.message);
        return Observable.throw(err.message);
    }
}

Finally to ge tthis into a working state, lets add this new component to the router and provide a link to it on the app.component.html:

#app.component.html
<h3><a [routerLink]="['/']">Home</a> | <a [routerLink]="['/protected']">Protected</a> | <a [routerLink]="['/api-test']">API Test</a></h3>
<h1>
    {{title}}
</h1>
<router-outlet></router-outlet>

#app-route-module.ts
const routes: Routes = [
{
    path: '',
    component: HomeComponent
},
{
    path: 'protected',
    component: ProtectedComponent,
    canActivate: [AuthGuardService]
},
{
    path: 'api-test',
    component: ApiTestComponent,
    canActivate: [AuthGuardService]
},
{
    path: 'auth-callback',
    component: AuthCallbackComponent
}

Now this will work! We've successfully configured our application to call our new RESTful service. However, there is a but. We don't currently require Authorization on our api/values route. You should enable it with the [Authorize] property on the Values API class and see what happens. As expected a 401. To get it working we need to pass back our Identity Token.

Setting up an Interceptor

Now the best way to pass back our token is to use an interceptor because in general practice you'll be providing the token to multiple API calls. Our intercept will spot all API calls and ad the token to the header before sending it on its way.

Firstly add the following package to our solution.

yarn add angular2-jwt

Next up let's add some token functionality to our AuthService, they should be quite clear on what they do:

#auth.service.ts

...
public getToken(): string {
    var token = localStorage[0];
    return token;
}

public isAuthenticated(): boolean {
    // get the token
    const token = this.getToken();
    // return a boolean reflecting 
    // whether or not the token is expired
    return tokenNotExpired(null, token);
}

public collectFailedRequest(request): void {
    this.cachedRequests.push(request);
}

public retryFailedRequests(): void {
    // retry the requests. this method can
    // be called after the token is refreshed
}

With that in place, lets add our interceptors. Create new folder called interceptors and then add two files (manual process I'm afraid), jwt.interceptor.ts and token.interceptor.ts. The code for these two files is as follows:

#jwt.interceptor.ts
import 'rxjs/add/operator/do';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpEvent, HttpResponse, HttpErrorResponse } from '@angular/common/http';
import { AuthService } from '../shared/services/auth.service';
import { Observable } from 'rxjs/Observable';

export class JwtInterceptor implements HttpInterceptor {
    constructor(public auth: AuthService) {}
    intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> 
    {    
        return next.handle(request).do((event: HttpEvent<any>) => {
                if (event instanceof HttpResponse) {
                // do stuff with response if you want
                }
            }, 
        (err: any) => {
            if (err instanceof HttpErrorResponse) {
                if (err.status === 401) {
                    this.auth.collectFailedRequest(request);
                }
            }
        });
    }
}

#token.interceptor.ts
import { Injectable } from '@angular/core';
import { HttpRequest, HttpHandler, HttpEvent, HttpInterceptor } from '@angular/common/http';
import { Observable } from 'rxjs/Observable';
import { AuthService } from '../shared/services/auth.service';

@Injectable()
export class TokenInterceptor implements HttpInterceptor {
    constructor(public auth: AuthService) {}
    intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

            request = request.clone({
                setHeaders: {
                Authorization: this.auth.getAuthorizationHeaderValue()
            }
        });
        return next.handle(request);
    }
}

Have a look through the code and have a look at home it manages to add the Authentication Token to our requests. We have one final thing to do, let's add the interceptor to our app.module as a provider and import the relevant files:

#app.module.ts
Providers : [{
    provide: HTTP_INTERCEPTORS,
    useClass: TokenInterceptor,
    multi: true
}]

Give it another go with some breakpoints to see what happens but we now have our API working alongside our client. That is where I'll leave these posts now, there are a lot more areas to explore but, I hope the last three posts have provided enough information to help you hit the ground running. Cheers for reading.

The code for this here

One of my biggest day to day problems is dealing with a corporate proxy. Especially with .Net Core 2 which is not completely configurable from the appsettings.json file yet. This post is about how to configure your application to handle it.

Configurable Proxy Settings

Firstly an application will not always be working behind a proxy so we need to make it configurable. In your appsettings.json file as in the following settings:

"MyConfig": {
    "UseProxy": "true",
    "ProxyHost": "127.0.0.1",
    "ProxyPort": "3128",
}

We then need a class for these settings to map to. Create the following MyConfig class:

public class MyConfig
{
    	public bool UseProxy { get; set; }
    	public string ProxyHost { get; set; }
    	public int ProxyPort { get; set; }
	}

Now we can configure our Startup.cs class to set up our configuration parameters as an injectable. In the ConfigureServices function add the following:

public void ConfigureServices(IServiceCollection services)
    {
	....
	// Add our Config object so it can be injected
        	services.Configure<MyConfig>(Configuration.GetSection("MyConfig"));
}

Now we can inject our configuration parameters where ever we need to, using the standard dependency injection style:

private readonly IOptions<MyConfig> _config;

    public HttpProxyClientService(IOptions<MyConfig> config)
    {
	_config = config;
    }

Create an Injectable Module

Following SOLID principals we will want to create a single point of reference for anything that will need to use the proxy. Two objects that are likely to use it are the HttpClient object and HttpWebRequest object. By designing it as a service you can add your own required objects down the line. For now, create the following interface:

public interface IHttpProxyClientService
{
    	HttpClient CreateHttpClient();
    	HttpWebRequest CreateHttpWebRequest(string requestUri);
 }

And then this boilerplate class for the next sections to come.

public class HttpProxyClientService : IHttpProxyClientService
	{
    	private readonly IOptions<MyConfig> _config;

    	public HttpProxyClientService(IOptions<MyConfig> config)
    	{
        		_config = config;
    	}

    	public HttpClient CreateHttpClient()
    	{
		return null;
    	}

    	public HttpWebRequest CreateHttpWebRequest(string requestUri)
    	{
		return null;
   		}
	}

Finally, register it in the Startup ConfigureServices function:

services.AddTransient<IHttpProxyClientService, HttpProxyClientService>();

We now have an injectable Service! Now let's sort out the functions.

HttpClient

The CreateHttpClient function is quite simple, if a proxy is required, configure it, otherwise, return a normal HttpClient object. We will pull the details from the configuration and if a proxy is required we will configure the returned HttpClient object to use a HttpClientHandler. The code is as follows:

public HttpClient CreateHttpClient()
    {
    	try
        	{
            	var useProxy = _config.Value.UseProxy;
            	if (!useProxy)
            	{
                		return new HttpClient();
            	}

            	var proxyHost = _config.Value.ProxyHost;
            	var proxyPort = _config.Value.ProxyPort.ToString();

            	var proxy = new WebProxy()
            	{
                		Address = new Uri("http://" + proxyHost + ":" + proxyPort),
                		UseDefaultCredentials = true
            	};

            	var httpClientHandler = new HttpClientHandler()
            	{
                		Proxy = proxy,
            	};

            	var client = new HttpClient(handler: httpClientHandler, disposeHandler: true);
            	return client;
        	}
        	catch (Exception ex)
        	{
            	Console.WriteLine("Error: " + ex.Message);
        	}

        	return null;
    }

Now instead of creating a HttpClient object when we need one, we just use the service instead.

var httpClient = _httpProxyClientService.reateHttpClient()

HttpWebRequest

It's probably no surprise that the HttpWebRequest will work in exactly the same way except the set up is a little different. Without going into to much detail, this is the code:

public HttpWebRequest CreateHttpWebRequest(string requestUri)
    {
    	try
        	{
            	var useProxy = _config.Value.UseProxy;
            	HttpWebRequest res = (HttpWebRequest)WebRequest.Create(requestUri);

            	if (!useProxy)
            	{
                		return res;
            	}

            	var proxyHost = _config.Value.ProxyHost;
            	var proxyPort = _config.Value.ProxyPort;
            	var myproxy = new WebProxy(proxyHost, proxyPort) { BypassProxyOnLocal = false };
            	res.Proxy = myproxy;
            
            	return res;
        	}
       	catch (Exception ex)
        	{
            	Console.WriteLine("Error: " + ex.Message);
        	}

        	return null;
    }

Conclusion

With that, you should now be able to handle Http requests through a proxy following SOLID principles. There's no direct code example for this one I'm afraid although I do use it in my Speech to Text API Comparator project if you'd like to see it in action. Cheers for reading.

The last week or so I've been exploring the pros and cons of three Speech to Text services. Bing Speech, IBM Watson and AWS Transcribe using a .Net Core 2.0 backend and an Angular 6 client. These are my findings.

Quick Links

• Example code for this post
• Bing Speech
• Bing Speech Documentation
• IBM Watson Speech to Text
• IBM Watson Speech to Text Documentation
• AWS
• AWS S3
• AWS Transcribe
• AWS Transcribe Documentation
• AWS .Net Toolkit
• AWS IAM

Bing Speech Service

The first of three that I implemented was the Bing Speech to Text service since I already have an Azure account. The documentation is pretty clear and the implementation did not take long to set up with Authentication cookies so Microsoft has done a good job there. Here are the following PROS and CONS:

Pros

• Supports the largest range of languages of the three.
• It's fast.
• Easy to implement.
• Three modes: interactive, conversation and dictation.

Cons

• Some modes are limited to 10 seconds of audio within a 15-second clip.
• Modes that can handle more than 10 seconds of audio require a client library to be imported.

Implementation

I've said it's easy to implement, so let me prove it. Firstly grab yourself a subscription key to the free Bing Speech API trial Make note of the subscription key. If you're looking at the provided code, put the subscription key in the appsettings.json file in the BingSubscriptionKey field.

"MyConfig": {
    "UseProxy": "false",
    "ProxyHost": "...",
    "ProxyPort": "...",
    **"BingSubscriptionKey": "65d5......"** <- Here
}

Let's have a look at the three steps to the implementation:

Step 1. Get an authentication token from the Azure Authentication Service using your subscription key.

# AzureAutenticationService

using (var client = _proxyClientService.CreateHttpClient())
{
    client.DefaultRequestHeaders.Add("Ocp-Apim-Subscription-Key", subscriptionKey);
    var uriBuilder = new UriBuilder(fetchUri);
    uriBuilder.Path += "/issueToken";
    var result = await client.PostAsync(uriBuilder.Uri.AbsoluteUri, null);
    return await result.Content.ReadAsStringAsync();
}

Step 2. Parse your file/base64 string into a memory stream and buffer it into a HttpWebRequest object.

# BingSpeechService

var bytes = Convert.FromBase64String(audioBase64);
using (var memoryStream = new MemoryStream(bytes))
{
    // Open a request stream and write 1024 byte chunks in the stream one at a time.
    using (var requestStream = request.GetRequestStream())
    {
        // Read 1024 raw bytes from the input audio file.
        var buffer = new byte[checked((uint) Math.Min(1024, (int) memoryStream.Length))];
        int bytesRead;
        while ((bytesRead = memoryStream.Read(buffer, 0, buffer.Length)) != 0)
        {
            requestStream.Write(buffer, 0, bytesRead);
        }

        // Flush
        requestStream.Flush();
    }

Step 3. Call the response and process the JSON response.

# BingSpeechService

using (var response = request.GetResponse())
{
    var statusCode = ((HttpWebResponse) response).StatusCode.ToString();
    int.TryParse(statusCode, out var statusCodeInt);

    string responseString;
    using (var sr = new StreamReader(response.GetResponseStream() ?? throw new InvalidOperationException()))
    {
        responseString = sr.ReadToEnd();
    }                
    
    return new SpeechRecognitionResult()
    {
        StatusCode = statusCodeInt,
        JSONResult = responseString,
        ExternalServiceTimeInMilliseconds = sw.ElapsedMilliseconds
    };
}   

This process can be seen within two services in the provided code, BingSpeechService and AzureAuthenticationService. The settings are passed in through the URL, the main one being language.

Results

I've tested the process using a few sound files and it seems to be pretty accurate once configured correctly. It roughly takes a couple of seconds to process, so it's fairly snappy too! The response is returned in the form below:

{
    OK
    {
        "RecognitionStatus": "Success",
        "Offset": 22500000,
        "Duration": 21000000,
        "NBest": [{
        "Confidence": 0.941552162,
        "Lexical": "find a funny movie to watch",
        "ITN": "find a funny movie to watch",
        "MaskedITN": "find a funny movie to watch",
        "Display": "Find a funny movie to watch."
     }
}

Overall I've found the service simple to use and effective! Unfortunately, you can only process sound clips up to 10 seconds long with the API alone, any longer and you'll have to use the client library. I'll compare the features of the service with the other services later in this post.

IBM Watson

The second service, IBMs Watson is also a pretty easy service to configure and use, it can be done in one call!

Pros

• It's fast.
• Easy to implement.

Cons

• Does not support as many languages as Bing Speech.

Implementation

Implementing Watson is again pretty straightforward, you can sign up for a free account here. The process is exactly the same as Bing Speech except without the Authentication token, the username and password are passed straight in. If you're using the provided code, you will need to add your Watson subscription details into the appsettings.json file.

public SpeechRecognitionResult ParseSpeectToText(string[] args)
{
    var base64String = args[0];
    using (var client = _httpProxyClientService.CreateHttpClient())
    {
        client.DefaultRequestHeaders.Accept.Clear();
        client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
            "Basic", Convert.ToBase64String(
            Encoding.ASCII.GetBytes(_username + ":" + _password)));

        var bytes = Convert.FromBase64String(base64String);
        var content = new StreamContent(new MemoryStream(bytes));
        content.Headers.ContentType = new MediaTypeHeaderValue("audio/wav");

        Stopwatch sw = new Stopwatch();
        sw.Start();
            
        var response = client.PostAsync("https://stream.watsonplatform.net/speech-to-text/api/v1/recognize?continuous=true&_model=" + _model,
                    content).Result;

        if (!response.IsSuccessStatusCode) return null;
        var res = response.Content.ReadAsStringAsync().Result;
            
        sw.Stop();
            
        return new SpeechRecognitionResult()
        {
            JSONResult = res,
            StatusCode = 200,
            ExternalServiceTimeInMilliseconds = sw.ElapsedMilliseconds
        };
    }
}

Again the URL takes parameters for the settings, so these can be configured as you see fit to serve your purpose. Model is the main parameter that handles language and the quality of the sound file.

Results

There can be multiple responses from the API but will take on this form:

{
    "results":[
        {"alternatives":[{"confidence":0.764,
         "transcript":"testing one two three"}],
         "final":true
     }],
     "result_index":0,
     "warnings":["Unknown arguments:continuous."
    ]
}

Overall IBMs Watson is a pretty solid choice. It does not have Bings sound clip time limit which is a plus but does not have as many supported languages which could sway your decision on which one to use. In general testing, it does fall slightly short on accuracy compared to Bing Speech. Next up, AWS Transcribe.

AWS Transcribe

AWS transcribe put simply is not the easiest of services to use, it feels like it has been designed to work with Landa expressions meaning you get tied into the AWS infrastructure. However, it does have one major fundamental difference from the other services, it processes punctuation! It does so at a significant cost to its speed though!

Pros

• Calculates punctuation.
• Sound files can be preserved in S3 storage.
• Transcribed files are stored for x amount of time so they don't need to be reprocessed.

Cons

• Slow.
• Tricky to set up.
• Very limited language choice.

Implementation

So why is AWS Transcribe a bit tricky to set up? You need to set up S3 storage to store your files, as well as user configuration and the transcribe service itself. If you're handling files already that's fine but if you're using base64 strings from a front end client there's a lot of conversions going on. Firstly sign up for a free account here. You're also going to need the AWS Visual Studio Toolkit. Before opening Visual Studio, you should run through the IAM best practices to set up a non-root user. The next time you open Visual Studio you'll be prompted for your username and keys, if you've not got them already you can grab them through the IAM user panel shown below.

By providing our details to Visual studio, not only will we now have access to the AWS Explorer. There is also an AWS configuration file configured into our Visual Studio environment. Now that's setup, here are the steps to run the speech to text conversion.

Step 1. Upload a file / base64 string into an S3 bucket. Not just any bucket, one that's been created in us-east-1. You can do this through the AWS explorer panel or through the AWS browser console. Once it exists, the following is the code that will convert your base64 string into a WAV file and upload it to the bucket.

#AmazonUploaderService

byte[] bytes = Convert.FromBase64String(base64);
var filename = "S2C" + DateTime.UtcNow.ToString("ddMMyyyyhhmmss") + ".wav";
var request = new PutObjectRequest
{
    BucketName = _bucketName,
    CannedACL = S3CannedACL.PublicRead,
    Key = filename
};

using (var ms = new MemoryStream(bytes))
{
    request.InputStream = ms;
    await _amazonS3Client.PutObjectAsync(request);
    return new S3UploadResponse()
    {
        BucketName = _bucketName,
        FileRoute = filename,
        BucketRegion = _amazonS3Client.Config.RegionEndpoint.SystemName
    };
}

Step 2. Create and trigger a transcribe job. Note this is only the triggering, this process won't return the response.

#AWSService

var transciptionJobName = "Transcribe_" + uploadDetails.FileRoute;
var request = new StartTranscriptionJobRequest()
{
    Media = new Media()
    {
        MediaFileUri = "https://s3." + uploadDetails.BucketRegion + ".amazonaws.com/" + uploadDetails.BucketName + "/" + uploadDetails.FileRoute
    },
    LanguageCode = new LanguageCode(LanguageCode.EnUS),
    MediaFormat = new MediaFormat("Wav"),
    TranscriptionJobName = transciptionJobName
};

Step 3. Poll the AWS service for the job status until complete.

#AWSService

while (!jobComplete)
{
    jobRes = await _amazonTranscribeService.GetTranscriptionJobAsync(new GetTranscriptionJobRequest()
    {
        TranscriptionJobName = transciptionJobName
    });

    if (jobRes != null && jobRes.TranscriptionJob.TranscriptionJobStatus !=
        TranscriptionJobStatus.COMPLETED)
    {
        System.Threading.Thread.Sleep(5000);
    }
        else
    {
        jobComplete = true;
    }
}

Step 4. Create a HttpClientRequest to the new transcribe job resource (the URL containing the result is returned in the job status request, it's not contained directly).

#AWSService 

using (var client = _httpProxyClientService.CreateHttpClient())
{
    client.DefaultRequestHeaders.Accept.Clear();
    client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    var response = client.GetAsync(jobRes.TranscriptionJob.Transcript.TranscriptFileUri).Result;

    if (!response.IsSuccessStatusCode) return null;
    jsonRes = response.Content.ReadAsStringAsync().Result;
}

Step 5. Delete the uploaded file from the S3 bucket (otherwise you will be billed for storage at some point).

# AmazonUploaderService

var res = await _amazonS3Client.DeleteObjectAsync(_bucketName, filename);

Results

The polling process alone puts me off this process, let alone how slow it is. Yet it does not mean that the Transcribe service does not have a place. For non-real-time applications where punctuation is a critical factor then it's ideal! The response is also broken down word by word by default with timestamps which is a nice feature:

"jobName": "Transcribe_S2C21052018021806.wav",
"accountId": "007698288441",
"results": {
    "transcripts": [{
        "transcript": "Because in one two, three."
    }],
    "items": [{
        "start_time": "0.250",
        "end_time": "0.470",
        "alternatives": [{
            "confidence": "0.9666",
            "content": "Because"
        }],
        "type": "pronunciation"
    },
    {
        "start_time": "0.470",
        "end_time": "0.570",
        "alternatives": [{
            "confidence": "0.9993",
            "content": "in"
        }],
        "type": "pronunciation"
    },...
    ]
},
"status": "COMPLETED"

In conclusion to AWS, I'd not consider it for any real-time applications but may find some use in offline tasks, especially since it shows itself to be the most accurate of the three when dealing with large files. It should also tie in nicely with other AWS services which is worth bearing in mind.

Key Comparison

The following table has been created from the data contained within the documentation of the three services:

Comparison results

The results can vary greatly, however, when using short phrases Bing Speech comes out on top for accuracy and speed. On the other hand, AWS Transcribes accuracy seems to be the best for long sound files, although slow. An example result can be seen in the image below using the following extract from Frankenstein "It was on a dreary night of November that I beheld the accomplishment of my toils. With an anxiety that almost amounted to agony".

Conclusion

This has been a nice stepping stone into Speech to Text services, although not perfect they can be considered usable. I feel this project is not complete yet as Azure and AWS have updated services in beta, so the exploration process is likely to continue in the near future. I hope this has been useful so far.

As promised, I've converted the quick training code I created in the CodeIT 2018 Hackathon into a console application. The code can be found here.

There are three key parts to the training process:

* Creating a people group
* Adding people and faces to the group
* Training

Then of course, after the training is complete, there is the identification process. Let's have a look at the application and each process.

Application configuration

After grabbing the code, the first thing to do is to configure the code to your machine and Azure settings. Update the subscription key and the location of the root folder in the code below.

    const string SubscriptionKey = "insert subscription key";
    const string UriBase = "https://northeurope.api.cognitive.microsoft.com/face/v1.0";
    private static readonly string RootFolder = "Update This Path/MicrosftFaceApiTest-Console";
    private static readonly string TrainingFolderPath = RootFolder + "/Data/PersonGroupTraining";

You will also need the Microsoft.ProjectOxford.Face Nuget package. This will allow us to use the FaceServiceClient which makes using the API service pretty simple:

var faceServiceClient = new  FaceServiceClient(SubscriptionKey, UriBase);

Creating a People Group

A person group is as exactly what it says it is, a collection on people. The first step is to create one using console option 2. All we need to do is to assign an ID to the group and create it. I've also provided console option 1, to set the "application reference" to an existing people group.

var personGroupId = "";

static async Task<string> CreatePersonGroup(FaceServiceClient faceServiceClient, string id, string description)
{
    try
    {
        await faceServiceClient.CreatePersonGroupAsync(id, description);
    }
    catch (Exception ex)
    {
        return "Error: " + ex.Message;
    }

    return id;
}

Adding People and Faces

This is where your project directories become important, the Data folder has been designed to hold other folders named after each person. Inside each person folder should be a number of .jpg images of the individual and only the individual. No images with multiple faces. Have a look at the example Data folder.

We then need to scan the Data directory to find each person to add:

var peopleFolders = GetDirectories(TrainingFolderPath);
        
// Lets add the people
foreach(var potentialPersonDir in peopleFolders)
{
    ....
}

There are two functions being called within the process above, CreatePerson which adds a person with the name specified (the folder name) and AddFacesToPerson. We can add faces to the person from the GUID returned by the CreatePerson function. It is also possible to add additional data to a person through the userData option such as a user ID from a local database. The two functions themselves really only call the relevant FaceClientService options:

static async Task<CreatePersonResult> CreatePerson(FaceServiceClient faceServiceClient, string groupId, string name,
        string userData)
    {
        try
        {
            CreatePersonResult person = await faceServiceClient.CreatePersonAsync(groupId, name, userData);
            return person;
        }
        catch (Exception ex)
        {
            Console.WriteLine("Failed to create person " + name);
            Console.WriteLine("Error: " + ex.Message);
        }

        return null;
    }
    
    static async Task<bool> AddFacesToPerson(FaceServiceClient faceServiceClient, string imagesDirectory,
        string personGroupId, Guid personId, bool limit = false)
    {
        var files = GetFiles(imagesDirectory, "*.JPG").Union(GetFiles(imagesDirectory, "*.jpg")).ToArray();;
        foreach (var imagePath in files)
        {
            using (Stream s = File.OpenRead(imagePath))
            {
                // Detect faces in the image and add to person
                try
                {
                    await faceServiceClient.AddPersonFaceAsync(personGroupId, personId, s);
                }
                catch (Exception ex)
                {
                    Console.WriteLine("An error has occured with image " + imagePath + " and has not been added to person");
                    Console.WriteLine("Error: " + ex.Message);
                }
            }

            if (limit)
            {
                System.Threading.Thread.Sleep(15000);
            }
        }

        return true;
    }

With that you know have your facial images ready for training.

Training

Training is the easy part, just make a call to train and wait for it to complete:

static async void TrainPersonGroup(FaceServiceClient faceServiceClient, string personGroupId)
    {
        await faceServiceClient.TrainPersonGroupAsync(personGroupId);
    }
    
    static async Task<bool> WaitForPersonGroupTraining(FaceServiceClient faceServiceClient, string personGroupId,
        bool limit = false)
    {
        while(true)
        {
            var trainingStatus = await faceServiceClient.GetPersonGroupTrainingStatusAsync(personGroupId);

            if (trainingStatus.Status != Status.Running)
            {
                return true;
            }

            if (limit)
            {
                System.Threading.Thread.Sleep(15000);
            }
        }    
    }

Identification

The final part is to test your training through the identification process. Firstly we pass in an image and look to see if there are any faces present:

var faces = await faceServiceClient.DetectAsync(s);
var faceIds = faces.Select(face => face.FaceId).ToArray();

We then pass the detected faces into the identify call:

var results = await faceServiceClient.IdentifyAsync(personGroupId, faceIds);

We will get a list of GUIDs for all identified individuals. If we require more information such as the name of the individual and the userData we passed into the creation process, we just need to Call GetPerson with the GUID:

var person = await faceServiceClient.GetPersonAsync(personGroupId, candidateId);

The identification process is the only part that you will need to build into any application using your newly trained API.

Conclusion

The Azure Face API is a powerful piece of technology that is surprisingly easy to implement. At its cost point its hard to imagine why you'd go about developing your own implementation. Have fun playing with it!

The quest continues, this time to get an Angular client authenticated against our Identity server.

First of all, let's get a basic Angular app going:

$ ng new AngClient --routing -prefix ac --skip-install
$ cd AngClient
$ yarn or npm install

With that, we can now follow another great post by Scott Brady - SPA Authentication using OpenID Connect Angular CLI and oidc client, slightly dated again, however, we can happily follow this guide up untill "Calling a Protected API". I would recommend some changes though to maintain a good code structure, here are my amended instructions.

Protecting a Component & Route Guard

The main problem with the structure that I have here is that everything gets merged together, plus you may have pages that don't need authenticating so let's do the following in the CLI:

$ ng g c components/protects
$ ng g c components/home

Then in the app-routing.module.ts, update the routes array to look like the following:

import { ProtectedComponent } from './components/protected/protected.component';
import { HomeComponent } from './components/home/home.component';

const routes: Routes = [
  {
    path: '',
    component: HomeComponent
  },
  {
    path: 'protected',
    component: ProtectedComponent
  }
];

Next, let's configure the app.component.html to display the routes through the following no thrills navigation menu:

<h1>
  {{title}}
</h1>
<router-outlet></router-outlet>

Route Guard

The route guard is more of a shared component so let's make it so. Firstly let's create a shared module:

 $ ng g m shared

Then let's move the common modules from app.module.ts into the shared module, export them and then import the shared module into app.module.

# shared.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { BrowserModule } from '@angular/platform-browser';

@NgModule({
  imports: [
    CommonModule
  ],
  exports : [
    CommonModule,
    BrowserModule
  ],
  declarations: []
})
export class SharedModule { }

# app.module.ts

...
import { SharedModule } from './shared/shared.module';

@ngModule({
    ...,
    imports: [
    AppRoutingModule,
    SharedModule
      ]
    }
)

Now let's create our Authguard service and implement it:

$ ng g s shared/services/authguard

import { Injectable } from '@angular/core';
import { CanActivate } from '@angular/router';

@Injectable()
export class AuthGuardService implements CanActivate {
    canActivate(): boolean {
        return false;
    }
}

Then declare it as a provider in the shared.module.ts:

 providers: [AuthGuardService]

Finally, we want to use this guard within our routes so that any route that requires our authentication, calls the guard's canActivate function prior to any of the routes components lifecycle hooks.

#app-routing.mdoule.ts

{
    path: 'protected',
    component: ProtectedComponent,
    canActivate: [AuthGuardService]
}

If you run the application now, you should no longer be able to access the protected route!

The oidc-client

Now onto the authentication, first of all, create another service called auth and add it into out sharedModule providers.

$ ng g s shared/services/auth

#shared.module.ts
import { AuthService } from './services/auth.service';

...
providers: [AuthGuardService, AuthService]

Next up we need the oidc-client package, through the command line type:

yard add oidc-client
or
npm install oidc-client

We can now use the user manager components from oidc-client in our auth service:

#auth.service.ts
import { UserManager, UserManagerSettings, User } from 'oidc-client';

Next up we need to sort out out client settings to tie in with our identity server. In the auth service add the following code, filling in the authority field with your identity server endpoint address:

#auth.service.ts
@Injectable()
export class AuthService {
}
export function getClientSettings(): UserManagerSettings {
  return {
    authority: 'https://localhost:443xx/',
    client_id: 'ng',
    redirect_uri: 'http://localhost:4200/auth-callback',
    post_logout_redirect_uri: 'http://localhost:4200/',
    response_type: "id_token token",
    scope: "openid profile",
    filterProtocolClaims: true,
    loadUserInfo: true,
    automaticSilentRenew: true,
    silent_redirect_uri: 'http://localhost:4200/silent-refresh.html'
};

Later down the line you should configure these settings to a config file! Next up, we want to make sure we have a user on the construction of our AuthService with the following:

#auth.service.ts
private manager: UserManager = new UserManager(getClientSettings());
private user: User = null;

constructor() {
    this.manager.getUser().then(user => {
        this.user = user;
    });
}

Then finally for our auth service, we need to add five self-explained functions, if you need more info on these functions have a look at Scott Brady's post which will go into more detail.

#auth.service.ts
isLoggedIn(): boolean {
    return this.user != null && !this.user.expired;
  }

  getClaims(): any {
    return this.user.profile;
  }

  getAuthorizationHeaderValue(): string {
    return `${this.user.token_type} ${this.user.access_token}`;
  }

  startAuthentication(): Promise<void> {
    return this.manager.signinRedirect();
  }

  completeAuthentication(): Promise<void> {
      return this.manager.signinRedirectCallback().then(user => {
      this.user = user;
    });
  }

Now we can use the AuthService in our AuthGuardService by implementing the isLoggedIn and startAuthentication function. They are used within the constructor and canActivate function:

#authguard.service.ts
import { Injectable } from '@angular/core';
import { CanActivate } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable()
export class AuthGuardService implements CanActivate {
    constructor(private authService: AuthService) { }

    canActivate(): boolean {
        if(this.authService.isLoggedIn()) {
          return true;
        }

        this.authService.startAuthentication();
        return false;
    }
}

There is one final task within the angular app, that is to handle the callback endpoint from our identity server and complete the authentication process. We will need a component to do so, so let's create it:

ng g c shared/components/auth-callback -m shared

Then fill it in with the following:

import { Component, OnInit } from '@angular/core';
import { AuthService } from '../../services/auth.service';

@Component({
    selector: 'app-auth-callback',
    templateUrl: './auth-callback.component.html',
    styleUrls: ['./auth-callback.component.css']
})

export class AuthCallbackComponent implements OnInit {

    constructor(private authService: AuthService) { }

    ngOnInit() {
      this.authService.completeAuthentication();
    }
}

Make sure we're exporting it in our shared.module.ts

#shared.module.ts
import { AuthCallbackComponent } from './components/auth-callback/auth-callback.component';

...

exports : [ ..., 
    AuthCallbackComponent
]

And finally set up a route so that our Identity Server can reach our Angular app's callback component:

#app-routing.module.ts

const routes: Routes = [
...,
{
    path: 'auth-callback',
    component: AuthCallbackComponent
}]

And that's it for our Angular app, however, we still need to add it as a client within our Identity Server. Open up our Identity Server project and head to the config.cs file. Then within clients add the following:

#config.cs
new Client
{
    ClientId = "ng",
    ClientName = "Angular 4 Client",
    AllowedGrantTypes = GrantTypes.Implicit,
    RedirectUris = new List<string> { "http://localhost:4200/auth-callback" },
    PostLogoutRedirectUris = new List<string> { "http://localhost:4200/" },
    AllowedCorsOrigins = new List<string> { "http://localhost:4200" },
    AllowAccessTokensViaBrowser = true,

    AllowedScopes =
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile,
    }
}

Good news we are finally there! Run the Identity Server project and Angular project together and head to your home page, no problem. Now click on the "Protected" link and you should be redirected to the Identity Server login page. Use your credentials and sign in and surprise, you should get redirected to our auth-callback page. Click on the "Protected" link again and you should now see "protected works!". Awesome we can now block pages from unauthorised users!

That's as far as I'm going to go with this post, however, part 3 will be about angular passing its token onto a standalone API. There are also a couple of things you can do at this point to improve your app listed below. Cheers for reading.

The completed code for this post can be found here.

• You probably want to modify the auth-callback page to record what page redirected you to it. That way once the Identity Server is done you can go straight back to the page they originally tried to access.
• Your token will expire eventually and we have no control over that yet. Check it out here.

Yesterday I was introduced to the world of Hackathons through Civica Digital's CodeIT18 event in Bristol. Teamed up with David Banks and Matthew Cantilion we had a pretty well rounded full stack team, even if it was our first time working together. Part of the prerequisites of the day was to choose a specific scenario, in which we decided to challenge ourselves with a facial recognition task. This is how the day played out for us.

08:00: Introduction to the seven teams, set up and breakfast. Free food is always welcome!

08:30: We're off! The first point of call was to come up with a plan. We quickly mocked up some screen designs and a user workflow using Balsamiq. Then when we were happy, we set up a GitHub repository, Angular 5 frontend and a .NET Core 2 back API. Perfect since Matt and I are Mac users allowing us to work on the backend too.

09:15: The skeleton of the front and backend parts is up and running. Snappy! Matthew has not used Angular before so he's having to pick it up quite fast but the CLI is proving invaluable for its speed. David's hit the first snag of the day. The police database API is not liking basic authentication. Matt and I will continue with the basic manual search functionality features required by the scenario, just in case we fail on the face detection section of our project.

10:00: David's fixed the authentication issue, who knew the authentication header is case sensitive! He's also got the searching functionality working with the police API so that's one key piece of functionality complete, as well as a basic form of authentication for our own API. Accountability with this type of system is key! Matt and I, on the other hand, have sorted out a login page and searching form. It's going well so far.

10:45: We now have JSON server up and running and a few services pulling back mock data for our search results on the frontend. Matt's now continuing to develop the page to display them. Image data is currently missing as it seems to be missing from the police API which provides a challenge. David's been working some magic and is now waiting to tie the front and back together. 11:30 has been agreed as the combining time.

11:30: Matt has finished the results page and is now ready to tie the frontend together with the back with David. I've also started on implementing the camera functionality within the frontend.

12:00: Lunch time calls! We are now in a strong position if the facial recognition fails we now have the manual search process functional and tied together with our backend. The real fun starts soon!

12:30: Facial identification time. We've not been able to get back any photos from the police API yet so I've had to take a couple of photos from a few people around the event. Three images of each person should create a good model during the training process. Matt is now working on tidying up the frontend into a user-friendly state. David is working on some issues with the police API and publishing while I'm working on the facial recognition training process.

14:30: Facial identification is working! The Azure face API is actually quite impressive even if it did throw a few spanners in the works by not returning error messages during the training process. I also managed to assign IDs of individuals from the police API into the face data. All my willing victims from earlier have now been turned into criminals. Sorry! The frontend is looking good and is ready to now implement the facial identification process. David has been fighting some publishing issues but nothing that should affect the end result.

16:00: The frontend is now passing an image back successfully, the facial recognition is detecting faces as required and returning both the azure GUID and our police API ID. David has been working on returning the individuals data from the police API and should be ready to tie in shortly to the template page we created earlier.

17:30: Matt has produced us a nice presentation for the end show. David and I have been battling Git merge issues and multiple communication issues. The final half an hour is going to be a rush to tie this all together.

18:00: Just made it, the functionality that we set out to create has been produced! A few little tweaks to some JSON strings and ID manipulation (as they start at 108 not 1) and we've officially hacked are the way to a working solution. David has also snuck in Azure insights at some point so every API call is now being logged. Magic! 62 commits and now all that's left is to present our work.

19:15: Presentations completed! A few minor issues but that's what happens when you only finish your solution five minutes before the end. A couple of strong contenders, it's going to be close.

19:45: Winners announced, Congratulations CrEYEm Labs! Now off for a well-earned pint! Cheers everyone and a big thank you to the organisers and everyone else who helped in the running of the day!

Looking back on the day we didn't kill each other and our solution was fairly successful. Maybe we should have done a bit more research into the provided API's responses earlier on and maybe we could have done with an extra member to help with polishing up the solution but ultimately we're happy with the result of the day. Our code can be found here and I'll produce another post on the Azure Face API training process in the near future.

Last night I had the pleasure of co-hosting with Raquel Plaza and Richard Press, the first joint Dojo between the Bath and Hammersmith Civica offices. I hope everyone enjoyed their introduction to the Angular CLI, or if you were a bit more advanced, managed to take away something new with you.

For all those who attended and those who would like to see the material, you can find it here. I will try and keep this updated to the best of my ability.

I would also recommend the following resources to continue down your Angular path.

• Pipelines – Chapter 6 Data Binding and Pipes > Transforming Data with Pipes by Deborah Kurata
• Interceptors by Ryan Chenkie
• Angular with Identity Server by Scott Brady
• Best Practises by Jim Cooper

Cheers for attending everyone!

Edit 1 27/04/2018 - A couple of people asked about why some modules use .forRoot() and .forChild() which I could not answer last night. However, Gareth Penfold the eager bee he is, had already gone away to look it up and has recomended the following post. Cheers Gareth :).

I wanted to explore the concept of identity, authentication and authorisation in more detail after I acquired some hands-on experience with Identity Server 3 on my last project. This post is about my findings along the way and hopefully the development of a modern authorisation structure.

My first stop was to explore modern security concepts and workflows in which I came across Dominick Baier's slightly dated Pluralsight Course - Introduction to OAuth2, OpenID Connect and JSON Web Tokens (JWT).

This course took about 2 hours to complete and personally I found it quite useful to build a fundamental understanding of concepts. However, I've also found some further resources on each item of interest for anyone who does not have access to PluralSight.

• oAuth2 - An Introduction to oAuth2
• OpenId - API Security: Deep Dive into OAuth and OpenID Connect

My next point of call was to start implementing authentication in which I found a nice course by Chris Klug on PluralSight - ASP.NET Core 2 Authentication Playbook.

He's a little fast in places but he does cover a lot of different methods of authentication, each chapter is a different process and can easily be used as a return reference point. I've not implemented every method but some of the key chapters for me were:

• Using Local Logins
• Authenticating Users Using Azure AD B2C
• Authenticating Users Using OpenID Connect and IdentityServer
• Setting up Authorization

It's a really good course in terms of providing a basic overview of how to implement the different methods of authentication however, I want to implement something a little more complex than the basics. I want users stored in a database at the least.

The best way I can think of doing this is to tie identity server 4 in with ASP.Net users. To do this I originally followed Scott Bradys "Getting Started with IdentityServer 4" blog post. This tutorial has some good material particularly in terms of the MVC client (which is worth understanding) however, it is outdated when it comes to the ASP.Net user integration. The best resource I found for this part was actually the Identity Server official documentation. Beware though, a lot of it is a muddle of different versions at the time of posting this blog!

You can successfully follow the documentation up untill "Logging in with the MVC client to set up ASP.Net users with an identity server-driven login system" before it gets a bit lost. There are a couple of things to look out for when running through this tutorial:

• When you reach modify hosting, why not just enable SSL from the start and copy the SSL URL as the project start URL (Make note of the URL for future required references).
• When you reach creating the user database you will need to enter the project folder through the package manager to be able to use the dotnet ef command.

You should now be able to create a user, login and logout through the default ASP theme! Do so before continuing as we will be removing the create functionality. The next part of the tutorial is where it becomes unclear, these are the steps that I took to get it working.

Firstly grab the Identity Server Quickstart UI. We are going to replace the default ASP theme with the Quickstart UI since the authentication endpoints have already been configured for us. For now move the wwwroot, Views and Quickstart folders into a new folder called old. Then copy the new versions in from the download. There will now be a couple of references that need updating/removing (e.g. Account controller) just run a build to find the errors.

Secondly, we need to grab the MVC client referenced in the documentation. What is not clear though is that all the documentation code examples can be found here. Grab the MVC client from the relevant sample (Quickstarts > 6_AspNetIdentity) and import it into your project.

The MVC Client needs to be configured to point to our identity server. Head into the startup.cs file and change the authority field to your identity server URL "https://localhost:443xx/". We also need to update our client, firstly enable SSL and update the default URL in the MVC Client in the same manner as we did previously. Then in the server projects, config file update the following URLs...

RedirectUris = { "https://localhost:443xx/signin-oidc" },
PostLogoutRedirectUris = { "https://localhost:443xx/signout-callback-oidc" },

To run the project, right click on your solution and select "Set Startup Projects". so we can see everything thats going on I've set mine to start both projects under the multiple option.

The application will now run but we have a problem, by default the quickstart UI uses Username as a required field whereas ASP Users uses Email. We will have to change that, head into quickstart > account > logininputmodel.cs and change username to email. Build the project and you'll find a few missing references to the username which you can change over to email. There will also be some references that won't get caught in the build under views > account > login.cshtml. They will also need changing to email.

Finally, we need to update the account controller to a hybrid controller that I've developed from multiple sources. Just completely change the controller to the following:

namespace IS4Server.Controllers.Account.Account
{
    [SecurityHeaders]
    public class AccountController : Controller
    {
        private readonly UserManager<ApplicationUser> _userManager;
        private readonly SignInManager<ApplicationUser> _signInManager;
        private readonly IIdentityServerInteractionService _interaction;
        private readonly IClientStore _clientStore;
        private readonly IAuthenticationSchemeProvider _schemeProvider;
        private readonly IEventService _events;

        public AccountController(
            UserManager<ApplicationUser> userManager,
            SignInManager<ApplicationUser> signInManager,
            IIdentityServerInteractionService interaction,
            IClientStore clientStore,
            IAuthenticationSchemeProvider schemeProvider,
            IEventService events)
        {
            _userManager = userManager;
            _signInManager = signInManager;
            _interaction = interaction;
            _clientStore = clientStore;
            _schemeProvider = schemeProvider;
            _events = events;
        }

        /// <summary>
        /// Show login page
        /// </summary>
        [HttpGet]
        public async Task<IActionResult> Login(string returnUrl)
        {
            // build a model so we know what to show on the login page
            var vm = await BuildLoginViewModelAsync(returnUrl);

            if (vm.IsExternalLoginOnly)
            {
                // we only have one option for logging in and it's an external provider
                return await ExternalLogin(vm.ExternalLoginScheme, returnUrl);
            }

            return View(vm);
        }

        /// <summary>
        /// Handle postback from username/password login
        /// </summary>
        [HttpPost]
        [ValidateAntiForgeryToken]
        public async Task<IActionResult> Login(LoginInputModel model, string button)
        {
            if (button != "login")
            {
                // the user clicked the "cancel" button
                var context = await _interaction.GetAuthorizationContextAsync(model.ReturnUrl);
                if (context != null)
                {
                    // if the user cancels, send a result back into IdentityServer as if they 
                    // denied the consent (even if this client does not require consent).
                    // this will send back an access denied OIDC error response to the client.
                    await _interaction.GrantConsentAsync(context, ConsentResponse.Denied);

                    // we can trust model.ReturnUrl since GetAuthorizationContextAsync returned non-null
                    return Redirect(model.ReturnUrl);
                }
                else
                {
                    // since we don't have a valid context, then we just go back to the home page
                    return Redirect("~/");
                }
            }

            if (ModelState.IsValid)
            {
                var result = await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberLogin, lockoutOnFailure: true);
                if (result.Succeeded)
                {
                    var user = await _userManager.FindByEmailAsync(model.Email);
                    await _events.RaiseAsync(new UserLoginSuccessEvent(user.UserName, user.Id, user.UserName));

                    // make sure the returnUrl is still valid, and if so redirect back to authorize endpoint or a local page
                    // the IsLocalUrl check is only necessary if you want to support additional local pages, otherwise IsValidReturnUrl is more strict
                    if (_interaction.IsValidReturnUrl(model.ReturnUrl) || Url.IsLocalUrl(model.ReturnUrl))
                    {
                        return Redirect(model.ReturnUrl);
                    }

                    return Redirect("~/");
                }

                await _events.RaiseAsync(new UserLoginFailureEvent(model.Email, "invalid credentials"));

                ModelState.AddModelError("", AccountOptions.InvalidCredentialsErrorMessage);
            }

            // something went wrong, show form with error
            var vm = await BuildLoginViewModelAsync(model);
            return View(vm);
        }

        /// <summary>
        /// initiate roundtrip to external authentication provider
        /// </summary>
        [HttpGet]
        public async Task<IActionResult> ExternalLogin(string provider, string returnUrl)
        {
            if (AccountOptions.WindowsAuthenticationSchemeName == provider)
            {
                // windows authentication needs special handling
                return await ProcessWindowsLoginAsync(returnUrl);
            }
            else
            {
                // start challenge and roundtrip the return URL and 
                var props = new AuthenticationProperties()
                {
                    RedirectUri = Url.Action("ExternalLoginCallback"),
                    Items =
                    {
                        { "returnUrl", returnUrl },
                        { "scheme", provider },
                    }
                };
                return Challenge(props, provider);
            }
        }

        /// <summary>
        /// Post processing of external authentication
        /// </summary>
        [HttpGet]
        public async Task<IActionResult> ExternalLoginCallback()
        {
            // read external identity from the temporary cookie
            var result = await HttpContext.AuthenticateAsync(IdentityConstants.ExternalScheme);
            if (result?.Succeeded != true)
            {
                throw new Exception("External authentication error");
            }

            // lookup our user and external provider info
            var (user, provider, providerUserId, claims) = await FindUserFromExternalProviderAsync(result);
            if (user == null)
            {
                // this might be where you might initiate a custom workflow for user registration
                // in this sample we don't show how that would be done, as our sample implementation
                // simply auto-provisions new external user
                user = await AutoProvisionUserAsync(provider, providerUserId, claims);
            }

            // this allows us to collect any additonal claims or properties
            // for the specific prtotocols used and store them in the local auth cookie.
            // this is typically used to store data needed for signout from those protocols.
            var additionalLocalClaims = new List<Claim>();
            var localSignInProps = new AuthenticationProperties();
            ProcessLoginCallbackForOidc(result, additionalLocalClaims, localSignInProps);
            ProcessLoginCallbackForWsFed(result, additionalLocalClaims, localSignInProps);
            ProcessLoginCallbackForSaml2p(result, additionalLocalClaims, localSignInProps);

            // issue authentication cookie for user
            // we must issue the cookie maually, and can't use the SignInManager because
            // it doesn't expose an API to issue additional claims from the login workflow
            var principal = await _signInManager.CreateUserPrincipalAsync(user);
            additionalLocalClaims.AddRange(principal.Claims);
            var name = principal.FindFirst(JwtClaimTypes.Name)?.Value ?? user.Id;
            await _events.RaiseAsync(new UserLoginSuccessEvent(provider, providerUserId, user.Id, name));
            await HttpContext.SignInAsync(user.Id, name, provider, localSignInProps, additionalLocalClaims.ToArray());

            // delete temporary cookie used during external authentication
            await HttpContext.SignOutAsync(IdentityConstants.ExternalScheme);

            // validate return URL and redirect back to authorization endpoint or a local page
            var returnUrl = result.Properties.Items["returnUrl"];
            if (_interaction.IsValidReturnUrl(returnUrl) || Url.IsLocalUrl(returnUrl))
            {
                return Redirect(returnUrl);
            }

            return Redirect("~/");
        }

        /// <summary>
        /// Show logout page
        /// </summary>
        [HttpGet]
        public async Task<IActionResult> Logout(string logoutId)
        {
            // build a model so the logout page knows what to display
            var vm = await BuildLogoutViewModelAsync(logoutId);

            if (vm.ShowLogoutPrompt == false)
            {
                // if the request for logout was properly authenticated from IdentityServer, then
                // we don't need to show the prompt and can just log the user out directly.
                return await Logout(vm);
            }

            return View(vm);
        }

        /// <summary>
        /// Handle logout page postback
        /// </summary>
        [HttpPost]
        [ValidateAntiForgeryToken]
        public async Task<IActionResult> Logout(LogoutInputModel model)
        {
            // build a model so the logged out page knows what to display
            var vm = await BuildLoggedOutViewModelAsync(model.LogoutId);

            if (User?.Identity.IsAuthenticated == true)
            {
                // delete local authentication cookie
                await _signInManager.SignOutAsync();

                // raise the logout event
                await _events.RaiseAsync(new UserLogoutSuccessEvent(User.GetSubjectId(), User.GetDisplayName()));
            }

            // check if we need to trigger sign-out at an upstream identity provider
            if (vm.TriggerExternalSignout)
            {
                // build a return URL so the upstream provider will redirect back
                // to us after the user has logged out. this allows us to then
                // complete our single sign-out processing.
                string url = Url.Action("Logout", new { logoutId = vm.LogoutId });

                // this triggers a redirect to the external provider for sign-out
                return SignOut(new AuthenticationProperties { RedirectUri = url }, vm.ExternalAuthenticationScheme);
            }

            return View("LoggedOut", vm);
        }

        /*****************************************/
        /* helper APIs for the AccountController */
        /*****************************************/
        private async Task<LoginViewModel> BuildLoginViewModelAsync(string returnUrl)
        {
            var context = await _interaction.GetAuthorizationContextAsync(returnUrl);
            if (context?.IdP != null)
            {
                // this is meant to short-circuit the UI and only trigger the one external IdP
                return new LoginViewModel
                {
                    EnableLocalLogin = false,
                    ReturnUrl = returnUrl,
                    Email = context?.LoginHint,
                    ExternalProviders = new ExternalProvider[] { new ExternalProvider { AuthenticationScheme = context.IdP } }
                };
            }

            var schemes = await _schemeProvider.GetAllSchemesAsync();

            var providers = schemes
                .Where(x => x.DisplayName != null ||
                            (x.Name.Equals(AccountOptions.WindowsAuthenticationSchemeName, StringComparison.OrdinalIgnoreCase))
                )
                .Select(x => new ExternalProvider
                {
                    DisplayName = x.DisplayName,
                    AuthenticationScheme = x.Name
                }).ToList();

            var allowLocal = true;
            if (context?.ClientId != null)
            {
                var client = await _clientStore.FindEnabledClientByIdAsync(context.ClientId);
                if (client != null)
                {
                    allowLocal = client.EnableLocalLogin;

                    if (client.IdentityProviderRestrictions != null && client.IdentityProviderRestrictions.Any())
                    {
                        providers = providers.Where(provider => client.IdentityProviderRestrictions.Contains(provider.AuthenticationScheme)).ToList();
                    }
                }
            }

            return new LoginViewModel
            {
                AllowRememberLogin = AccountOptions.AllowRememberLogin,
                EnableLocalLogin = allowLocal && AccountOptions.AllowLocalLogin,
                ReturnUrl = returnUrl,
                Email = context?.LoginHint,
                ExternalProviders = providers.ToArray()
            };
        }

        private async Task<LoginViewModel> BuildLoginViewModelAsync(LoginInputModel model)
        {
            var vm = await BuildLoginViewModelAsync(model.ReturnUrl);
            vm.Email = model.Email;
            vm.RememberLogin = model.RememberLogin;
            return vm;
        }

        private async Task<LogoutViewModel> BuildLogoutViewModelAsync(string logoutId)
        {
            var vm = new LogoutViewModel { LogoutId = logoutId, ShowLogoutPrompt = AccountOptions.ShowLogoutPrompt };

            if (User?.Identity.IsAuthenticated != true)
            {
                // if the user is not authenticated, then just show logged out page
                vm.ShowLogoutPrompt = false;
                return vm;
            }

            var context = await _interaction.GetLogoutContextAsync(logoutId);
            if (context?.ShowSignoutPrompt == false)
            {
                // it's safe to automatically sign-out
                vm.ShowLogoutPrompt = false;
                return vm;
            }

            // show the logout prompt. this prevents attacks where the user
            // is automatically signed out by another malicious web page.
            return vm;
        }

        private async Task<LoggedOutViewModel> BuildLoggedOutViewModelAsync(string logoutId)
        {
            // get context information (client name, post logout redirect URI and iframe for federated signout)
            var logout = await _interaction.GetLogoutContextAsync(logoutId);

            var vm = new LoggedOutViewModel
            {
                AutomaticRedirectAfterSignOut = AccountOptions.AutomaticRedirectAfterSignOut,
                PostLogoutRedirectUri = logout?.PostLogoutRedirectUri,
                ClientName = string.IsNullOrEmpty(logout?.ClientName) ? logout?.ClientId : logout?.ClientName,
                SignOutIframeUrl = logout?.SignOutIFrameUrl,
                LogoutId = logoutId
            };

            if (User?.Identity.IsAuthenticated == true)
            {
                var idp = User.FindFirst(JwtClaimTypes.IdentityProvider)?.Value;
                if (idp != null && idp != IdentityServer4.IdentityServerConstants.LocalIdentityProvider)
                {
                    var providerSupportsSignout = await HttpContext.GetSchemeSupportsSignOutAsync(idp);
                    if (providerSupportsSignout)
                    {
                        if (vm.LogoutId == null)
                        {
                            // if there's no current logout context, we need to create one
                            // this captures necessary info from the current logged in user
                            // before we signout and redirect away to the external IdP for signout
                            vm.LogoutId = await _interaction.CreateLogoutContextAsync();
                        }

                        vm.ExternalAuthenticationScheme = idp;
                    }
                }
            }

            return vm;
        }

        private async Task<IActionResult> ProcessWindowsLoginAsync(string returnUrl)
        {
            // see if windows auth has already been requested and succeeded
            var result = await HttpContext.AuthenticateAsync(AccountOptions.WindowsAuthenticationSchemeName);
            if (result?.Principal is WindowsPrincipal wp)
            {
                // we will issue the external cookie and then redirect the
                // user back to the external callback, in essence, testing windows
                // auth the same as any other external authentication mechanism
                var props = new AuthenticationProperties()
                {
                    RedirectUri = Url.Action("ExternalLoginCallback"),
                    Items =
                    {
                        { "returnUrl", returnUrl },
                        { "scheme", AccountOptions.WindowsAuthenticationSchemeName },
                    }
                };

                var id = new ClaimsIdentity(AccountOptions.WindowsAuthenticationSchemeName);
                id.AddClaim(new Claim(JwtClaimTypes.Subject, wp.Identity.Name));
                id.AddClaim(new Claim(JwtClaimTypes.Name, wp.Identity.Name));

                // add the groups as claims -- be careful if the number of groups is too large
                if (AccountOptions.IncludeWindowsGroups)
                {
                    var wi = wp.Identity as WindowsIdentity;
                    var groups = wi.Groups.Translate(typeof(NTAccount));
                    var roles = groups.Select(x => new Claim(JwtClaimTypes.Role, x.Value));
                    id.AddClaims(roles);
                }

                await HttpContext.SignInAsync(
                    IdentityServer4.IdentityServerConstants.ExternalCookieAuthenticationScheme,
                    new ClaimsPrincipal(id),
                    props);
                return Redirect(props.RedirectUri);
            }
            else
            {
                // trigger windows auth
                // since windows auth don't support the redirect uri,
                // this URL is re-triggered when we call challenge
                return Challenge(AccountOptions.WindowsAuthenticationSchemeName);
            }
        }

        private async Task<(ApplicationUser user, string provider, string providerUserId, IEnumerable<Claim> claims)> 
            FindUserFromExternalProviderAsync(AuthenticateResult result)
        {
            var externalUser = result.Principal;

            // try to determine the unique id of the external user (issued by the provider)
            // the most common claim type for that are the sub claim and the NameIdentifier
            // depending on the external provider, some other claim type might be used
            var userIdClaim = externalUser.FindFirst(JwtClaimTypes.Subject) ??
                              externalUser.FindFirst(ClaimTypes.NameIdentifier) ??
                              throw new Exception("Unknown userid");

            // remove the user id claim so we don't include it as an extra claim if/when we provision the user
            var claims = externalUser.Claims.ToList();
            claims.Remove(userIdClaim);

            var provider = result.Properties.Items["scheme"];
            var providerUserId = userIdClaim.Value;

            // find external user
            var user = await _userManager.FindByLoginAsync(provider, providerUserId);

            return (user, provider, providerUserId, claims);
        }

        private async Task<ApplicationUser> AutoProvisionUserAsync(string provider, string providerUserId, IEnumerable<Claim> claims)
        {
            // create a list of claims that we want to transfer to our store
            var filtered = new List<Claim>();

            // user's display name
            var name = claims.FirstOrDefault(x => x.Type == JwtClaimTypes.Name)?.Value ??
                claims.FirstOrDefault(x => x.Type == ClaimTypes.Name)?.Value;
            if (name != null)
            {
                filtered.Add(new Claim(JwtClaimTypes.Name, name));
            }
            else
            {
                var first = claims.FirstOrDefault(x => x.Type == JwtClaimTypes.GivenName)?.Value ??
                    claims.FirstOrDefault(x => x.Type == ClaimTypes.GivenName)?.Value;
                var last = claims.FirstOrDefault(x => x.Type == JwtClaimTypes.FamilyName)?.Value ??
                    claims.FirstOrDefault(x => x.Type == ClaimTypes.Surname)?.Value;
                if (first != null && last != null)
                {
                    filtered.Add(new Claim(JwtClaimTypes.Name, first + " " + last));
                }
                else if (first != null)
                {
                    filtered.Add(new Claim(JwtClaimTypes.Name, first));
                }
                else if (last != null)
                {
                    filtered.Add(new Claim(JwtClaimTypes.Name, last));
                }
            }

            // email
            var email = claims.FirstOrDefault(x => x.Type == JwtClaimTypes.Email)?.Value ??
               claims.FirstOrDefault(x => x.Type == ClaimTypes.Email)?.Value;
            if (email != null)
            {
                filtered.Add(new Claim(JwtClaimTypes.Email, email));
            }

            var user = new ApplicationUser
            {
                UserName = Guid.NewGuid().ToString(),
            };
            var identityResult = await _userManager.CreateAsync(user);
            if (!identityResult.Succeeded) throw new Exception(identityResult.Errors.First().Description);

            if (filtered.Any())
            {
                identityResult = await _userManager.AddClaimsAsync(user, filtered);
                if (!identityResult.Succeeded) throw new Exception(identityResult.Errors.First().Description);
            }

            identityResult = await _userManager.AddLoginAsync(user, new UserLoginInfo(provider, providerUserId, provider));
            if (!identityResult.Succeeded) throw new Exception(identityResult.Errors.First().Description);

            return user;
        }

        private void ProcessLoginCallbackForOidc(AuthenticateResult externalResult, List<Claim> localClaims, AuthenticationProperties localSignInProps)
        {
            // if the external system sent a session id claim, copy it over
            // so we can use it for single sign-out
            var sid = externalResult.Principal.Claims.FirstOrDefault(x => x.Type == JwtClaimTypes.SessionId);
            if (sid != null)
            {
                localClaims.Add(new Claim(JwtClaimTypes.SessionId, sid.Value));
            }

            // if the external provider issued an id_token, we'll keep it for signout
            var id_token = externalResult.Properties.GetTokenValue("id_token");
            if (id_token != null)
            {
                localSignInProps.StoreTokens(new[] { new AuthenticationToken { Name = "id_token", Value = id_token } });
            }
        }

        private void ProcessLoginCallbackForWsFed(AuthenticateResult externalResult, List<Claim> localClaims, AuthenticationProperties localSignInProps)
        {
        }

        private void ProcessLoginCallbackForSaml2p(AuthenticateResult externalResult, List<Claim> localClaims, AuthenticationProperties localSignInProps)
        {
        }
    }
}

Now when you run the MVC Client app, you should reach a home page which has no authentication requirements. When you click the "secure" tab, suddenly you hit a route with the [Authorise] property. The client will redirect to the Identity Server to log in. Once logged in, the Identity Server will then redirect you back to the MVC app with the correct credentials displaying the cookie. Success!

We have now implemented Server to Server authentication using a hybrid flow. This is not my usual project structure but it's a start towards my final aim of an API / Front End Authentication process. Part 2 will be on the process to authenticate an Angular 5+ front-end application.

The completed code for this post can be found here.

No site these days is worth its worth unless HTTPS is enabled! This will guide you through the process of configuring your new blog to use HTTPS if you choose to do so. We will configure our domain to the server and then reverse proxy to the ghost blog container.

Firstly, you will need a domain. Head to any domain provider and pick up the domain you want. (I used Names since it was £5.99 at the time of writting this post for a .co.uk address and privacy protection). Once you've aquired your domain name, head into the DNS settings and set the A parmater to your VM's IP address. We won't need any further configurations at this point.

While the DNS tables update globally, we will head into our VM. SSH on to your machine. The first thing we will do is update our apt-get repo mirrors. By default, Azure has its own repos which, at the time of writing this post, were not active. To do this head to /etc/apt and open sources.list. If you don't have a text editor, run the following:

sudo apt-get update
sudo apt-get install nano
sudo nano sources.list

Now, wherever Azure is referenced in the file, change it to "us". To exit and save in nano, press ctrl+x which will prompt you to save on exiting. Then finally update one more time.

sudo apt-get update

Good, we should now have access to the repos we require. We now need to install nginx which is the equivalant to IIS on Ubuntu 17.10.

sudo apt-get install nginx
systemctl status nginx // Check nginx is up and running

Heading to http://{server ip} should now bring up a default nginx home page. Success!

Certbot

We will use Certbot to create a HTTPS certificate for us, follow these instructions to install Certbot.

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx

With that installed, we need to open up our default nginx settings to allow access to "yourdomain.com/.well-known/acme-challenge" so that we can confirm access through lets encrypt. There are mutiple ways to configure these settings but for now, this is what has worked for me. Head to /ect/nginx/sites-avaliable and open the file named default in nano. It's probably worth a read through this file to understand what options are avalaiable; once read update the file to the following:

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/yourdomain.com;
    location ^~ /.well-known/acme-challenge {
        allow all;
    }

    location / {
        return 301 https://$server_name$request_uri;
    }
}

Now we can make sure that there are no errors with the syntax and reload Nginx.

sudo nginx -t
sudo systemctl reload nginx

You can see that root has been defined here, make sure this directory exists with the steps below. We will also test to make sure we have access to the relevant directories before running the certification process.

cd /var/www
mkdir yourdomain.com
cd yourdomain.com
mkdir .well-known
cd .well-known
mkdir acme-challenge
cd acme-challenge
touch testfile.txt
sudo nano testfile.txt
hello world
ctrl + x

As soon as the global DNS tables have been updated, you can test to see if the file is downloadable by accessing http://yourdomain.com/.well-known/acme-challenge/testfile.txt or if it's still going through http://{serverip}/.well-known/acme-challenge/testfile.txt.

Once successful, head back to /var/www/yourdomain.com and remove the /.well-known folder.

rm -r .well-known

The certification process will create the directories itself. For the next step, the DNS tables must be working so you may have to wait at this point. To check the status of the update head to Whats my DNS and type in "yourdomain.com" to see if it's pointing to your machine.

Get the Certificate

The Certbot has become a lot more user friendly recently and will update the nginx configuratiom file diretly with the --nginx flag. Nice! To do so run:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Follow the instructions providing your domain and the folder that we created above and it will grant us with a certificate for our HTTPS. The certificate will have to be updated every 90 days which can be automated but for now let's just simulate the update process to make sure everything is in order.

sudo certbot renew --dry-run

Open the ports

HTTPS/SSL uses port 443 which we have not opened up yet on Azure. Head to your Azure portal > then to the VM > then to the Networking tab. Add in a new inbound port rule for port 443 to open up access to https://.

Next we want to direct our server to our Ghost container instance. Head back to /ect/nginx/sites-avaliable and open the default file in nano. In the server settings for the new server listening on 443 created by Certbot, set "location /" inner brackets to:

proxy_pass http://127.0.0.1:<ghost container port>
proxy_set_header    X-Real-IP $remote_addr;
proxy_set_header    Host      $http_host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

We're also going to redirect the http route directly to HTTPS. For the original server that is listening on port 80, we want to add the following return statement:

return 301 https://yourdomain.com.

Check over the config file and reload it.

sudo nginx -t
sudo systemctl reload nginx

Now try heading to https://yourdomain.com and http://yourdomain.com. You should now have access and the http route should head directly to the https route!

So, it's come to a point where I need to separate out my blogs into their respective topics and document the results of my projects for sharing purposes. So, welcome to my first post on my tech blog which will provide a brief overview of Azure VMs, Docker and the Ghost blogging platform.

I've used the Ghost blogging platform previously (before it reached v1) and remembered how simple its interface is in terms of blog theming, markdown and content management so thought let's combine it with Docker to get it off the ground fast. So what will we be using?

• Ghost
• Docker
• Azure (You will need an account)

VM Setup

The first thing to do is to spin up an instance of a Ubuntu Server on Azure, the process is fairly straightforward; select create a resource and search for Ubuntu Server 17.10 VM. Follow the steps through with the following in mind:

• Choose a machine that your credit covers
• When you get to configuring the IP, make sure it's set to static otherwise redirecting a domain to the blog is not going to be possible.

Why use a Ubuntu Server instead of MS Server 2016? Well, the Docker containers as a preference run on Linux so if a container does not have a Docker for Windows configuration, we can't use it. There also seems to be some issues with HyperV on Azure when it comes to virtualising a Linux box for Docker on Windows so we can't use Linux containers on Windows Server 2016. Bummer!

Right, once the machines up and running we need to ssh onto the machine. Grab a copy of Putty if you don't already have it. Open a command line terminal at its location and type...

putty.exe -ssh {username}@{machine ip address}
(Note if SSH is blocked on your machine you can run this from another vm)

You will then get prompted for your password after which you'll then be connected to your VM.

Docker Setup

The next step is to set up Docker which fortunately Digital Ocean has provided a nice guide. Right now we're only interested in step one and two which consist of the following commands:

Install Docker

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
$ sudo apt-get update
$ apt-cache policy docker-ce
$ sudo apt-get install -y docker-ce
$ sudo systemctl status docker // Should indicate that Docker is installed

Configure Docker to bypass sudo

$ sudo usermod -aG docker ${USER} //Where user is your machine login
$ su - ${USER}
$ (Input password)
$ id -nG // will confirm that docker has been configured.

At this point I would also restart the VM to make sure the changes take effect. Good news - we are now ready to set up Ghost.

Installing Ghost

Fortunately for us, the Ghost team have already set up a Ghost container so let's pull it.

$ docker pull ghost // Will default to @latest

That's it, we have everything we need. All we need to do now is start the container with the following:

$ docker run -d --restart unless-stopped --name {choose a name} -p {choose a port}:2368 ghost

This will run the container as a background process (-d), it will restart until manually stopped (--restart unless-stopped), perfect for when the VM restarts. --name is how you will reference the container in Docker and the port (-p) is how you will access the blog e.g. http://localhost:{chosen port }.

Open the Port

The final step is to open access to the port in Azure. In the VMs menu, select networking and add a new inbound port rule. Set port range to the specific port you defined earlier and set priority to 100 and click OK.

Once Azure is done with that, you should now be able to access your blog through http://{VM ip}:{chosen port}. Nice!

You now have a Ghost blogging platform while your VM is running. To get to the blog manager just head to http://{VM ip}:{chosen port}/ghost which will get you to create an account. Following that, you can modify the content until your heart's content. Happy Blogging.