Every time I run a command that had to connect to the deamon, I was getting the same exact error:

docker: Cannot connect to the Docker daemon at unix://Users/<user>/.docker/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

This was not fun. But after a bit of googling (yes, ChatGPT etc couldn't help), I stumbled across the solution on this StackOverflow post

The cause of the problem is that at some point, Docker removed the /var/run/docker.sock symlink in default behavior. If you're curions, you can find more details about this in the Docker release notes here or you can skip straight to the fix

The fix

We have to manually add a symlink You have to follow the steps below to fix the issue on your MacOS

1. Quit the Docker Desktop app
2. Open your terminal, copy-paste the following and press Enter

sudo ln -s ~/Library/Containers/com.docker.docker/Data/docker.raw.sock /var/run/docker.sock

3. Restart Docker Desktop
4. Run the following command to ensure that the symlink works

DOCKER_HOST=unix:///var/run/docker.sock docker ps

If everything worked as expected, the output should look similar to this:
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

5. (optional) if you use zsh then you also need to update your .zshrc file and add the following setting:

export DOCKER_HOST=unix:///Users/$USER/Library/Containers/com.docker.docker/Data/docker.raw.sock

And that' all there is to it. Now, you're good to start interacting with your Docker deamon

What is Amazon Polly?

Amazon Polly is a text-to-speech service that uses advanced deep learning technologies to convert written text into lifelike speech. It comes with dozens of high-quality, natural-sounding voices in various languages. You can quickly test and find the one that meets your requirments and specific user case here

The Polly is extremely simple and allows developers to quickly create applications that can interact with a human-like voice. Polly supports a wide range of use cases, from enhancing accessibility in applications to creating engaging voiceovers for multimedia content.

Getting Started with Amazon Polly in Python:

Step 1: Set Up Your AWS Account

Before diving into Amazon Polly, ensure you have an AWS account. Set up an IAM (Identity and Access Management) user with the necessary permissions to interact with Polly. The best policy that allows all actions except deleting of Lexicons is shown below:

{
   "Version": "2012-10-17",
   "Statement": [{
      "Sid": "AllowAllActions-DenyDelete",
      "Effect": "Allow",
      "Action": [
         "polly:DescribeVoices",
         "polly:GetLexicon",
         "polly:PutLexicon",
         "polly:SynthesizeSpeech",
         "polly:ListLexicons"],
      "Resource": "*"
      }
      {
      "Sid": "DenyDeleteLexicon",
      "Effect": "Deny",
      "Action": [
         "polly:DeleteLexicon"],
      "Resource": "*"
      }
   ]
}

Step 2: Install Boto3

Boto3 is the AWS SDK for Python, and you'll need it to interact with Polly. Install it using the following command:

pip install boto3

Step 3: Create a Polly Client

In your Python script, create a Polly client using the Boto3 library:

import boto3

# Create a Polly client
polly_client = boto3.client('polly', region_name='your-region')

Step 4: Synthesize Speech

Now, you can use Polly to synthesize speech from text:

audiofile= 'voicefile.mp3'

response = polly_client.synthesize_speech(
    Text='Hello, you are now using Amazon Polly!',
    VoiceId='Joanna',
    OutputFormat='mp3'
)

# Save the audio file
file = open(audiofile, 'wb')
file.write(response['AudioStream'].read())
file.close()

Putting it all together, including the ability to output the audio file using your system's audio device can be found in this gist

amazon_polly_python

amazon_polly_python. GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

Conclusion

Amazon Polly, coupled with the versatility of Python, provides an easy, low friction, and affordable way to integrate text-to-speech capabilities into your applications. Whether you're building a voice-driven application, adding accessibility features, or creating engaging multimedia content, Amazon Polly is the service for you :)

Since I moved to AWS I've been looking into the various services and Lightsail seemed very promising for my needs. Lightsail is a lightweight, low cost (pun intended) but truly capable service for hosting web apps. It comes with a number of integrations, called blueprints and supports both Linux and Windows OS with Windows being slightly more expensive. One of the Blueprints supported is Ghost, albeit still on version 4.4.x at the time of writing this blog .

Create a Ghost Instance

Let's see what it takes to spin up an instance to run a Ghost blog! In the AWS Console, select Lightsail. This will actually open a new tab on your browser. We need to follow 4 basic steps to spin up our instance:

1. Select the OS flavor

2. Select the Blueprint you want - in this instance Ghost

3. Choose the instance size - it's an EC2 instance under the hood anyway

4. Give it a meaningful name

Wait for a few minutes and you should have your Ghost instance up and running.

Add a static IP address

Once your instance is available, you'll need to add a static IP address to make it available to internal or external DNS providers. My DNS service is Cloudflare and I already own a domain, so a static IP address is needed to map my domain to my blog running in Lightsail.

Back at the Lightsail home, select the Networking and press the Create Static IP button

See it in action below:

Weird things I had to do

Since this was a migration and not a straight up new blog site, I was imported my content, via the old exported json file, to the new blog just fine. However, I had over 10 years worth of images that couldn't be uploaded via the Ghost admin portal.

For that, I had to use SFT with SSH. Filezila connected fine to the remote instance but the bitnami account lacked the appropriate permissions to create folders and upload files.

I had to spin up an SSH session and use the following commands to give the bitnami account the write permissions to the images folder:

sudo chown bitnami <your folder name>
sudo chmod +w <your folder name>

Note that the username is bitnami and the SSH private key you can acquire

The second issue I encountered is that all the image URLs were resolving to http://localhost/..... I knew that this was a configuration issue somewhere. First I looked for any weird hardcoded values, since I was editing and developing the blog locally prior to uploading the updated template. However, I quickly ruled out the hardcoded values and I worked out that the images where using the https://cmatskas.com variable which gets populated from the config.production.json file.

Back in my SSH session, this is what I had to do:

1. Open the file in VI with: sudo vi config.production.json
2. Update the URL with the right domain name, i.e https://cmatskas.com - note that the old value was the original public IP address of the Lightsail instance which didn't resolve to anything since I configured a static IP address
3. Restart both Ghost and Apache with the following commands:

sudo /opt/bitnami/ctlscript.sh restart ghost
sudo /opt/bitnami/ctlscript.sh restart apache

Custom domain

Configuring a custom domain is really straightforward. I use Cloudflare both for SSL termination and for domain name management. Since cmatskas.com is already registered with Cloudflare, what I needed to do was remove the old DNS mappings, some A and CNAME records and add two new A records to point to my Lighsail instance.

In Cloudflare, navigate to your DNS section and add an A Record  for the root and www versions of your website that point to the static IP address configured on your Lightsail instance. This is what mine looks like:

Job done....

Lingering issues

I still need to work out why http requests to my domain don't resolve properly and end up in 127.0.0.1. If you're a DNS wizard and can help out with that, please do let me know what I've done wrong, because as we all know... IT'S ALWAYS DNS!!!

Over the past few years, I built a decent home gym that contains most of the equipment I need to be train. Squat rack, bars and plates, dumbbells, platforms, pull up bars etc. Training has been good with a steady progress and I’ve managed to hit some good numbers across most of the major lift. Nonetheless, there is only so much you can achieve with training for 1hr, 3-4 days a week. My goal has always been to be fit and healthy to enjoy life. I’ve never idolized size or the strength that comes with it. Functional strength and flexibility do real-world activities without running out of breath is nice. Also, working out allowed me to be more liberal with my diet and eat “unhealthy”  sometimes - as to enjoy life. I mean, I’d love visible abs and a 6-pack like everyone else but

• Sustaining a < 10% body fat in real world is hard / unreasonable
• I like my food
• I have too much hair to even show a six pack, LOL

Ok.. enough with weight training, although if you are curious and want to discuss, hit me up

Why triathlons then?

Back to my original question… how did I get here? Last summer (Jul ’21) in the middle of the COVID pandemic I picked up David Goggin’s book - Can’t Hurt Me. David is an insane person and his book is definitely worth the read. He’s incredibly motivational and inspiring although some (many) of his methods are extreme and dangerous (please seek advice from your physician and trainer if you’re going to embark in David-style training - seriously). Regardless of methodology, the book offer some great gems of wisdom and it spoke to me. So much so that before I even finished the book, I signed up for a triathlon!!! At least I talked myself out of an IronMan because that would have been crazy :) A triathlon was something totally out of my comfort zone. I’ve done weight training for the past 15 years with very little cardio, apart from the occasional weighted HIIT. So this was an opportunity to reinvent myself, find my limits and push past them. I chose something that was within my grasp yet far enough and challenging to make me (and my family) question my life choices - LOL

