Software, Design, Architecture and Whatever Else
One of my favorite features of Azure DevOps is its package management feature where you can publish NuGet packages to your own organization’s feed. Packages in your feed can be referenced by other projects in the CI/CD pipeline or through Visual Studio. In this walkthrough I’ll give a simple example of how to use it. I’ll assume you’re comfortable with Azure DevOps. If you’re not familiar with the tool see my four-part series on the subject.
If you live in the northern hemisphere like me then this Friday is hibernal or winter solstice. For those of you in the southern hemisphere it will be the summer solstice. Either way happy solstice to all! For those of us in midwinter the Earth’s north pole is at its maximum tilt away from the sun. This means that the apparent height of the sun is at its lowest point in the sky on the winter solstice.
Believe it or not a bunch of people — your friends and neighbors — have no idea what I’m talking about right now. But I suspect you think astronomy is cool or you wouldn’t be reading this right now. So I’m here to help you build an awesome solar calendar in your front yard both to mark the changing of the seasons and to help visualize the sun’s apparent motion across the sky. Your neighbor kids will love it trust me. And it will be fun for you to design and build. After the jump is a photo of the finished product as it looks in the parking strip in front of my house.
I won’t repeat the project home page except to say that if you need good strong security for clients (MVC or otherwise) calling services (micro or otherwise) then this is for you!
Basic authentication middleware is no longer available in Core 2 and I’ve blogged about that before and wrote a SquareWidget.BasicAuth.Core NuGet package. Even with TLS you should probably not use it unless you have no choice. The password goes over the wire in base64 encoding rather than ciphertext, it sits there in the request header for the whole session, the user can cache it permanently in the browser, and anyone on the network can sniff it out before it gets to the web server.
So why do people use basic auth so much? One word: convenience. Developers fall back on the tried and true rather than take the time to do the right thing. So my aim with this middleware is to encapsulate all the goodness of HMAC and keep it dead simple so that the developer has no excuse for not using a more secure algorithm.
This is the introductory post in a four part series walking through the process of creating a project in Visual Studio and building out a complete CI/CD pipeline to get that code into production on Azure using Azure DevOps.
Here’s a rough outline of where I think this series will go. As soon as I have the content ready I’ll link to them from here:
Part 1: Publish to an Azure DevOps Repository
Part 2: Setting up a Build Pipeline in Azure DevOps
Part 3: Setting up a Release Pipeline in Azure DevOps
Part 4: Adding a Database to the Project
A little context… Lately I’ve been using the Eclipse plugin Subversive for source control on my java-based projects, which uses an on-prem SVN server. For C# projects I use the Visual Studio plugin VisualSVN. Back in the old days I used an on-prem TFS server. Before that VSS which I’ll just leave that right there. So I’ve used SVN for many years and I have no complaints about it in particular or concurrent version control systems in general. But this series isn’t about those tools or centralized version control. And it’s not about Git Bash or shelling out to the command line from GitHub Desktop or anything like that. Download the Pro Git book if you want to dive deep into that area.
I’ve also used TFS v1.0 and before that NAnt and then CruiseControl somewhere along the line. Currently my place of work uses TeamCity for builds, NUnit for tests, Octopus for deployments and probably other things like DbUp for database scripting. And I’ve deployed straight to Azure from Visual Studio more times than I can count. But guess what? This series isn’t about any of those things either. In this series I want to help you to take your game up to the next level so that your pipeline to production is fully automated. And I want to keep it as simple as possible. So let’s get started at Part 1.
This is Part 4 in a series on Azure DevOps.
In Part 1 I created a simple web app called WidgetApi. I then put it under source control and pushed it up to an Azure DevOps repo. In Part 2 I configured a build pipeline and made a code change to trigger that build with continuous integration. In Part 3 I set up a release pipeline and deployed our build artifacts to Azure. In this part I’m going to add a database to WidgetApi and use a DACPAC file to bundle database changes for deployment in the release pipeline. Finally, I’ll configure a production environment with an approval process.
This is Part 3 in a series on Azure DevOps.
In Part 1 I created a simple web app called WidgetApi. I then put it under source control and pushed it up to an Azure DevOps repo. In Part 2 I configured a build pipeline and made a code change to trigger that build with continuous integration. In this part we’re going to create a release pipeline that deploys our build artifacts to Azure.
Continue reading “Part 3: Setting up a Release Pipeline in Azure DevOps”
This is Part 2 in a series on Azure DevOps.
In Part 1 I created a simple web app called WidgetApi. I then put it under source control and pushed it up to an Azure DevOps repo. In this part we’re going to set up a build and then change our code to trigger a continuous integration build. Open the browser and go to your Azure DevOps portal. You should see all your pushed commits there from Part 1. Awesome. Now there’s a couple of housekeeping things to do before we set up the build.
Continue reading “Part 2: Setting up a Build Pipeline in Azure DevOps”
In this series I’m going to use the free Visual Studio 2017 Community Edition and the free Azure DevOps to target a full-blown CI/CD pipeline to deploy a web application to Azure. So in addition to those tools make sure you have an Azure subscription. Last, I’ve got the latest Git for Windows installed (v2.19.1.windows.1). So let’s get started after the jump.
Continue reading “Part 1: Publish to an Azure DevOps Repository”
There’s very little guidance from Microsoft on writing your own custom authentication handlers for Core 2. If you look at the documentation you’ll find detailed guidance on the built-in Core Identity model that they want you to use. They also provide links to third-party open-source providers like Identity Server which is what I use in this example. There is an article on custom cookie authentication. But generally speaking because security is hard and it’s way too easy to screw up Microsoft would rather you did not roll your own. It’s best to stick to the prescriptive guidance Microsoft offers. Now that I’ve said that I’m going to ignore completely my own advice. Read on if you’re with me.
Continue reading “ASP.NET Core 2.1 Web API Using Multiple Authentication Schemes”
Well just like the title says I want to show a complete microservice-based architecture using the lightweight IdentityServer4 for authentication and Ocelot as an API gateway. Ocelot will act as a reverse proxy for a secured internal ASP.NET Core Web API. Everything here is open-source .NET Core 2.0 or later.
The main source of guidance I consulted for this architecture is the eShopContainers project and the white paper they published (which I read cover-to-cover at my favorite coffee shop and I recommend you do the same). There are a few helpful blog posts out there too. Dan Patrascu-Baba wrote a couple posts (here and here), Scott Brady wrote a helpful intro to IdentityServer4, and Catcher Wong wrote a nice series on Ocelot. But I couldn’t find a “complete picture” presentation of the whole architecture so I decided to write it myself. My goal here is to present a bare bones framework in one place to help bootstrap a serious microservices project.
I’ve organized this post into three parts: (1) The Big Picture; (2) The Configuration; and (3) The Deep Dive. Let’s get started right after the jump…
Continue reading “Microservices with IdentityServer4 and Ocelot Fronting a .NET Core API”