DEV Community: Austin Cooper

Azure Active Directory Authentication in ASP.NET Core 3.1

Austin Cooper — Mon, 03 Feb 2020 05:44:58 +0000

Originally posted here: https://austincooper.dev/2020/02/02/azure-active-directory-authentication-in-asp.net-core-3.1/

Intro

Using Azure Active Directory for authentication is super simple in .NET Core 3.1. There's a couple of things that need to be just right, and then it "just works." This guide assumes that you're already familiar with ASP.NET Core 3.1 and how those projects are structured. GitHub repo for this guide is here: https://github.com/cooperaustinj/azure-auth-demo

Set up Azure Active Directory in the Azure Portal

First, create a new directory:

Next, you can set up a test user under the Users section. Once you're happy with that, go to App registrations

When creating the new app registration, make sure to add a Redirect URI of http://localhost:5000/signin-oidc.

Under Overview in the app, note down your Client ID and Tenant ID.
Then, go to Authentication and check the two boxes under Implicit Grant. You can also add a logout URL if you're using HTTPS:

Integrate Azure Active Directory with ASP.NET Core 3.1

I'm using a new blank project created from dotnet new web. The following steps should work for an existing project as well.

First we need to add a package for Azure AD, so run:

dotnet add package Microsoft.AspNetCore.Authentication.AzureAD.UI.

Next, add the following to Startup.cs to register Azure Active Directory as an authentication provider and register controllers. Take careful note of the comments specifying the order we need to make calls on the application builder.

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    var config = new ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json", false)
        .Build();

    services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
    .AddAzureAD(options => config.Bind("AzureAd", options));

    services.AddControllers();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting(); // UseRouting must come before UseAuthentication
    app.UseAuthentication(); // UseAuthentication must come before UseAuthorization
    app.UseAuthorization();
    app.UseEndpoints(endpoints => // UseEndpoints must come after UseAuthentication and UseAuthorization
    {
        endpoints.MapControllers();
    });
}

We need to give our application the Tenant ID and Client ID from our app registration, so add the following to your appsettings.json (careful not to check this into source control with your IDs):

"AzureAd": {
    "Instance": "https://login.microsoftonline.com",
    "Domain": "demo283814.onmicrosoft.com",
    "TenantId": "<tenant id>",
    "ClientId": "<client id>",
    "CallbackPath": "/signin-oidc"
}

Wrapping up

That's it! You can now put [Authorize] attributes on your controllers and/or actions to require the user be logged in to visit them. You can even use Security Groups to only allow certain users access to endpoints, but that's outside the scope of this guide. Here's an example of a controller using the [Authorize] attribute. If the user tries to go to /secret without being logged in, they will be redirected to a Microsoft login screen. After logging in, they'll be redirected to the secret page.

[Route("/")]
public class HomeController : Controller
{
    [Route("/")]
    public IActionResult Index()
    {
        return Ok("Home page");
    }

    [Authorize]
    [Route("/secret")]
    public IActionResult Secret()
    {
        var identity = ((ClaimsIdentity)HttpContext.User.Identity);
        var name = identity.Claims.FirstOrDefault(c => c.Type == "name")?.Value;
        var email = identity.Claims.FirstOrDefault(c => c.Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name")?.Value;
        return new OkObjectResult(new { name, email });
    }
}

Using Vue Observable as a State Store

Austin Cooper — Sat, 16 Nov 2019 03:25:11 +0000

Original post here: https://austincooper.dev/2019/08/09/vue-observable-state-store/

Version 2.6.0 of Vue.js added Vue.Observable. This is a function that returns a reactive instance of a given object. In Vue, objects are not automatically reactive. That means that if we want to react when properties on an object change, we need to do some extra work. Vue.Observable makes that super easy. Read more about reactivity
here.

Non-Reactivity

const obj = {x: 0, y: 0};
export default { // Vue component
    data() { return {}; },
    method() {
        updateObj() {
            obj.x = 1;
            obj.y = 2;
        }
    }
}

In this example, calling updateObj will not trigger a re-calculation of computed values nor re-render the view. Fortunately, Vue components have the data function. The object returned by data is reactive!

Reactivity via data()

export default { // Vue component
    data() {
        return {
            obj: {x: 0, y: 0}
        };
    },
    method() {
        updateObj() {
            this.obj.x = 1;
            this.obj.y = 2;
        }
    }
}

Since the result of data is made reactive, calling updateObj will cause computed values that depend on obj to be re-calculated and update the view if needed.

Breakout State from Components

In basic components/applications, all mutable data is put into the object returned by the data function. Storing all of the app's data in data functions on each component quickly falls apart. In particular, this becomes an issue when data needs to be passed between sibling components.

Does the component with the data pass it up to the parent component via events and then the parent component passes it down to the sibling component via props? Even in simple cases, this is immediately a code smell and not a great development experience. It couples components, is difficult to test, prone to bugs, unmaintainable, and plain confusing.

This is where state stores come in.

State Management

Vuex is the go-to state store plugin for Vue.js. Here's how vuejs.org describes Vuex:

Vuex is a state management pattern + library for Vue.js applications. It serves as a centralized
store for all the components in an application, with rules ensuring that the state can only be
mutated in a predictable fashion.

That's great, but Vuex is not quite trivial to use. For one, it needs to be added as a plugin to your Vue app. Two, it is very powerful, making it daunting to get started with. Finally, many applications are simple enough to not need Vuex and all its features for state management.

So, what's the alternative to Vuex? Of course, the answer is the topic of this post: Vue.Observable.

Vue.Observable as a State Store

Finally with all the background established, here's how to use Vue.Observable as a state store.

store.js

import Vue from 'vue';
import axios from 'axios';

const state = Vue.Observable({ // this is the magic
    radius: 0,
    color: 'red'
});

export const getters {
    radius: () => state.radius,
    color: () => state.color
}

export const mutations {
    setRadius: (val) => state.radius = val,
    setColor: (val) => state.color = val
}

export const actions {
    fetchRadiusFromApi() {
        return axios
            .get('http://localhost:5001/api/radius')
            .then((res) => {
                mutations.setRadius(res.data);
            });
    },
    fetchColorFromApi() {
        return axios
            .get('http://localhost:5001/api/color')
            .then((res) => {
                mutations.setColor(res.data);
            });
    }
}

Line 4, where we declare state, is where the important part happens. Getters and mutations are how we read and update the state. Actions are where async calls go, namely API requests. Actions commit mutations, potentially based on the results of API requests.

component.vue

<template>
    <div>
        <div>Radius: {{ radius }}</div>
        <div>Color: {{ color }}</div>
        <button @:click="setRadius(0)">Reset radius</button>
        <button @:click="fetchColorFromApi">Fetch color</button>
    </div>
</template>

<script>
    import { getters, mutations, actions } from 'store.js';