What is a triathlon

A triathlon (as the name indicates - if you’re Greek then you know what I’m talking about) is 3 sports in one all happening sequentially on the same day:

1. Swimming
2. Cycling
3. Running

Depending on the event, the distance for each differs. And if you’re ready for a bigger challenge, then you can graduate to a half or full IronMan.

Did I mention that I hate(d) all of the above sports? Yes, I hate running with a vengeance and yet if you ask me today to go for an 8mi run, I can do it without an issue. I also sucked at swimming because I didn’t know how to swim. Swim lessons are your friend no matter your ability. Swimming is absolutely awesome once you’re comfortable in the water. I went from barely being able to do one length in the pool without running out of breath and feeling like I did a 100m sprint to being able to swim 2500m in open water unbroken or racing for 1mi. Cycling - I hadn’t been on a bike since 2007 and I didn’t even own a bike before starting triathlon training. I can now put 50-60mi where I can average 20-22mph and still be able to go for a run right after it.

Training / Coaching

I made the best decision of my life to hire a coach - my coach is Paul Rakness and he's simply awesome. I wanted a certified and successful coach to guide me through the experience. Yes, I could have done it myself. There are plenty of programs available online but for me my coach has been invaluable on this journey. Besides scheduling everything for me and touching base regularly on how I’m doing, we continuously adjust and adapt my program to fit my work and family needs. So if I’m too busy with work one day or I have to skip a workout due to traveling or illness, he adjust my schedule so that I can hit my milestones. Paul is a fantastic coach not so much for the programming (although he’s ace at that too) but because he takes the uttermost care to keep me healthy and fit to continue my training. This is vitally important because it’s easy to go too hard and too fast and injure yourself, especially if you’re old like me. At 43 I’m feeling that my recovery has slowed down and progress is slower. In the past 10 months, despite Paul’s best efforts, I did hit a few health snags that required an MRI, two specialist visits and multiple physiotherapist sessions to nurture me back to health. This meant that Paul had to work around my physical limitation and keep me on track despite the fact that I couldn’t run for an extended period of time. It’s also worth mentioning that Paul really “hates” me and sometime I can tell based on my workouts. Like - this guy really wants to kill me!!! If you’ve done an FTP, then you know what I’m talking about. Joking aside, he’s helped me push myself while being supporting and encouraging every step of the way :D

My coach has also been an important advisor when it comes to nutrition and equipment - because both can be expensive if you don’t know what you’re doing. More on this in a bit. In any case, if you plan on starting Triathlon training (or any other sport) get a qualified coach, it will be the best money you spend.

In addition, paying for training creates accountability which itself enforces consistency. Finally, there is a second element of accountability: reporting. Everything I do gets recorded and reviewed by Paul. Therefore, if I miss a session there better be a good excuse!! More than money, knowing that Paul expects me to hit certain goals means forces me to stay on track. It sounds funny but I don’t want to disappoint my coach or myself and this is a great incentive…

Paul, when you read this, now that I’m extremely grateful for having you by my side along the way and for helping me get closer to my true potential. I would’t be here without you!

Equipment

No matter what sport you choose to participate in, you have to spend some money. Now imagine signing up for 3 sports at once! I’m lucky my wife hasn’t divorced me yet with all the new equipment I had to buy. I will explain my approach below but everyone’s different. At minimum you need a bike (any bike - although a good bike does make a difference), running shoes and a swim suit. Let’s break it down:

Cycling

I bought a second hand Specialized gravel bike for my triathlons. I then put some intermediate tubeless tires (big mistake) and power pedals. Before spending serious time on the bike, I also got a bike fit. There are specific shops that can fit the bike to your body type and needs. I spent nearly 4hrs finding the right saddle as well as repositioning everything to fit my body and style of cycling. Again, if you are serious about this, I would highly recommend getting your bike fitted. Solid advise from Paul. I also bought a Wahoo Element bike computer to track my cycling when outdoors. However, 90% of my training has been indoors, spent on a bike trainer, the Wahoo Kickr. Why? Because I live in the PNW where the weather is awful for the majority of the year and having a trainer allows me to be more flexible with my schedule. I can wake up at 5.30am and hit my workout from the comfort of my garage. No rain, no cold, no special lights, no danger getting hit by cars etc etc. A trainer also allows me to work off the raw power output (Watts) and target my workouts on specific targets to build stamina and strength. Without power pedals (which I had to hold off buying for nearly 9 moths) a trainer is perfect. It is a costly investment but totally worth it, especially if you don’t get nice weather or have nice bike tracks where you live. There is an associated cost for Zwift which is the app that allows you to virtually cycle anywhere in the world and connects with the bike trainer to adjust resistance based on altitude etc. Again, I happily pay for this for the convenience and safety that it offers. Finally you need clothes. You know, the cycling, lycra type ones that are super tight and less flattering. But they come with padding and help with absorbing sweat with clever pockets to put phones and nutrition so, highly worth the investment. There is a price range and you need to find the ones that fit you best and make you feel comfortable on the bike. And let’s not forget the shoes - the ones that clip on the pedals. I tried several pairs and since I have wide feet it took a bit of research. I spent the first 9 months with numb feet on the bike. I pushed through it thinking it’s fine until my first race T-run ( a transition run from the bike to the run) where I could barely run because I couldn’t feel my feet. Stupidity comes at a price. I exchanged them the next day for a pair that actually fits my feet.

Running

Running is much easier. All you need is a good pair of shoes and some comfortable clothing. But you also need something to track your runs and your fitness. My shoes are Nike. I’m a Nike person and no matter what else I try, I always come back to Nike because I’m either used to them or they fit me the best. In any case, I run best on Nikes. For tracking my runs and fitness, I went with the Wahoo Rival watch. I finally ditched my Apple Watch after 5 years of dutiful service. The Wahoo watch is great. Price wise comes at mid-range (when compared to the high-end Garmin ones for example) at $329 and can track Triathlon activities, including races. And even though it’s optimized for Triathlons it works for most other sports as well and has a great companion phone app. It provides enough smart elements to allow me to stay connected with my phone as well through txt messages and phone calls - which is really all I want from my watch anyway. I also picked up the Wahoo Tickr HR monitor from Wahoo as the watch is not perfect at tracking my HR and when I’m on the bike trainer I don’t use my watch (double tracking) so I needed a way to reliably and consistently track my HR. I also sweat a lot so I got a head band (like Rambo) to keep the sweat from getting into my eyes. I look silly but I don’t really care about appearances anyway :) For longer runs, I have a water bladder in a backpack to keep me hydrated as I run hot and I need water and electrolytes

Swimming

Swimsuit, googles and a gym with a pool (or your own pool if you’re wealthy). Speedo seems to be the de facto one for swimsuits so I got that. For goggles, I started with off the shelf stuff but I now love my Magic5 which are built around your face. I just ordered a second pair since I lost mine after my last race :( . Most of my workouts take place in the pool, either solo or with my team. However, endless hours in the pool cannot replace OWS (open water swims). I hated swimming and I hated deep water. I had a fear of the unknown and not being able to see what’s below me. I grew up swimming in Greece where most of the beaches have crystal clear water. As soon as I lose that I literally panic and swim back to the safety of the clear water. Fear of the unknown is also accentuated by the lack of skill. I mean, if I can barely do a length (25m) in the pool without running out of breath, how the hell can I feel comfortable swimming in open water - ALONE???

My first open water experience was 1 month into my training with my coach. We were supposed to do 400m in one of the nearby lakes in early October. I accepted the invite because there is no way I can say NO to Paul! We arrived at 8am, I put my wetsuit on and got in the (cold) water. The wet suit, which I was wearing for the first time in my life BTW, did a great job job in keeping me from going hypothermic but, on the inside, I was freaking out. As soon as I got submerged, I started hyperventilating, I couldn’t see a foot ahead of me, it was dark, rainy and cold. Further more, I didn’t know how to do sighting (watch where you're going) and I could barely swim. As you can imagine, this went great!!! LOL Fast forward 7 months and I can now jump in any lake (yes any lake) and swim a mile comfortably on my own. I do have an inflatable buoy with I attach to my waste and drag behind me, in case I get a cramp or I need a break. For reference, I’ve only used it once to stop and adjust my goggle. A 1500m OWS is now pretty standard and I feel that I can hit much longer distances with ease. I’m still working on improving my form and getting better and more efficient but based on my last two races, apparently the swim is my strongest suit even at this shitty, less efficient form. Back to the equipment bit, you need a wetsuit (I was lucky to get a good second hand one) and a buoy if you plan on doing OWS regularly on your own.

Joining an IM/Triathlon team

Initially I wasn't convinced but after a bit of persuasion from my coach, I decided to join my local team (PR Performance). The team consists of some amazing coaches and athletes all focused on similar goals so it’s a great place to be. The team does many activities together, including organized swims and running track workouts. When time permits it, I try to join these as I get invaluable advice and new challenges to help me improve my fitness level and form in these sports. In addition, as a team we get discounts for gear from major IM brands so every little helps. Finally, it’s not uncommon for many team mates to show up at the same event which I find nice as I have a familiar face to talk to. After being with the team for 10months, I could recommend that you join a team as well, if that’s something available to you. Optional, but highly beneficial.

Nutrition and diet

An average workout burns about 1000 calories! I haven’t been extremely careful with my diet. I haven’t counted calories, micro or macro nutrients and yet, it’s the first time in my life I feel and look better. My weight has dropped down a bit (and could drop even further if I focused on my diet) but at the same time, I haven’t had to sacrifice anything and I can eat whatever the rest of the family eats. Carbs are super important and has been a big focus during my training and races. This is great because every other diet hates carbs and overindexes on protein and fats. For the past 10 months even been eating normally and I feel great. During training, I have to consume carbs so energy gels, bananas and bars are always in my fitness pantry. The problem is that it gets expensive quickly so you have to find the stuff that works for you and buy in bulk to save money.  Another important thing you need in your diet is electrolytes and salt (tablets). Drinking plain water won’t cut it so you need to also invest in decent electrolytes and salt tablets to ensure that you stay at peak performance throughout the workout or the race. Talking about racing, nutrition is a bit of a thorny subject for me since I cannot intake all the food I need. Pre-race I only have some light solid carbs to get my digestive system working and ensure I have a #2 before I leave the house. This works great. But once at the race ground and during the race, I struggle to intake enough food as I’m so focused on the race and my stomach can’t tolerate much food especially since everything is SO SWEET. I need something with blunt taste that I can down easily and I’m still searching for it! This is something I definitely need to work on.

Competing

I signed up for a Tri race without knowing what to expect. Lake Whatcom did not disappoint! After putting the work for 10 months, I was able to complete my first Olympic Triathlon in 3hrs and 11mins based on my watch and I’m still waiting on the official race results. I went from not being able to do any of the 3 sports well (or at all) to competing with 100s of other people, but mostly competing against myself. I didn’t finish top at the event or my age group this time around, but it was a major accomplishment to be able to race without suffering any major injuries or a DNF (Did Not Finish). I learned some important lessons about what we need to do in my training going forward to improve overall and I had a lot of fun pushing myself. Taking inspiration for David Goggins (what started all this) I was able to overcome physical and mental obstacles to finish strong! This was my 2nd Triathlon, with Lake Wilderness being my first, albeit a Sprint one and the 3 competitive event overall. I did run my very first half-marathon in March. A lot of firsts this year. A lot of opportunities to learn, grow and improve.

General notes

Triathlons are very different! In comparison to my weight lifting training, I always feel great after my triathlon workouts. I rarely feel in pain (unless injured) and I can spend the rest of my day being productive instead of having sore, broken muscles from lifting heavy things. After 10 months of consistent training, I have to admit that I enjoy this type of workout over anything else - to the point that I’m selling off all my old gym equipment. If you’re near Sammamish, WA and want to do a local pickup, let me know and I can send you a list of all my immaculate gym equipment that is sitting idle in my garage feeling unloved :D. This was the “little” bit. It takes a lot of consistency and effort. This is the first time in my life that I’ve been training 6 days a week for 10 months non stop. OK, Paul will say that Training Peaks says otherwise and I will agree that I have been known to miss a day here and there, but for the majority of time I try really hard to stick to my schedule, with all the changes and tweaks that real life dictates.

I need to get better at working out early in the morning. Early mornings during the summer are easier but getting up at 5.30am on a cold winter’s day is somehow infinitely more challenging. I would say that for the majority of my workouts, I manage to do them before 5pm and I rarely workout after 8pm as it’s not good for my body. Running and cycling are easier as I can do them at home or near my house but driving to the pool is what kills me. I think I need a pool in my back yard….LOL

I'm always wet!! I sweat too much during my workouts, I’m in the water swimming or I'm taking yet another shower  - some days have double workouts. There are gym clothes hanging to dry ALL THE TIME, but at least I don’t burden my wife with this task. She’s already tolerating too much of me and my hobbies

It’s an expensive sport, despite my coach claiming I have spent the least amount of money of anyone that he knows in this sport. If you’re clever you can save some money by getting second half stuff but certain things you need to buy new. Like a decent bike etc etc. Start small and build up. This is what I’ve been doing in the past year but I would say overall I’ve spent around $5-6k so far. Next year I’ll probably spend more as I need to get a better bike

Family support is extremely important. It’s hard enough to have to fight with yourself for motivation. It’s much harder having to fight with family for the time needed for all this. Training for a triathlon requires a lot of hours away from family. This is another reason why early morning workouts are great - you don’t have to sacrifice time with family.  

I wouldn’t have been able to get where I am today without the unending support and understanding of my family. My wife, beyond not complaining about all the new gear I had to buy, has been incredibly supportive of my goals and has been there with me every step of the way. If there is something I look forward to at every race is seeing my wife and kids waiting for me at the finish line. No medals or recognition can beat that - a massive thank you and all my love to my wife and kids for believing in me!

Looking into the future, I definitely want to get better at competing in Triathlons and eventually move up to a half-Ironman, assuming my body is aligned to my plans. If you've made it this far, I hope you enjoyed reading this and that it will inspire you to pick your own challenges (mental or physical) to get you out of your comfort zone and push you beyond what you thought was ever possible. And don't forget to have fun while doing it!

In this blog post, we'll see how to take our Windows Terminal with PowerShell Core to the next level :)

What we need to install

• Windows Terminal Icons
• Custom Fonts
• Posh-Git
• Oh My Posh

Most of these are straight downloads and installs with PoSh - using PoSH to make PoSH nice!

Install the Windows Terminal Icons

Open Terminal and run the following command:

Install-Module -Name Terminal-Icons -Repository PSGallery

Then edit your $Profile using your favorite editor - I'll use VS Code, so it will be code $profile

Add this line at the top: Import-Module -Name Terminal-Icons

Restart your Terminal for this to take effect and you should see something similar to this:

Install Custom Fonts

Most developers prefer clean, easy to read and work with fonts with ligatures. There are many fonts out there but few that meet all these requirements. Luckily, [NerdFonts](Nerd Fonts - Iconic font aggregator, glyphs/icons collection, & fonts patcher) have done a fantastic job in aggregating and listing some awesome, developer-friendly fonts. Find the ones you like and download them. Now, the tricky bit is to install them as you have to go through many many *.ttf or *.otf files. But don't worry, I got you covered! Unzip the font(s) to a folder and navigate into it and run the following script:

Ok! Fonts covered..

Install Posh-Git and Oh My Posh

As a developer you'll most likely have to work with Git so having the ability to quickly understand where things are, is very important. [Posh-Git](dahlbyk/posh-git: A PowerShell environment for Git (github.com)) is a fantastic tool that adds this capability to your PowerShell terminal:

Install-Module posh-git -Scope CurrentUser -Force

Then we want to install Oh My Posh, a PowerShell equivalent to OhMyZsh, that provides customization and theming for our editors.

Install-Module oh-my-posh -Scope CurrentUser

Ensure that you update your $Profile accordingly. Open it with your favorite editor and add these two lines at the top:

Import-Module posh-git
Import-Module oh-my-posh

With installation done, the next step is customization

Fancy progress bars in Terminal

If you use winget then you've seen the boring, monotone progress bars that are displayed during downloads or updates. Who likes that? WinGet now winget settings via a file so that you can customize it to an extent. Execute winget settings in the terminal. This will open the settings.json file which you can edit. I added the following to get the rainbow effect in the progress bar

 {
    "$schema": "https://aka.ms/winget-settings.schema.json",
    "visual": {
        "progressBar": "rainbow"
    }
}

Select a theme

Selecting a theme is a big decision. I know people that have spent hours tweaking the look and feel, colors and contrast of their themes. I'm lazy and I rely on the themes that the awesome open source community has built. Oh My Posh comes with way too many themes so if you want to have a quick demo how they would look in your terminal run the following command. This will apply each available theme to help you decide:

Get-PoshThemes

However, I recently fell in love with Nick Craver's (of the StackOverflow fame) theme: Craver. Make sure to update your Oh My Posh (if you're not new to this) and follow the Nick's instructions here: Craver's oh-my-posh profile.

Edit your $profile file to include your theme as per the example below:

Import-Module posh-git
Import-Module oh-my-posh
Import-Module -Name Terminal-Icons
Set-PoshPrompt -Theme Craver

Configure Windows Terminal

Lastly, you want to configure Windows Terminal with your favorite fonts and tweak. You can now do this in the UI or via the settings.json file - whatever makes you happy :)