    export default {
        data() { return {}; },
        computed() {
            ...getters // radius(), color()
        },
        created() {
            this.fetchRadiusFromApi(); // fetching data right away
            this.fetchColorFromApi().then(() => {
                console.log('You can chain then after actions, if you return the request');
            });
        }
        methods() {
            ...mutations, // setRadius(val), setColor(val)
            ...actions // fetchRadiusFromApi(), fetchColorFromApi()
        }
    }
</script>

Wrapping Up

That's it! Any components can just import store.js and share the same state. No need to use props/events to pass around data.

Bonus tip for components that don't need all the getters or need a computed value:

component.js

computed() {
    // ...getters <- instead of this, do this:
    radius() {
        return getters.radius;
    },
    diameter() {
        return getters.radius * 2;
    }
    // this component doesn't need color
}

Creating Custom Middleware in ASP.NET Core (Part 1)

Austin Cooper — Sun, 25 Aug 2019 19:53:22 +0000

Original post: https://austincooper.dev/2019/08/25/creating-custom-middleware-in-.net-core/

What is middleware?

Simply, middleware is code that becomes part of a pipeline to handle requests and responses in a web app. In ASP.NET Core, middleware is a big deal! All requests are handled by a pipeline of middleware.

If you've created an ASP.NET Core app before, you are probably aware of the UseDeveloperExceptionPage middleware. This middleware adds special exception handling. If an exception is thrown later in the pipeline, the exception bubbles up to this middleware, which returns a nice page with details as a response to the request. Because middleware is a pipeline, order matters. For the developer exception page, it's important that it is one of the first middleware added to the pipeline.

Find the code for this post on GitHub!

Getting started

For this guide, I'm starting with a project creating using dotnet new web. This command creates an ASP.NET Core project with the minimum amount of boilerplate.

// Startup.cs
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
}

Even in this most basic project, we already have two middleware components: UseDeveloperExceptionPage and Run. We already know about UseDeveloperExceptionPage. Run is a terminal middleware. A terminal middleware stops processing additional middleware for the request.

Use is a another middleware we can use. It is not necessarily a terminal middleware, like Run. It can be terminal or non-terminal depending on whether the next middleware is called. Use will be how we write our first custom middleware.

Custom Middleware

Let's add some custom middleware to our Startup.Configure method.

- public void Configure(IApplicationBuilder app, IHostingEnvironment env)
+ public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILogger<Startup> logger)
 {
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
+
+    app.Use(async (context, next) =>
+    {
+        logger.LogInformation("Request started");
+        await next.Invoke();
+        logger.LogInformation("Request finished");
+    });

    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
 }

We added a logger and an app.Use section. This is always a non-terminal middleware, because we call next.Invoke for all code paths within the middleware. To try this out, run dotnet run and navigate to http://localhost:5000. You should see Hello World! on the page, and something like this in the console:

info: CreatingMiddleware.Startup[0]
      Request started
info: CreatingMiddleware.Startup[0]
      Request finished

Enhance!

So we've created a super simple custom middleware that logs when a request is started and completed. Cool... but what else can we do? Let's make some changes to our app.Use block...

app.Use(async (context, next) =>
{
    if (context.Request.Path.ToString().StartsWith("/test"))
    {
        await context.Response.WriteAsync("Welcome to Test");
    }
    else
    {
        await next.Invoke();
    }
});

Now, our middleware is terminal when the request path starts with /test, returning the response Welcome to Test. To verify, navigate to http://localhost:5000/test. For routes that don't start with /test, we just pass-through to the next middleware.

You've likely noticed that we have access to the entire HttpContext in our middleware. We can check whether the user is authenticated, pull information out of the route, and read the body of the request. Of course, those are just some examples of the information we can get from HttpContext.

That's All for Now

Middleware is a pretty deep rabbit-hole, so I'm going to call this post here. I have more to write about, but that will have to come in later posts - I don't want to overload post with everything. Visit my personal site at http://austincooper.dev to subscribe and be notified when Part 2 comes out.