After all this, my Terminal looks like this:

Let me know if you want me to publish my Terminal settings json file if you feel it will help you with your setup :)

NOTE: this is only the tip of the iceberg! Windows Terminal is extremely configurable so I would encourage you to look around and customize it even further

Summary

In any case, I'm really excited to see all the innovation and customization that has gone into Windows Terminal. I have been an avid user since the early preview/beta stages. Windows has always been behind MacOs and Linux in the terminal space and I always wanted to somehow have the equivalent of my iTerm2 with ZSH and OhMyZsh. These days it's the other way around where I want Windows Terminal on my Mac! But for now I'll compromise with what's available.

So, go ahead and tweak your Terminal to your liking - you can. Don't forget to tweet a picture of your terminal and tag me and Kayla Cinnamon @cinnamon_msft (the PM of Windows Terminal). We would love to see what you achieve!

Is there a video?

Funny you ask? I've also recorded a 4min video that takes you through the process if you are a visual person. Check it out:

Installation

First we want to remove old versions of Go. Run the following command in WSL Ubuntu:

sudo rm -rf /usr/local/go* && sudo rm -rf /usr/local/go	

Then we want to download the latest version (currently 1.18). The commands for this are:

wget https://go.dev/dl/go1.18.linux-amd64.tar.gz
tar -xvf go1.18.linux-amd64.tar.gz
mv go go-1.18
sudo mv go-1.18 /usr/local

Next we need to add Go to our environment profile so that it can get picked up by our command line. Open ~/.bashrc with VS Code or your favorite editor: code ~/.bashrc

Update the settings are per below:

export GOROOT=/usr/local/go-1.18
export GOPATH=$HOME/go
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

Restart your command line/terminal and verify that the latest version has been installed correctly by typing go version

Job done! Happy coding with Go(lang)

At the end of that blog post, I promised to show you how to take your app from local development to production seamlessly, leveraging Managed Identities on the Azure App Service.

What does the app currently do

Before setting things up on Azure, let's remind ourselves quickly what the application does and where Azure Managed Identities and Key Vault fit. The Razor Web App retrieves two secrets from Key Vault without having to configure any connection strings for accessing Key Vault. Visual Studio uses the currently logged in account to retrieve the secrets by leveraging a couple of libraries - as explained on the original post. Now I want to publish and run this .NET Core 3.1 app in Azure without changing any code. Let's do this

Deploying to Azure

There are many different ways to deploy your apps to Azure, Azure DevOps and GitHub actions highly recommended, but I will be lazy efficient and use the Right-Click Publish feature in Visual Studio. Once the publication is successful, I navigate to the Azure Portal to check my app. Since the code is configured to pull information from Key Vault at startup, my app is going to fail miserably the first time I try to run it since I haven't configured the Managed Identity yet. If you are presented with the following error message, it's perfectly normal and expected:

Ouch... let's fix this :)

Using System Assigned Managed Identities

As soon as we deploy our web app to Azure, a system assigned Managed Identity is provisioned to our app. You can check this by navigating to the Identity tab in our App Service. This is great as it saves me a few steps. However, this account doesn't have any permissions to any of my Azure Resources.

If you want to find more details about this identity, head over to your Azure Active Directory -> Enterprise Application where you can search by application name. The name of the Manage Identity matches the name of the App Service we deployed our app to:

I can now go to my Key Vault and assigned the necessary permissions so that my application can retrieve the secrets using the system assigned Managed Identity. In the Azure Portal, navigate to your designated Key Vault and open the Access Policies tab. Next, press on the Add Access Policy link

Since our web app only needs to retrieve secrets from Key Vault, we want to allocate the bare minimum permissions to the Managed Identity to reduce the risk that could come from a compromise. So, in this instance, we only need to assign List and Get permissions.

Next, we need to find the right principal. Again, you can search by name or object id, and select it.

Back in the Access Policies tab, we should now be able to see our Managed Identity with its two Secrets Permissions. Make sure to press Save to persist the changes. Back to our Web App, we need to do a restart to ensure that the new permissions are picked up. Run the app and.... what a glorious sight!

This all works out of the box with no code changes and minor modifications to our Key Vault.

Using User Assigned Managed Identities

As we mentioned earlier Managed Identities come in two flavors. The default, system-assigned is created automatically for us. But these MSIs are bound to the resource and can't be reused. User defined MSIs, on the other hand, are not bound to any resources and can be reused across multiple ones. In addition, a resource can have multiple user-assigned MSIs! This means that if we want to use user-assigned MSIs, we need to do some code changes. More specifically, we need to configure the AzureServiceTokenProvider with the identity we want to use. You can find more details about Service-to-Service authentication with MSI in the docs.

First, we need to define a new parameter in our appsettings.json file. The new parameter, we'll name it UserDefinedId will be used to store the clientId of our user-defined MSI. If you need to find the client id, run the following command in the Azure CLI

az identity list

If you need to first create a new identity, you can run the following command

az identity create --name <any unique name> --resource-group <resourceGroupName>

You can't use the ClientId in development as the code is not running in the context of Azure and it will throw and exception. However, we can update the code to handle both scenarios :)

Open the Program.cs class and update the code with the following:

The code here does a few things. First, it checks to see if the app is going to use a user-assigned or a system-assigned MSI based on the value of the UserAssignedId parameter in the appsettings.json. If the value is empty, then we assume that the app is either running locally (you can't use user-assigned MSI in dev) or it's using a system-assigned MSI with the default constructor for the AzureServiceTokenProvider. If, however, the paramater value is set, then the code knows that we're using a user-assigned MSI and instantiates the AzureServiceTokenProvider with the appropriate connection string. This is code is clever enough to work it out but I'm sure there are other ways we can implement this

Back in the Azure Portal, in the Identity tab on our Web App, we need to configure the User Assigned MSI

At this point, you also want to ensure that the System Assigned MSI is turned off

We also need to add a new App Setting for the UserAssignedId. In the Configuration tab on our Web App, we need to add a new Application Setting with:

• name: UserAssignedId
• Value: <The ClientID of our user-assigned identity>

Make sure to press Save to persist the changes. This will also restart the web app (for good measure, lol)

Finally, we need to ensure that our user-assignd MSI  has the appropriate permissions to access our Key Vault. Remember that we only need to configure the minimum permissions (i.e GET and LIST on the Secrets) and save the changes.

We can now test our web app and check that everything is working as expected!

Summary

Managed Identities are an invaluable tool for helping you create more secure solutions by removing the need to store keys, secrets, passwords or anything else that can be used to compromize your infrastructure. And with MSI being designed is a way to support this end to end, from development to production, you should be making sure to use this wherever it's supported.

The repo with a working example is on GitHub and you can always reach out to me if you have any questions!

Imagine the scenario where you already have an app that was coded without authentication. This could be an app that was developer to run internally but now it needs to be moved to Azure. To secure access to the app, you have 2 options:

• Add authentication in code so that users can log in with their enterprise credentials
• Use the Azure App Service Authentication option

The first one is more involved. You need to write code, test it and then push the new solution to Azure. It gives you a lot more control but requires code changes. The second option is instant. A few settings within the App Service environment and you're good to go.

At this point, you may wonder why do we need a blog post for App Service Authentication if it works so well. It works great, but it's not perfect for .NET Core 3.1 (yet!). Although the authentication works as expected, due to the differences between .NET and .NET Core, in ASP.NET Core apps the claims principal object doesn't get populated out of the box. That what we have in the official authentication:

At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature.

The user authenticates and gets access to the app but my app/code doesn't know who that user user is or what permissions (claims) the user has. A small setback - i know - but this is what I set out to fix with this blog post.

Prerequisites

• An Azure Subscription (get your's FREE here)
• .NET Core 3.1

The ASP.NET Core 3.1 app

I mentioned before that we don't have to do anything to our app to leverage the turn-key Azure App Service Authentication feature. But if we want to use the authenticated user identity to do custom checks, then using the code in this blog will allow you to do so. For this example I'm using Razor Pages but the code should apply to any ASP.NET Core web app.

The main changes in the app are:

1. A custom middleware to retrieve the user identity and claims based on the auth header
2. A  partial page to display a logout option
3. A new page to display all the user claims - this is to prove that we have access to the full user object

ASP.NET Core provides a straightforward way to work with its middleware unlike the 'olden days' when OWIN was our only option. With ASP.NET Core, anyone can implement (even me) custom middleware following some basic rules to ensure that the whole pipeline executes as expected. We don't want our middleware to break things. The ASP.NET Core docs do a great job explain how and what we need to implement in our middleware as well as some gotchas.

With that in mind, let's build our middleware that will take the information from the HTTP headers and check if there is an authenticated user before reaching out to Azure AD to grab the user properties

First, lets create a brand new .NET Core Razor pages app using the CLI. Open the shell of your choice and type the following:

dotnet new webapp

Now that we have the app barebones, we can add our custom middlware. You don't really have to, as you can stick your code directly into the Configure() method in Startup.cs but this can clatter the code and make it hard to read. Therefore, it is preferable to create a separate class for your middlware code. Let's name it EasyAuthUserValidationMiddleware.cs and add the following code:

The code looks at the headers, grabs the appropriate information, makes an HTTP call to Azure AD ( to grab the user claims and adds the user to the context so the Context.Current.User object is populated.

We now need a way to be able to wire up our middleware to the rest of the ASP.NET Core pipeline. For that, we need a few lines of code to expose our middleware and the code below shows how to do it. Create a new class called EasyAuthUserValidationMiddlewareExtensions.cs and add the following code:

The final step is to configure our app to use our middleware. Open the Startup.cs class, go to the Configure() method and add the following line:

app.UseEasyAuthUserValidation();

That's all we need. It's concise and neat and... OK, it should be part of the framework and shouldn't require any extra work on your part but we're working on this. In the meantime, we have a working solution. So let's put our solution to practice.

Enumerate the logged in user claims in the app

Up until this point I didn't have to write any code to implement the authentication. In fact, my app would happily run as is. But I wanted to do a bit more in this example and actually interact with the user object. For this reason, will add a new Razor page, called Claims where I can enumerate, you guessed it, the user claims - only to show that my middleware is working as expected :)

In the Claims.cshmtl.cs class, I added the following code to grab the Claims and send them to the view:

public IEnumerable<Claim> UserClaims { get; set; }
public void OnGet()
{
	UserClaims = HttpContext.User.Claims;
}

And the in the Claims.cshtml I added the following code to check if the user is logged in (should always be) and enumerate the user claims on the page:

Running the app locally shouldn't break anything and only show this when going to the Claims page:

Next, we're going to deploy our app to Azure Web Apps and see what happens. Use the method that works best for you: Azure DevOps, GitHub Actions or right-click publish straight from Visual Studio - there I said it :)

Configure Authentication on the Azure Web App.

On the Azure portal, navigate to your web app and open the Authentication tab and flick the switch to On

We will be using Azure AD to configure authentication but as you can see we support a large number of additional providers such as Google, Microsoft Account etc

Select Azure Active Directory and proceed to use the Express settings to set things up. The Create App option will set up an Azure AD App Registration automatically for you when using the Express mode.

If you already have an App Registration that you want to use instead, you can configure this using the Advance mode. Pressing OK will configure the App Registration. There is one more step left to ensure that only logged in users can access our web app. Back in the Authentication tab, we need to select the right option from the drop down (you option will differ based on the Identity Provider you choose)

Since we chose to authenticate with Azure AD, we need to select the Log in with Azure Active Directory option and press Save to apply our changes.

Testing our authentication

You can see our code and Authentication setup in action on the gif below:

Other options

I agree that this may be too involved for your tasting and you may be looking for a simpler solution. How about if I told you there is a Nuget package that can do more or less the same as what I've shown you above. If you're interested, check out Maxime Rouiller's (Microsft CDA and great coder) blog post that explains how his library works and how to get it.

The main difference between mine and Maxime's code is that I check for the authorized user on every request whereas Maxime's library only executes on pages/controllers that have the [Authorize(AuthenticationSchemes = "EasyAuth")] attribute applied. And maybe his code is nicer :)

Conclusion

Adding authentication doesn't have to be complicated. If you have legacy apps or code that you don't want to update, the Azure App Service offers turn-key authentication using EasyAuth. In this blog post we covered how to set your Azure Web app to Authenticate user and then implement a custom middleware in our ASP.NET Core 3.1 Razor pages web app to retrieve and populate the user object.

I hope this is useful to you and as always, ping me on Twitter if you have any questions!

Prerequisites

Since Cosmos DB is an Azure service, you'll need and Azure Subscription. Grab one for FREE here! For this example we will also be using .NET Core 3.1 so make sure to download it here. Finally, you are free to use the IDE/tool of your choice - I'm using Visual Studio 2019 Preview this time around.

Components

• .NET Core 3.1
• Bogus NuGet package( create fake/sample data with Bogus and .NET)
• Cosmos DB NuGet package

Create a Cosmos DB resource

If you already have a Cosmos DB resource, you can skip to the next section. If not, keep going. I will be using the Azure CLI with CloudShell to create the Cosmos DB instance. If you're using the latest Windows Terminal, CloudShell is already a shell option :) If not, you can use the CloudShell instance on the azure portal or navigate to shell.azure.com to fire up a new instance! You can find the necessary CLI command documentation here.

The script necessary to create a new Cosmos DB instance is:

az login
az account set --subscription <SubscriptionName or Guid>
az cosmosdb create --resource-group <ResourceGroupName> --subscription '<SubscriptionName>' --name <CosmosDBName>

We can now grab the connection string so that we can use it later in our console app

az cosmosdb list-connection-strings --name <yourCosmosDBName> --resource-group <ResourceGroupName>

We've now completed our DB setup :)

Create the console app

As I started down this path, I was lucky to find some existing sample data in this Azure Samples repository. However, there were a couple of issues. 1. There were spaces in a couple of JSON properties and 2. I wanted richer data. So I downloaded the json file locally, did a quick search and replace to remove the spaces and then I started writing the necessary code to to enrich and push the data to my Cosmos DB database.

Next, we will use the dotnet CLI to create a new console app and add the necessary NuGet packages.

dotnet new console
dotnet add project <ProjectName> package Microsoft.Azure.Cosmos
dotnet add project <ProjectName> package Microsoft.Extensions.Configuration.UserSecrets
dotnet add project <ProjetName> package Bogus
dotnet add project <ProjetName> package Newtonsoft.Json

I also copied my sampleData.json file into the project folder and added the following into my *.csproj file so that it be copied to the bin folder:

 <ItemGroup>
    <None Update="sampleData.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>

Finally, from the command line, I executed the following command to initialize the secrets file so that I can store my Cosmos DB connection string outside my source code :)

dotnet user-secrets init
dotnet user-secrets set CosmosDBConnection "<one of the connections retrieved earlier"

And now the code in all its glory

There are a couple of helper methods here to set things up:

The BootstrapConfiguration() method returns an IConfiguration object with all the secrets (well, just one for our example). The PopulateMeasurementData() takes the JSON data we loaded from file and adds some extra measurement data using Bogus. The GetJsonDataAsync() loads the data from file and deserializes it into strongly typed objects. Finally, the BulkUploadDataToCosmosDB() takes our enriched data and bulk uploads it to Cosmos DB. The Main() method ties everything together and adds a bit of logging.

If you want to create sample data on the fly, you are welcome to fork the GitHub repo, add your Cosmos DB connection string and run the app to get some sweet, realistic Volcano data for your app :)

1. Azure AD to for token validation and authorization
2. The Function App
3. The Cosmos DB database

First, we will need to create and populate our Cosmos DB with some data. If you already have sample data then that's awesome, you can skip this step. Then we need to register two apps in Azure AD and configure application roles for our users. Finally, we will implement the appropriate code in our Functions to validate user tokens and then perform the appropriate CRUD operation in CosmosDB

Create and populate the Cosmos DB database

Head over to the Azure portal and create a new Cosmos DB database. Provide the subscription, resource group and a name for your Cosmos Account. If you want to simply test Cosmos DB and save some money, you can choose the Free Tier Discount. Please note that there are limitations to the free tier.

Press Review and Create if you wish to omit Networking or Encryption settings. Once our Cosmos DB instance is ready, we can create a new empty collection by navigating to the Data Explorer tab and selecting New Collection:

Since we will be working with the Volcano sample dataset, we will be using the id field as the Partition Key. To upload the sample data, we need to expand the Volcano Collection, click on the Items node and select the Upload Item option from the menu:

The import should be instantaneous, so refreshing the query results on the page should result to this:

One last thing we need to do is make a note of the connection string as we will need to configure our Azure Functions with it. Head to the Keys tab and grab the connection string (either the primary or secondary will work):

At this stage we have a Cosmos DB instance we can use with our Functions. Next, Azure AD.

Configure Azure AD for authentication and authorization

We will need to create 2 separate application registrations in Azure AD. One for our (Functions) API and one for the API client. You could have multiple API clients (mobile app, web, desktop) all with different scopes as well but for now we will keep it simple.

Create the API App Registration

First, the Function API app registration. In the Azure Portal, navigate to Azure AD select the App Registrations tab and create a new registration. Give it a meaningful name, select Single Tenant and leave the Redirect URI empty:

Next, navigate to the API Permissions tab and delete any existing Permissions (should be only one for Graph -> User.Read). Since this is an API that we want to expose to the world, we need to navigate to the Expose an API tab to configure our settings. First we need to add a scope so, press the Add a scope button:

Add a scope name, in this instance access_as_user, and the appropriate messages for admins and users. Make sure to press Add scope in the end:

If you want to change the Application ID URI, you can do so:

Finally, we need to add the Roles to our application. Unfortunately there is no UI to do this yet so we have to edit the json in the application Manifest directly.

We may not have an easy way to add Roles to an app via the UI for now but we do have a way to do all this using the Graph API. At /build we announce the GA availability for Applications which means that you can now programmatically create and configure app registrations via the Graph SDK

Open the Manifest tab and edit the appRoles section. Interesting side-note: Emojis are fully supported, though you may want to approach this with some caution :) We will be adding two roles: a) Data.Read and b) Data.ReadWrite like below:

"appRoles": [
{
	"allowedMemberTypes": [
		"User"
	],
	"description": "Read-Write access to CosmosDB data",
	"displayName": "😂😂👏✌Data.ReadWrite",
	"id": "0e13539f-f5d6-4b94-a349-4b178f677759",
	"isEnabled": true,
	"origin": "Application",
	"value": "Data.ReadWrite"
},
{
	"allowedMemberTypes": [
    	"User"
    ],
    "description": "Read access to CosmosDB data",
    "displayName": "Data.Read",
    "id": "caf1baec-8df5-4358-9703-6a5adc9a6a82",
    "isEnabled": true,
    "origin": "Application",
    "value": "Data.Read"
}],

You'll also need to update the AccessTokenAcceptedVersion to 2 (i.e. AAD v2) or otherwise the token validation process will fail later in our Functions code.

Make sure to press the Save button to persist the changes. At this point, we're done configuring the API app

Create the client API app registration

There could be many different clients that consume our API. In this instance, we will use Postman to emulate the front end but the important bit here is that each client app registration could come with different scopes and hence different access levels or restrictions. Our Functions code will be responsible for checking and validating both the access tokens and the user claims.

We have to create a new single-tenant app registration, but this time we need to provide a Redirect URI so that Postman can receive the JWT token (like PIN number - I know). The right Redirect URI for Postman is https://www.postman.com/oauth2/callback. We don't have to select Access or ID tokens in the configuration. Since we're using Postman, we also need a client secret, however depending on your front-end stack, you may not need one (see web app etc). We can create a new secret in the Certificates & secrets tab. Make sure to make a note of the secret as you won't be able to get it back once you leave this tab - you can, however, recreate it as they are cheap and easy to generate :)

Next, and final step, we need to configure the API Permissions for our app. Press the Add a permission button and select My APIs. We should be able to see the FunctionAPI app registration we created in the previous step.

Select the API Permission (scope) we configured for our FunctionAPI app and press Add Permissions

As a final step here, we need to Grant admin consent

Almost done. The very last step is to assign users to the application roles. This is done in the Enterprise Applications tab in Azure AD. Find the FunctionAPI app we registered in step one and select Assign users and groups.

Select Users and then assign them the appropriate roles:

You can assign multiple users and multiple roles simultaneously to speed things up as well :) Now, I know I shouldn't but I couldn't resist adding some emojis to our Role Permissions, which, surprisingly, showed up in the role selection window! Who said Identity and Azure AD can't be fun?

Our Azure AD configuration is now complete. 2 out of 3 tasks done. Now on to write some fun code!!!

Create a protected API using Azure Functions and Azure AD

We can use the Azure Functions Core Tools (CLI), the Azure Functions extension in VS Code or Visual Studio to create a new Function App and the following 3 HttpTrigger Functions:

• GetVolcano (GET,POST)
• GetAllVolcanoes (GET, POST)
• UpdateVolcane (POST)

For this example I will be using the Core Tools so the commands to create all these are:

func init
func function create -> HttpTrigger -> GetAllVolcanoes
func function create -> HttpTrigger -> GetVolcano
func function create -> HttpTrigger -> UpdateVolcano

We can now open this in VS Code start adding the appropriate code. First of all, we need to add the appropriate NuGet packages. Open the *.csproj file in your Function App folder and add the following package references:

<PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="6.6.0" />
<PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="6.6.0" />
<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.0.0" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.CosmosDB" Version="3.0.7" />

Pressing save will trigger VS Code to prompt you if you want to restore the newly added NuGet packages - go ahead and do this. Next, we need to add some extra configuration settings, namely the Azure AD details and the Cosmos DB Connection string. Open your local.settings.json file and add the following information

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet",
        "CosmosDBConnection": "<Your Azure CosmosDB connection string in full>"
    },
    "AzureAd": {
        "Instance": "<yourAADInstanceName>.onmicrosoft.com",
        "TenantId": "b55f0c51-61a7-0000-84df-33569b247796",
        "ClientId": "69516c95-a7cc-0000-a62f-66aa336ef62a"
    }
}

Our Functions need to perform the token validation and also check for the appropriate claims (in the form of scopes and user roles). To do this, we will add class named  TokenValidator that contains the following code:

There are 3 methods here:

• GetJwtFromHeader()
• ValidateTokenAsync()
• HasRightRolesAndScope()

The first one grabs the JWT token from the header. The second one uses Open ID Connect to validate the token against Azure AD and the final one checks that the ClaimsPrincipal has the right roles and scope. Different user will likely have different roles, as in our case we have a read-only and a read-write role. We also check for scopes because different client apps may have different scopes which would also dictate a different behavior in the API. In our case we only have one scope but there is nothing stopping you adding more to your API and doing the appropriate checks in the code.

GetVolcano - Function

For this Function, we will use the Cosmos DB Function bindings to connect seamlessly with our database. There is also a little bit of code to grab the config settings from the local.settings.json file. The full function code is provided below:

From an authentication and authorization perspective, the Function allows anyone with the Data.Read and Data.ReadWrite roles to be able to execute the code. It also expects that the user has provided the expected scope, i.e access_as_user.

GetAllVolcanoes - Function

For this function we will again use the Cosmos DB Function bindings and the code is more or less the same apart from the fact that we return all the records instead of selecting just one. The roles and scopes allowed are also the same as before. The full code is shown below:

UpdateVolcano - Function

This function is slightly different. Firstly, we use an output Cosmos DB binding to execute the Update/Insert into Cosmos DB. Secondly, this API endpoint is restricted to users that have the Data.ReadWrite role. Read-only users will receive an HTTP 401 error if they attempt to execute this code. The code is again below:

Volcano - DTO

Finally, we need a class that describes our volcano object and can be used to serialize and deserialize data. The volcano.cs class is attached below:

Putting it all together

As I mentioned earlier, I will be using Postman to test the API so off with it :) In Postman, I created a new request and I went straight into the Authorization bit as this is the most important step

When we press the Get New Access Token button, we are presented with a new window where we need to enter the details from our Client app registration (not the FunctionAPI app - that's use by our Functions, remember?).

Of particular importance are the Callback URL which needs to match what we put in the client app Redirect URI in AAD and the Scope which should be API Permission we configure in the client app API Permissions tab. If you're wonder where to find the auth and token endpoints, head back to your Azure AD -> App Registrations tab and look at the Overview:

If all is configured correctly, upon pressing the Request Token button you should be prompted by AAD to login in with your tenant's account details and in return you should receive a token. We can inspect the token on jwt.ms where we should see something similar to this:

You should notice how the roles, scope(scp) and audience(aud) all contain the information we need for our token to be validated by our API. I can now execute my HTTP request and receive some data:

And although this succeeds (as expected), check what happens when I use the same token to call the UpdateVolcano() method - 401 Unauthorized:

As you can see, following the steps in this blog we were able configure AAD, create a Cosmos DB database and implement an Azure AD secured API using .NET Core 3.1 in Azure Functions that performs CRU(D) operations against our data. You can find the full source code in this Github repo. All you need to do is slap a local.settings.json file with your settings (as shown earlier) and you're ready to go!

Watch me and JP aka @AzureAndChill build this solution live during our first stream on Mixer/Twitch

If you haven't used the Microsoft.Identity.Web NuGet package yet,  then I would urge you to have a look at the repo and start integrating it with your ASP.NET Core apps. The team designed this library to makes working with authentication a lot more straightforward by hiding a lot of the complexities.

I'll admit it  - this is a big one... there are a few moving components and requires a bit of a setup but we will break it down to individual components to make it more "digestible". At a high level, this is what we need to do:

1. Create 2 app registrations in Azure Active Directory
      a) one for the client app (i.e the Power App)
      b) one for the API
2. Write a .NET Core API that
   2.1 accepts authenticated requests from clients (i.e. the Power App in this     case)
      2.2 makes calls to MS Graph to retrieve data
3. Create a Power App that calls our API to get the data

So let's get started!

1. Create the Graph Service API app registration in Azure AD

Navigate to Azure AD in App Registrations to register a new application for our ASP.NET Core Web API. The API will act as our middleware (think of it as air traffic controller) that provides access to MS Graph data.

Side note: we could have made our lives easier by calling MS Graph directly from PowerApps, as this is built-in functionality, but
a) I wanted to prove that this is possible via a custom API
b) In the future we will be adding role-based access so the PowerApp will have different access rights based on who's using it :)

Back in the Azure portal > Azure AD resource > App Registrations, let's register a new app. Give it a meaningful Name, select the Single Tenant option and press Register. We will be coming back to configure the Redirect URI later (once we have our .NET Core API set up) but for now we can ignore this.

Next, we need to configure the appropriate Graph API permissions as this is the application that will be requesting the Graph data. Go to the API Permissions blade and click on the Add Permission button and select Microsoft Graph

Search for User.Read to jump into the User API and select the following 3 permissions and press the Add Permissions button at the bottom of the page:

• User.Read
• User.ReadAll
• User.ReadWrite

The next step is important. As you can see, One of the permissions requires Admin Consent. Since this app registration is for an API and there is no user interaction, i.e the users can't consent to permissions, we need to Grant admin consent so that the API can access the necessary data.

Up to this point, we configured an app that can access the MS Graph data. Next, we need to expose our API so that authenticated client apps can access it. To do this, navigate to the Expose an API blade and hit the Add a scope button. In the new tab that opens, provide the appropriate information as per the image below:

The most important bit is the access_as_user scope name. At the end, press the Add Scope button at the bottom of the page. Finally, what we need to do is configure a client secret to allow the API to authenticate against Azure AD. Navigate to the Certificates & Secrets blade and add a new client secret.

Make sure to copy the value somewhere (temporary and securely) as we will need to add it to our .NET Core Web API configuration. This concludes our Service API app registration. To recap:

• We created a new app registration
• We configured the API Permissions
• We exposed the API and created a scope
• We created a client secret to use in our .NET Core API code

2. Create the Graph Client API app registration in Azure AD

Next, we need to create an app registration for the client app. The app registration will be used by any app (in this case our Power App) to call into Azure AD to get an access token with the right permission and so that it can then pass it to our API.

In the Azure Portal > Azure AD > App Registrations, create a new registration:

One important configuration setting here the Redirect URI. Because we are using PowerApps, the Redirect URI needs to be set to:https://global.consent.azure-apim.net/redirect. Normally, this would be the Redirect URI autogenerated by your Power App Connector. However:

This is currently a temporary workaround as the PowerApps connector that uses Azure AD with OAuth2 is failing to autogenerate the redirect URI which we would otherwise be configuring here. This is currently being looked at so by the time you do it you should use the standard procedure.

Also note that you can configure multiple Redirect URIs later. This means that you can have one for your local dev environment i.e. https://localhost:<port>, one for Postman or whichever tool you like to use and one for your test/QA environment.

Next, we need to configure a Client Secret. use the steps from the previous app registration instructions for this. On the Authentication blade, make sure that both Access Tokens and ID Tokens are selected:

The final step is to define the appropriate permissions for our client app. Navigate to the API Permissions blade and hit the Add a permission button. Go to the My APIs selection and find the app we registered in the previous step

We now have all we need for our client app to authenticate users and return the appropriate access tokens so that users can hit our API and retrieve the Graph data. In this section:

• We created a client app to authenticate users
• We created a client secret
• We added the appropriate Redirect URI(s)
• We configure the appropriate permissions to speak to our exposed API

3. Create a protected .NET Core API to pull data from MS Graph

Time to write some code :) This bit will be fun to write as .NET Core and the new Microsoft.Identity.Web have greatly improved the overall experience when it comes to validating tokens and talking to the Graph API.

Open up Visual Studio and create a new, blank .NET Core Web API. Next we need to add 3 NuGet packages:

• Microsoft.Identity.Web (v 0.1.2-preview)
• Microsoft.Graph (v 3.5)
• Swashbuckle.AspNetCore (v 5.4.1)

With the solution created, we can now go back to our API app registration (the one we created in step 1) and configure the Redirect URL with our API URL (most likely https://localhost:5001 if you're running on Kestrel.

To configure authentication, we start with the appsettings.json file. At the top of the file, add the following json:

"AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "<The app ID from the API app registration - step 1",
    "ClientSecret": "<your client secret>",
    "Domain": "<your domain e.g cmatskas.onmicrosoft.com>",
    "TenantId": "<your Azure AD tenant ID>"
  },

Next, we need to wire up the authentication in our Startup.cs. Open the file and add the following code in the ConfigureServices() method:

services.AddProtectedWebApi(Configuration)
        .AddProtectedWebApiCallsProtectedWebApi(Configuration)
        .AddInMemoryTokenCaches();

In the Configure() method, remember to add the following:

app.UseAuthentication();

As you can see, with less than 4 lines of code, we've instructed our API to authenticate incoming requests and check for valid tokens AddProtectedWebApi, wire up the call to another API, i.e the GraphAPI with .AddProtectedWebApiCallsProtectedWebApi(Configuration) and configure a token cache, albeit only an in memory one in this instance.

Next we need to create an Auth provider that we can pass to the GraphServiceClient. This helper class or service, will be later injected to our controller to retrieve and return the Graph data.

This class grabs the access token for the user from the incoming request and exposes a DelegateAuthentiationProvider.

Let's go back to our Startup.cs and register this as a scoped service so that we can later inject it to our controller(s). In the ConfigureServices() method, add the following line:

services.AddScoped<GraphClientAuthProvider>();

Notice that although I would have liked for the GraphClientAuthProvider to be registered as a singleton, since this services relies on the ITokenAcquisition service which is also scoped, we need to match on the scope.

We also need to create an additional class that will provide an instance of GraphServiceClient. Add the following code to the new class:

We also need to ensure that we register this as a scoped service as it depends on the GraphClientAuthProvider. In the ConfigureServices() method, in startup.cs add the following line:

services.AddScoped<GraphClient>();

Next, we can build our GraphController.cs. We are going to expose two methods:

• Get() => an HTTP GET method that returns all users in the directory
• Get(upn) => an HTTP GET method that returns a single user or me depending on the request parameters passed

Also notice how we enforce that all requests should be authenticated using the [Authorize] attribute on the controller declaration.  

NOTE: if you attempt to return raw Graph objects then you will get a serialization exception as the Graph SDK hasn't been ported to work with System.Text.Json (the default json serializer in .NET Core 3.1). You can work around it by using DTOs or configure your controller to work with Newtonsoft.Json by registering the serializer in your Startup.cs as per: services.AddControllers().AddNewtonsoftJson();

Finally, we need to wire up the Swashbuckle functionality to get the OpenAPI/swagger tools to expose the API to external consumers, including our Power App! Let's go back in our Startup.cs class and add the following code in the ConfigureServices() method:

services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "Graph Service API", Version = "v1" });
});

In the Configure() method, add the following code:

app.UseSwagger();
app.UseSwaggerUI(c =>{c.SwaggerEndpoint("/swagger/v1/swagger.json", "Graph Service API");});

This wraps the necessary steps to create an AAD protected API that calls into MS Graph. To summarize once again:

• We added 3 NuGet packages
• We configured the appsetting.json file with the AD app details
• We updated the Startup.cs class to wire up the authentication, DI and OpenAPI
• We created an Auth provider for our GraphServiceClient
• We created a protected API that calls into MS Graph and returns user data

4. Test the .NET Core API

Firstly, we can spin up the API in Visual Studio and navigate to https://localhost:<portnumber>/swagger to ensure that the Open API UI and json can be accessed. This is what you should see:

This is great but so far I haven't tested the API authentication and token validation at all. To do this, I decided to use Ngrok (free service) and Postman (free tool). Ngrok allow me to spin up a proxy that exposed my localhost to the world and Postman is great for easily acquiring OAuth tokens and sending requests. If you haven't used NGrok before, register and download the tool. Unzip the executable and put it somewhere that makes sense. I went with Program Files\ngrok. I also added this directory to my PATH env variables so I can easily access ngrok from any shell. Now all we have to do to expose our API to the world is to start our API and then fire up your favorite shell and type:
ngrok http https://localhost:<yourport>

I can now access my API from anywhere by navigating to https://5ab05a0e.ngrok.io! How awesome is this?

Let's fire up Postman and run some requests. Create a new request and set it to a GET with the following URL http://53b2317c.ngrok.io/api/graph.

We now need to acquire an access token. Change to the Authentication tab and select OAuth2 from the dropdown list:

We are now ready to request an access token. Click on the Get New Access Token button and fill in the appropriate fields using the details from your Client App registration we setup on step 2 with some gotchas I'll cover below

First of all, you'll notice that the Callback URL is configured for Postman so you'll need to make sure that this URL is configure in your App Registration > Authentication as one of the Redirect URLs

Secondly, you'll need to know your Auth URL and Access Token URLs. You can locate these in the Azure AD>App Registrations blade under Endpoints.

Finally, and this is the important bit, notice the Scope. Our client app needs to explicitly ask for this scope with all API requests. This will then be swapped by the API and the appropriate Graph scopes will be applied. We can now execute the request with the newly acquired token :)

We have now tested our API and have confirmed that we can use the Client app details registered in Azure AD to acquire a token that we can then pass to the API to ask for Graph data! Next step: PowerApps FTW!

5. Create a Power App that consumes a custom API

PowerApps allows pro and citizen developers to create data driven solutions quickly and efficiently using built-in, predefined components, layouts and connectors. The platform comes with a plethora of services you can pull data from such as SQL, ServiceNow, SharePoint etc etc. But where I see the great potential is bringing the two worlds together (pro + citizen devs) to achieve even more. With custom connectors and a lot more on the way, I can now leverage datasets and custom APIs in my PowerApps in seconds. And with the deep integration of Azure AD I can have a secure solution built on top of my existing implementation.

For our example, I'm going to create a Power App that connects securely to my protected API, built with .NET Core 3.1 and pull MS Graph data. So let's get started:

Navigate to make.powerapps.com, go to under Data>Custom Connector and select the New Custom Connector>Import and OpenAPI file

Grab the json file from you OpenAPI endpoint (like we tested at step 4) and upload it here:

In General, you only need to provide the Host details. In our case, this is the ngrok URL as per below:

In the Security tab, we need to configure our connection.

• Authentication Type: OAuth2
• Identity Provider: Azure Active Directory
• Resource URL: the API URI (you can get this from the Expose API blade of the API app registration in the Azure AD portal)
• Scope: the API URI + /.default (e.g api://c369fdb7-d70b-4651-9e5c-4379c3863d78/.default

In the Definition tab, we need to do a little bit of work to configure the Response to allow our Power App to easily wire controls to the API data. To do this, grab a copy of the json output from the Get() method of our GraphController and click in the Response box to configure the expected response object

On the new tab, press the Import from Sample button:

As a last step, we need to create a new connection. Press the Update Connector at the top to save the current configuration and proceed to test the available API operations. This will ensure that our connector is working as expected. The first time you create a connection, you'll be prompted to login to your AD your tenant.

We can now create our UI. Navigate to the + Create tab and use the app template that you like the most. I chose a Canvas app from blank and I dropped a Vertical Gallery to host my Graph data. Select the whole control and configure the Data Source: Items = GraphServiceAPI.GetAllUsers().

If everything worked as expected, you should be able to see your data in the dropdown! So far so good :). We now need to configure the individual controls to the Graph data. You can click on each label and either configure the value at the top bar using the: ThisItem.<property> or you can use the Properties tab on the right and configure the same value in the Text property as per below:

Choose the same for the second label and we now have a vertical list of all the organization users displayed on my Power App in a few steps.

By leveraging Azure AD and, Microsoft.Identity.Web and Graph SDKs, I was able to create a protected API that provides secured and controlled access to MS Graph. You can find the .NET Core API solution on GitHub ready to build and run.

Special thanks to JP and David Fowler for their guidance and help to shape the code. And thanks to Greg Hurlman for helping with the Power Apps implementation - I'm such a n00b :)

Coming next: Role-based authorization in WebAPI. We will see how we can use Azure AD role to implement authorization to the API resources so when different users work with our PowerApp, they get different access rights.