DEV Community: John Patrick Dandison

DarkSky to WeatherKit: from API keys to signed JWTs

John Patrick Dandison — Thu, 20 Apr 2023 23:25:02 +0000

As of March 31st, the Dark Sky API is no more, replaced by Apple's WeatherKit. I've used the Dark Sky API as it had a generous free-tier, was easy to use and flexible enough to customize.

Remember a few years ago when customized terminal prompts were all the rage? Pepperidge Farm remembers - especially people like me who probably went a bit overboard.

Note the weather & stock price. Stock price comes from Yahoo (and follows the same pattern as the weather data), weather data came from Dark Sky. The prompt would read from a cache file.

weatherData=$(curl -s "https://api.darksky.net/forecast/${API_KEY}/${LATLON}?exclude=minutely,hourly,daily,alerts,flags")
echo $weatherData > $weatherCacheFile

API key was a static string - could be regenerated on-demand. To run on a trusted machine (like my own), it was no sweat and easy to use. Of course I wouldn't want to distribute that key, but it was for my use locally. It was especially easy to use in shell scripting.

Enter WeatherKit

Apple pushed the Dark Sky cutoff date a few times, of course, I missed it and wondered why I was getting 301s and parse error for weather info. On March 31st, the API was dead and I'd have to migrate over to WeatherKit.

At first glance I figured it'd be pretty similar - this is weather data, after all - but was surprised to see that Apple's only accepted authorization scheme for the API was a bearer token, an EC-signed, asymmetric JWT! Needless to say I was surprised

Here's an example:

{
  "kid": "<KEY ID>",
  "id": "<TEAM ID>.<SERVICE ID>",
  "typ": "JWT",
  "alg": "ES256"
},
{
  "iss": "<TEAM ID>",
  "iat": 1682008228,
  "exp": 1682011828,
  "sub": "<SERVICE ID>"
}.<signature>

Get all of your pieces

Sadly, this is not free - unlike the Dark Sky API, this requires an Apple Dev membership. While the WeatherKit API itself has a generous starting tier (500k calls/month) that doesn't have any additional cost, you'll still be out the $99 for the annual membership. Students and non-profits can get it cheaper, so ask around.

Apple's docs cover most of what you'll need:

your Team ID
the .p8 file that contains your key
the key ID
the service ID
lat/lon coordinates of a location

The Service ID is a string (like dev.jpda.terminal-weather) of your choosing.

Testing with Postman's excellent JWT signer

To start, Postman has an excellent JWT Bearer auth type that includes an ES256 signer, which makes it much easier to get familiar with the API. I find creating a collection to make this easier (as the authorization settings can be set at the collection level instead of per-request). Here we can configure our token. Choose JWT Bearer as the type, ES256 as the algorithm, get your private key from the .p8 file from Apple.

JWT Payload

The payload is where we'll add our specific claims - there are four we need: iss,iat (issued at), exp (expires on) and subject (who/what the token is about).

iss: your team ID
sub: your service ID

The two timestamps we'll have to sort out. Postman has a $timestamp global that gives us a unix epoch time (seconds since 1/1/1970) making iat easy. exp we'll need calculate off of iat, which we can do via Pre-request scripts.

I've left my information in below as an example:

{
    "iss":"6RT85M24SE",
    "iat": {{$timestamp}},
    "exp": {{exp_timestamp}},
    "sub":"dev.jpda.terminal-weather"
}

Pay particular attention to the timestamps - they should not be in quotations, as they are longs. This will complain because exp_timestamp is not defined, which is OK, we're going to go define it next.

Variables & pre-request script

We'll need at least one variable to hold the calculated expiration value. I put my coordinates in variables called HOME_LAT and HOME_LON since they will be available to the whole collection.

Add a variable called exp_timestamp - it doesn't need an initial value.

Lastly head into your pre-request scripts tab. Here we can calculate the expiration timestamp like so:

var now = pm.variables.replaceIn("{{$timestamp}}")*1;
var exp = now + 3600; // adds +1 hour
pm.collectionVariables.set("exp_timestamp", exp);

Because of how Postman's variables work, replaceIn is required to use the global $timestamp variable.

JWT Header

Back in the Authorization tab, we have one more item to manage - we need to add two fields to the JWT's header - the kid (key ID) and id - the team ID + service ID of your app. This is under 'advanced configuration.' We can add our claims and postman will handle adding claims like alg for the algorithm and type.

I've left my values in as an example:

{
    "kid":"PMV7JU5DJJ",
    "id":"6RT85M24SE.dev.jpda.terminal-weather"
}

Ready! Let's get the weather...! Right?

OK, at long last we are ready to get the temperature! Well, not quite. First we need to see what datasets are available for your location.

Get a new request (making sure to save it/add it to your collection we just configured for authorization) and drop in this url:

https://weatherkit.apple.com/api/v1/availability/{{HOME_LAT}}/{{HOME_LON}}?country=US

Make sure your authorization tab is configured for 'inherit from parent' and you have variables set for {{HOME_LAT}} and {{HOME_LON}} and update your country if necessary. Run this and, if all went well, we should get a response with an array of the available datasets for that location.

[
    "currentWeather",
    "forecastDaily",
    "forecastHourly",
    "forecastNextHour",
    "weatherAlerts"
]

If you get an error, take the generated JWT (from the headers tab of the request) and drop it in your favorite JWT decoder (like jwt.io) and check the contents.

Note that these may be out-of-date, to get the specific token used in the failed request, look in the Postman console (View --> Show Console).

Ok so NOW we can get the weather?

At long last, now that we know what's available, currentWeather should give us what we're looking for. Create a new request in Postman in this collection and let's apply what we've determined:

https://weatherkit.apple.com/api/v1/weather/en/{{HOME_LAT}}/{{HOME_LON}}?dataSets=currentWeather&country=US

Note the /en/ in the path - use the ISO country code for your region. I am only interested in current weather, so that's the dataset I'll request.

{
    "currentWeather": {
        "name": "CurrentWeather",
        "metadata": {
            "attributionURL": "https://weatherkit.apple.com/legal-attribution.html",
            "expireTime": "2023-04-20T21:20:01Z",
            "latitude": 42.860,
            "longitude": -82.590,
            "readTime": "2023-04-20T21:15:01Z",
            "reportedTime": "2023-04-20T20:02:16Z",
            "units": "m",
            "version": 1
        },
        "asOf": "2023-04-20T21:15:01Z",
        "cloudCover": 0.65,
        "cloudCoverLowAltPct": 0.03,
        "cloudCoverMidAltPct": 0.66,
        "cloudCoverHighAltPct": 0.34,
        "conditionCode": "MostlyCloudy",
        "daylight": true,
        "humidity": 0.55,
        "precipitationIntensity": 0.0,
        "pressure": 1013.66,
        "pressureTrend": "falling",
        "temperature": 18.98,
        "temperatureApparent": 18.33,
        "temperatureDewPoint": 9.65,
        "uvIndex": 2,
        "visibility": 30544.32,
        "windDirection": 147,
        "windGust": 28.80,
        "windSpeed": 16.96
    }
}

Success! It's all in metric units, and the docs seem to indicate that's what it is and you'll like it. So a bit of work to convert from Cs to Fs (or Ks if you're adventurous).

Now what?

Now that we can at least get the data again, how are we going to leverage it? Remember I was using this in my terminal - using curl to go fetch the data with an environment variable with the API key. What's best here?

Whatever we use is going to need to access the private key - meaning whatever is generating those JWTs will need to be trusted - local, remote, etc.

Local executable

This is pretty straightforward, could easily balance JWT lifetime with overhead. Perhaps once-per-day with a 24-hour JWT? I wouldn't normally advocate for long-lived tokens but as it's locally generated, and it's relatively low-risk data, it seems like a decent tradeoff.

Remote

Something remote sounds neat too - like a Lambda or Azure Function - but once we leave our trusted space, we'll have to figure out how only the correct clients can get tokens to call the weather service. Something like AAD, Okta, Auth0, etc to secure the API to get JWTs. Which, at that point, maybe is easier to just let the function/etc get the weather data itself and cache it, further reducing the number of paid API calls to WeatherKit. Something like:

Client --> (secured via cloud auth service) http proxy API (keeps Apple private key + generates JWTs) --> WeatherKit

This is, in fact, a lot like the BFF pattern (backends for frontends) used for things like storing secrets securely, caching API responses, etc.

Remote has tradeoffs, of course, like hosting, downtime, etc. And it's one more thing to break :D

Next, we'll pick!

Join me on Twitch and we'll decide what's next!

425show @ Build 2021

John Patrick Dandison — Tue, 25 May 2021 21:35:06 +0000

Thanks for joining us at Build! We'll be updating this post throughout the week with code samples, docs and other info after our sessions.

Learn Live: Application types in Microsoft Identity (5/25, 3p ET)

This session kicks off a 5-week series every Monday through June, where Christos & I will take you through the Implement Microsoft identity - Associate learning path. Join us each Monday from June 7th - July 12th as we'll go into the why behind the how.

Find the code samples from this session, complete with CodeTour!

Stay tuned, more to come throughout the week! Join us on discord

Quick hits: Azure AD B2C with the MSAL v2 Angular alpha

John Patrick Dandison — Tue, 01 Dec 2020 18:02:02 +0000

We get a lot of interesting questions over here at 425 HQ. Today I have a friend working with a customer doing angular - they're interested in using the msal-angular v2 alpha to use auth_code with PKCE instead of implicit. There is a sample app here, although that app is for regular Azure AD, not b2c. While the library usage is largely the same between AAD and B2C, the configuration is not.

To use the alpha with the sample app with b2c, make sure to add an authority that includes your b2c policy/user flow ID, in addition to adding that in the knownAuthorities block. For example, in app.module.ts:

function MSALInstanceFactory(): IPublicClientApplication {
  return new PublicClientApplication({
    auth: {
      clientId: 'your-app-id-guid',
      redirectUri: 'http://localhost:4200',
      authority: 'https://your-b2c-tenant.b2clogin.com/your-b2c-tenant.onmicrosoft.com/B2C_1_your_user_flow'
      knownAuthorities: [
        'https://your-b2c-tenant.b2clogin.com/your-b2c-tenant.onmicrosoft.com/B2C_1_your_user_flow',
        'https://your-b2c-tenant.b2clogin.com/your-b2c-tenant.onmicrosoft.com/B2C_1_another_flow'
      ]
    }
  });
}

You may also need to add a dummy scope to your app registration - earlier versions of msal-browser expected an access_token but one was not provided by default with b2c if there were no scopes outside of openid.

Just what is the /.default scope in the Microsoft identity platform & Azure AD?

John Patrick Dandison — Wed, 30 Sep 2020 15:56:10 +0000

We talked about this in our last community hours. Check out the video above!

If you’ve ever worked with the Microsoft identity platform (aka Azure AD, aka Azure AD B2C), there is a good chance that you have had to work with scopes, including the /.default scope. In this blog post, we’re going to cover some of the basics and explain what the /.default scope is, when to use it and why.

Quick background

When we need to connect to APIs or services secured with OAuth2 (called resources in openid and oauth parlance), such as the Microsoft Graph API, Azure APIs, third-party APIs or our own APIs, we need to request an access token for that resource. For Microsoft services, the vast majority are secured with Azure AD, meaning you'll need to get tokens from Azure AD in order to use those services from your applications.

Sometimes OAuth2 is referred to as 'Bearer Authentication' - this is due to how we use the token with a resource: it's put into the Authorization HTTP header with a value of Bearer <access_token value>

When users sign-in to your app, Azure AD sends you back an id_token, which proves their identity to your application – but when your application also needs to connect to a resource, we need an access token specifically for that resource. In short, the id_tokenis for your application to use, while the access_token is for you to send to other resources (APIs) your app is using.

Scopes & permissions

Scopes can be thought of as permissions within a resource – for example, Microsoft Graph exposes Office 365 scopes like Mail.Read (read the user’s mail) or Files.Read (read the user’s OneDrive files). In this case, the resource is https://graph.microsoft.com while the permission is Mail.Read. Putting these together gives us our full scope: https://graph.microsoft.com/Mail.Read.

Once we know our scope, we need to ask the user if it's ok to use that scope. This is called consent. If the user consents to https://graph.microsoft.com/Mail.Read, our application will get an access token it can use to read a user’s mailbox.

You can think of it like permissions on your phone – when you install a new app, most smartphones will say "This app would like to use your location. Is that OK?"

What makes scopes so useful in building user trust is that our users can allow other apps to access their data without having to give those other apps full access to everything. In my phone example, if I grant app ABC access to my location, that’s all the app receives – it can’t also read my contacts, for example, unless the app asks and the user allows that to happen.

Let's order some business cards!

Imagine we’ve built an app that handles ordering business cards.  

It would be really helpful to pre-populate the user’s info in the card, so we request the User.Read permission from Microsoft Graph. This includes profile information like their display name, email address, etc.  

If you're keeping score at home, that means we'll need this scope: https://graph.microsoft.com/User.Read

But we also want to give them an option to save their design, or upload a custom design. We implement a normal file picker so a user can upload from their PC, but wouldn’t it be cool to offer upload and download from OneDrive or a SharePoint site? To do that, we will need the Files.ReadWrite and Sites.ReadWrite.All permissions. 

Now our scope list is:

https://graph.microsoft.com/User.Read

https://graph.microsoft.com/Files.ReadWrite

https://graph.microsoft.com/Sites.ReadWrite.All

Remember, however - not all users will want to do this. Some users won't have a OneDrive or Sharepoint site, other users may have all of their files locally.

Sample of users actually using these permissions:

https://graph.microsoft.com/User.Read: this is for signing into the app - 100% of users will use this

https://graph.microsoft.com/Files.ReadWrite: this is for accessing OneDrive - say, 40% of users will do this

https://graph.microsoft.com/Sites.ReadWrite.All: this is for accessing a SharePoint site - we'll estimate 10% of users want to do this

In Azure AD v1 (which you may also hear being referred to as ‘the v1 endpoint’), we had to add all the permissions we needed upfront - configured on the App Registration in Azure AD. This meant users would also need to allow those permissions upfront, just to sign-in to our app. This is called ‘static consent’. Let's see what that looks like:

Developer/admin view

Meanwhile, this is what your users will see when signing into the app:

What your users will see

Whoa! That's a lot of permissions. I just wanted to order some business cards, but now I'm being asked to let this app I've never used write to my files? Access sharepoint sites? No way, I'm outta here - I'll go order business cards somewhere else.

Not today

If the user does allow those permissions, it means your application is going to have permission to read a user’s files, even if you never need to read their files! Not particularly optimal for our app or our users.

Dynamic consent

The Azure AD v2 (aka Microsoft identity platform, aka ‘the v2 endpoint’) scope & permission system fixes this, by allowing dynamic consent – instead of requiring the developers to declare all permissions upfront, v2 allows developers to ask at any time. In our business card example, this means a user is only asked to consent to their profile data being read on sign-in, while users who elect to 'upload a custom design from OneDrive' (by clicking a button in your app, etc) will be prompted for the Files.Read permission when they perform the action. Better for our users, better for us as the developer 😊

Much better

/.default 

Now that we’ve written two pages of what got us here, let’s get to the point of this post – the /.default scope. The short description is the /.default scope is a shortcut back to the Azure AD v1 behavior (e.g., static consent). When we request a /.default scope (for example, https: //graph.microsoft.com/.default), our users will be asked to consent to all of the configured permissions present on our Azure AD App Registration for that specific resource (e.g., https: //graph.microsoft.com).

In our business card example, this means that a user would be prompted to consent to all permissions we’ve configured upfront.

For migrating old apps that currently use Azure AD v1 (including apps that use ADAL, the Active Directory Authentication Library), the /.default scope offers an easier migration path, as the developer gets the same behavior from the v2 endpoint keeping the experience consistent.

When must I use the /.default scope?

There are two extra scenarios where the /.default scope is required: 

client_credentials, where our app is making service-to-service calls or using application-only permissions (also known as application app roles in Azure AD parlance), or
when using the on-behalf-of (OBO) flow, where our API is making calls on behalf of the user to a different API; something like this: client app --> our API --> Graph API.

In both scenarios above, there is no user interface and no user interaction. In the client_credentials case, an application is using its own identity (not that of a user), so there is no concept of dynamic consent, as the application must statically configure the permissions that it needs - who would it ask for extra permission at runtime if there is no user present?

on-behalf-of (OBO) is similar; since the backend API is making a request to another API, there is no user interface for asking for additional permissions, so permissions must be set statically between APIs. This means that your scopes in token requests for service-to-service and on-behalf-of flows must use a scope of your-app-id-uri/.default – e.g., https: //graph.microsoft.com/.default, or https: //your-app.your-co.com/.default. 

You can read up more on the official doc about /.default, scopes & consent here: Microsoft identity platform scopes, permissions, and consent.

Check us out live Tuesdays & Thursdays at 10a ET, 7a PT at https://aka.ms/425show!

Connecting to Azure blob storage from React using Azure.Identity!

John Patrick Dandison — Wed, 05 Aug 2020 21:06:43 +0000

take me straight to the code!

On stream, after our great talk with Simon Brown, we decided to dig into building a fully client-side app that connects to Azure Blob Storage.

What is blob storage?

Just that - storage for blobs of data, big and small. Historically it stood for 'Binary Large OBjects' although that was mostly used in SQL circles for storing data in databases. Regardless of the origin, blob storage (aka S3 at AWS) is a staple of modern apps.

Azure Blob storage has some unique features that make designing apps even easier. For example - a standard storage account has a maximum egress of up to 50 Gb/s! - that's 50 Gb/s that your app server/platform doesn't have to handle on its own.

This works for upload too - standard storage in the US has a max ingress of 10Gb/s. Clients uploading or downloading directory to and from storage accounts can have a massive impact on your app's design, cost and scalability.

We've seen customers leverage this over the years - for example, streaming large media assets (think videos, pictures, datasets) from blob storage directly to clients instead of proxying through your app server.

Take this scenario - I want to share videos and pictures with people I work with, or with the internet as a whole. Previously, I would have had some storage - a network share, NAS device - and my app server would have some sort of API exposed to access that data. My app would have to send and receive data from clients, which meant my app servers would need enough bandwidth for pushing and pulling all that data around.

By using storage directly, my servers and APIs can direct clients to upload and download directly from storage, significantly reducing compute bandwidth requirements, with the benefit of a worldwide footprint of storage locations.

But how do we ensure secure access?

Historically, we used shared access signatures (SAS) tokens with storage, which are time- and operation-limited URLs with a signature for validation. For example - I'd like Read access to https://storageaccount.blob.core.windows.net/container/blob1.mp4 for the next 60 seconds - this would generate a URL with some parameters, which was then signed with the master storage account key, then the signature was tacked onto the end of the URL. Then we share that URL with whatever client needed to do the operations.

This was cool, except it meant we needed some server-side API or web server to store and manage the master account key, since can't send it directly to the client.

Enter Azure AD & Storage Blob Data RBAC

If you're familiar with Azure, you know there are two distinct 'planes' - the control plane (the management interface) and the data plane (the actual resource data). I like to think of it as the difference between being able to deploy a VM vs actually having credentials to RDP or SSH into it.

If you've seen this screen before, you've used Azure RBAC

All Azure resources have some degree of control plane role-based-access-control - things like 'Resource group owner' or 'resource group reader' - that allow management operations on those resources. Over time more and more data plane operations have been added, so we can use Azure RBAC for controlling both who can manage the resource as well as who has access to the resource or data itself. The advantage here is furthering the 'least privilege' mantra - a storage key is the key to the proverbial castle, so to speak, so if we can limit operations on an ongoing basis, we can limit the blast radius of any bad actors.

Storage has roles specifically for connecting to the account's data plane - connecting to blobs specifically, for example. In the IAM/role assignments blade for the storage account, note the 'Storage Blob Data...' roles. These give Azure AD accounts (users and service principals) access to the blobs directly.

The different storage-related roles

We're going to use this to build our client-side blob reader app.

Bill of Materials

We're going to:

deploy a storage account to Azure
add a user to the Storage Blob Data Reader role
Register an app in Azure AD to represent our React app
Create a quick-and-dirty React app
Add Azure Identity dependencies
Authenticate the user and list out our blobs

Setting up our blob storage account

Want to use CLI but don't have it setup yet? Try Azure Cloud Shell straight from your browser, or read here on getting it installed for your platform

CLI for a standard, LRS, v2 storage account:



az storage account create --name somednssafename --resource-group some-resource-group-name --kind StorageV2 --sku Standard_LRS --location eastus

First, create a blob storage account in Azure. General Purpose v2 is fine for what we're building. I use Locally-redundant storage (LRS) for my account, but pick what's best based on your requirements.

Storage account names are pretty particular

Once it's created (may take a moment or two), we'll go to the IAM blade of your storage account. Here we need to add a role assignment of Storage Blob Data Reader to a user you're going to sign-in with. This could be yourself or a test account. Start by clicking 'Add Role Assignment,' which should open up a side pane. Here we'll choose 'Storage Blob Data Reader,' and the user to whom you're allowing access. Make sure to click Save at the bottom.

Choose Storage Blob Data Reader

Now let's add some test data. We used some images, but you can use whatever files you want. First, under Containers in the side menu, add a new container, making sure to leave it as Private. Public will open that container to the internet with no authentication, so be careful here!

Once you've created your container, click it and you can upload files directly from the web interface. Upload a few files, it doesn't really matter what they are. We used pictures, but you can use whatever's handy.

Great! Now we're finished with our storage account. You can download Storage Explorer for a desktop app to view/upload/download to and from your storage accounts.

On to Azure AD!

Azure AD setup

In Azure AD, we need to register an application. This is essentially telling Azure AD "hey, here's an app, at a specific set of URLs, that needs permissions to do things - either sign-in users, and/or access resources protected by Azure AD."

CLI to register a new app:



az ad app create --reply-urls "http://localhost:3000/" \
--oauth2-allow-implicit-flow "true" \
--display-name msaljs-to-blobs \
--required-resource-access "[{\"resourceAppId\": \"00000003-0000-0000-c000-000000000000\",\"resourceAccess\": [{\"id\": \"e1fe6dd8-ba31-4d61-89e7-88639da4683d\",\"type\": \"Scope\"}]},{\"resourceAppId\": \"e406a681-f3d4-42a8-90b6-c2b029497af1\",\"resourceAccess\": [{\"id\": \"03e0da56-190b-40ad-a80c-ea378c433f7f\",\"type\": \"Scope\"}]}]"

To register a new app in the portal, head over to the Azure Active Directory blade; alternatively, go to the AAD portal - then App Registrations.

We're going to register a new app - give it a name, choose an audience and a platform. For us, we only want users in our directory to login, so we'll stick with single tenant. More on multitenancy in a different post :). Then we need our platform - ours is a client app, so we're going to use that for now.

Yours should look something like this

Now we'll have our app registered! Almost done. We need to go grab a couple of extra pieces of info. Once the app is registered, from the overview blade, grab the Application (Client) Id and tenant ID and stash them off somewhere, like notepad or sticky notes.

If you used the CLI, the appId will be in the returned data from the az ad app create command:

We need to give our app permission to the storage service. We could do this in code when we need it, but we'll do it now since we're already here. Under the API Permissions menu, we're going to add a new one, then choose Azure Storage. There will only be one delegated permission, user_impersonation. Add this, make sure to click Save at the bottom.

Choose Azure Storage

There's only one delegated permission, user_impersonation

If you're using the CLI, you're already done - we added those permissions in the requiredResourceAccess parameter of our command.

CLI or portal, by the end, under the 'API permissions' blade you should see something like this:

Now we can write some code!

We've made it! We're ready to build our app. Let's start with creating a new React app. I'm using create-react-app because I'm not a React pro - use what you're comfortable with.



npx create-react-app msaljs-to-blobs --typescript
cd msaljs-to-blobs

Now we've got our React app, let's add a few dependencies. We're using the Azure.Identity libraries for this as it's what the storage library uses.

We can add these two to our dependencies in package.json and do an npm i to install.



"dependencies: {
"@azure/identity": "1.0.3",
"@azure/storage-blob": "^12.2.0-preview.1"
}

Next we're going to create a new component. I've got a new one called blobView.tsx:



import React from 'react';
// we'll need InteractiveBrowserCredential here to force a user to sign-in through the browser
import { InteractiveBrowserCredential } from "@azure/identity";
// we're using these objects from the storage sdk - there are others for different needs
import { BlobServiceClient, BlobItem } from "@azure/storage-blob";

interface Props {}
interface State {
    // a place to store our blob item metadata after we query them from the service
    blobsWeFound: BlobItem[];
    containerUrl: string;
}

export class BlobView extends React.Component<Props, State> {
    state: State;

    constructor(props: Props, state: State) {
        //super(state);
        super(props, state);
        this.state = { blobsWeFound: [], containerUrl: "" }
    }

    // here's our azure identity config
    async componentDidMount() {
        const signInOptions = {
            // the client id is the application id, from your earlier app registration
            clientId: "01dd2ae0-4a39-43a6-b3e4-742d2bd41822",
            // this is your tenant id - the id of your azure ad tenant. available from your app registration overview
            tenantId: "98a34a88-7940-40e8-af71-913452037f31"
        }

        const blobStorageClient = new BlobServiceClient(
            // this is the blob endpoint of your storage acccount. Available from the portal 
            // they follow this format: <accountname>.blob.core.windows.net for Azure global
            // the endpoints may be slightly different from national clouds like US Gov or Azure China
            "https://<your storage account name>.blob.core.windows.net/",
            new InteractiveBrowserCredential(signInOptions)
        )

        // this uses our container we created earlier - I named mine "private"
        var containerClient = blobStorageClient.getContainerClient("private");
        var localBlobList = [];
        // now let's query our container for some blobs!
        for await (const blob of containerClient.listBlobsFlat()) {
            // and plunk them in a local array...
            localBlobList.push(blob);
        }
        // ...that we push into our state
        this.setState({ blobsWeFound: localBlobList, containerUrl: containerClient.url });
    }

    render() {
        return (
            <div>
                <table>
                    <thead>
                        <tr>
                            <th>blob name</th>
                            <th>blob size</th>
                            <th>download url</th>
                        </tr>
                    </thead>
                    <tbody>{
                        this.state.blobsWeFound.map((x, i) => {
                            return <tr key={i}>
                                <td>{x.name}</td>
                                <td>{x.properties.contentLength}</td>
                                <td>
                                    <img src={this.state.containerUrl + x.name} />
                                </td>
                            </tr>
                        })
                    }
                    </tbody>
                </table>
            </div>
        )
    }
}

And that's it! Our App.tsx just includes a reference to this component. The Azure Identity libraries handle logging you in, asking for consent and putting tokens in the correct headers, absolving the developer from having to worry with token storage.

Run the app and you should see the blobs listed in your storage account.

Stay connected!

We stream live twice a week at twitch.tv/425Show! Join us:

11a - 1p eastern US time Tuesdays
11a - 12n eastern US time Fridays for Community Hour

Be sure to send your questions to us here, on twitter or email: [email protected]">[email protected]!

Until next time,
JPD

Creating a Teams presence publisher with Azure Functions, local and cloud

John Patrick Dandison — Tue, 24 Mar 2020 15:04:11 +0000

Want to go straight to the code? Here it is

Teams Presence

Presence info has been around a long time - we had it in Skype for Business and its predecessors - Lync, OCS, LCS, etc. There were even devices you could buy with lights indicating presence - super useful, especially in more ‘open’ offices to achieve some focus.

The Embrava lights were popular, I had one on my desk, in fact - but they don’t seem to work with Teams presence. Combine that with more recent news:

And since I have little ones at home, it got me thinking about ways to let them know if I’m on the phone or not. I wanted something multitenant that could publish presence for anyone, not just me. In that spirit - any solution worth a solution is worth an over-engineered solution, right? Right?! Click the video to see it in action.

At home I’ve got a few bulbs, in my office but also upstairs so my family can see if I’m on the phone or not.

Same for the office - rather than a small light, I felt the size of this lamp really reinforced the message.

Let’s build!

Here’s what we’re going to build:

A presence-poller running in Azure Functions, which…

logs in a user and stores a refresh_token,
polls the Graph for Presence updates,
stores the update (if any) in Azure Table Storage, and
notifies subscribers over a Service Bus topic.

Plus, we have a local Azure Function, which…

runs in a container on a raspberry pi,
creates a subscription to the Service Bus topic, and
interacts with the local Philips Hue Hub over HTTP

There is no webhook or push support yet for Presence updates, so until then, we need to poll for it ourselves. Rather than having multiple devices poll for the same data, I thought it prudent to poll from one component, then push to as many subscribers as are interested. The local Function acts as a shim for interacting with whatever local devices are interested in presence updates. In my case, two Philips Hue Hubs - one in the office, one at home. This also helps with firewall silliness - since the poller runs cloud side but publishes changes to a topic, our local function only needs outbound internet access - no inbound access required.

Presence updater job

The presence-refresh function calls CheckAndUpdatePresence, which does the bulk of the heavy lifting. This timer job is responsible for actually pinging the Graph to fetch a user’s current presence, check it against the last known presence, and, if different, publish it to subscribers. I’m using the user’s ID as the service bus topic name - this way we have enough information at runtime to know which topic to use for sending updates.

First, we need to know which user for which we want presence data. This is driven by a store of accounts in Table storage. The key here is how the accounts get into the list in the first place - and how we get access tokens for querying the graph.

Authenticating users and asking for consent

Of course, being the Graph, everything here is authenticated via Azure AD. We need the Presence.Read permission, which (as of March 2020) is an admin-consentable permission only. This means that only an administrator of an Azure AD tenant can consent to apps using this permission. There are some reasons we can infer from that - a malicious app that knows your presence could risk far more information exposure than your organization (or you) would be comfortable with. Once we have an app with that consent, we still need to capture individual user consent (you can, of course, consent tenant-wide as an administrator) and record that this user would like to get their presence info published to them.

To configure this, first we need to register an app. The app itself needs Presence.Read but little else. We’ll also need certain reply URLs registered. You can read more about this process here. You’ll get a client ID (application ID) and secret (a random string, or a certificate). Save them off, we’ll need them in a little bit. Note I’m using a certificate here for authentication, since this Presence.Read is a sensitive scope. We also need a way to securely share that secret (be it a string or a certificate) with our Function.

We’ll use KeyVault and Managed Identity for accessing the secret. This way, our Function will have an identity usable only by itself - we’ll assign this identity permissions in KeyVault to pull the secrets, so we don’t keep any secrets in code. Alternatively, you can assign the Presence.Read permission directly to your Managed Identity, removing the need for KeyVault entirely. Read on here for more info on using KeyVault with Managed Identities.

Alternatively, if using certificate authentication to Azure AD, you can store the certificate in App Service directly, then reference it using normal Windows certificate store semantics (e.g., CurrentUser/My, etc). In fact, I had to switch to this for testing, as I was having issues getting connected to KeyVault reliably.

Next, let’s get into the auth-start and auth-end functions, which actually authenticate our users.

`auth-start`

This function is responsible for two things - authenticating a user to capture access_ and refresh_tokens, in addition to storing the user in the PresenceRequests table (e.g., please start polling for presence updates). We need the Presence.Read and offline_access scopes so we get a refresh token. Auth start doesn’t do a whole lot except redirect the user over to Azure AD to authenticate. We’re going to use the authorization_code flow here to keep any tokens out of the user’s browser. After the user signs in, we’ll ask Azure AD to do an HTTP POST back to us with the authorization code in tow. While we could generate that URL ourselves, we can hand it off to MSAL here using ConfidentialClientApplication.GetAuthorizationRequestUrl, making sure to also include response_mode=form_post to ensure we’re keeping the code out of the URL.

`auth-end`

This function handles the return trip from Azure AD. Notably, it receives the authorization_code Azure AD generates after a successful sign-in and authorization, sends that back to Azure AD to receive an access_token & refresh_token for the requested scopes. We could, again, handle this ourselves, but better to let a library do the heavy lifting - MSAL’s AcquireTokenByAuthorizationCode handles the interaction with Azure AD, then caches the tokens for us.

Next we store the fact that a user authorized us in tables - this is what the timer job uses to determine which presences to request.

Token caching & MSAL

Rather than reimplement an entire token cache, since we’re only interested in changing the persistence of the cache and not the mechanisms of how the cache is serialized, MSAL provides us some delegates we can set - namely, BeforeAccess and AfterAccess. Set these delegates to your own methods to handle the last-step persistence (and rehydration) of your preferred storage medium. I’m using table storage here again, so my Before and After access delegates are only concerned with writing and reading the bytes to and from table storage.

Now - if you read through the guidance from the MSAL team in the wiki & in the docs - you’ll notice this:

A very important thing to remember is that for Web Apps and Web APIs, there should be one token cache per user (per account). You need to serialize the token cache for each account.

In web apps, this is fairly straightforward to accomplish - a user is signed in, so we usually have some bit of identifying information about them to use as a cache key. This way we can query something like Redis, Cosmos, SQL, etc to fetch our MSAL cache. In our case, however, we don’t have an interactive user except for the first time. In fact, we want to keep a very Microsoft-Flow-esque user experience: sign in, store off tokens, do background work as necessary. This means that when we run our timer job without any sort of user context available, it gets dicey trying to figure out which token cache to use.

TokenCacheNotificationArgs (what your BeforeAccess and AfterAccess delegates will receive) don’t have enough user data for us to determine which cache to use, because we don’t have an Account object yet - at timer job runtime, we literally have an empty MSAL object - configured, but no accounts or data yet. That MSAL’s main entry point objects are called ‘Applications’ (PublicClientApplication and ConfidentialClientApplication) is a bit misleading. In reality, the uniqueness per application object is really the token cache itself. What I learned here was that, in fact, we don’t want to use a singleton ConfidentialClientApplication, instead we want a ConfidentialClientApplication per unique token cache which, per the guidance, is per-user. Beyond that, a singleton ConfidentialClientApplication would cause problems with cache serialization - as all accounts within the object at the time are serialized instead of a notion of a ‘swappable’ cache in the same object. Needless to say, I spent a ton of time trying to figure out the best way to go forward.

What I ended up with is an MSAL client factory. Not a big fan of it, but it lets me request an MSAL ConfidentialClientApplication configured with the right caches per user, sent in at runtime. Find it here.

You may also notice a transfer between transient & actual keys. The reason for this is that during the auth-end callback, we have no context to know who the user is - so when we create our CCA to consume the code (AcquireTokenByAuthorizationCode), if we don’t set the cache delegates upfront, they don’t get persisted. This sets the cache before with a random identifier, which is then renamed in storage to the user’s actual identifier once we know who the user is.

Rube Goldberg would be proud.

Once we’ve plowed through this circus, we have a reliable way to get access_tokens for calling the graph. At this point, we’re publishing presence changes from the graph to a topic! Our cloud-side work is done.

Publishing to subscribers

The Service Bus topics are created per user ID, each subscriber should have its own topic subscription (unless they are competing, in that they are doing the same work). I have two locations, Home & Office, so I have two subscriptions, one for each. If I had multiple instances of a subscriber working on a common goal (e.g., updating the lights at my home), those instances would share the same subscription.

Subscribing to updates and manipulating our Philips Hue Hub

OK! Now we’ve gotten our access token and we’re polling the graph. Great! Now we need something to listen for those status changes. This could be anything you want - a light, a sign, or even a puff of smoke (like when they pick a new pope). I’m using Philips Hue bulbs, but my colleague Matthijs built some wild stuff with his presence and a bunch of boards and hundreds of LEDs, plus a really cool MSAL Device Code flow.

Talking to the Hue Hub means creating the equivalent of an API key on the local Hub, then using that in subsequent requests. I looked at Philips’ online stuff, but you can only have one Hue hub per account? Seems like a strange limitation, but since I have one at home and at work, I figured that wasn’t going to work out. Instead, I’ll just talk to them locally.

Creating an api key to talk to the hub locally is a pretty quick one-time procedure. You can do it manually or automate it - but you’ll need to press the button on your Hub, then run your code within a window of time. See more about creating Hue keys here.

Now on to our LocalHueHubSubscriber function. This function is what runs locally, with a network path to your Hue Hub. There is a dockerfile to build targeting dotnet2.0-arm32v7, which runs on a raspberry pi. This function is what’s going to ping our Hue Hub with new colors depending on status. I have a crude status-to-color map (find that here) - it uses a Service Bus trigger and when it fires, makes an HTTP call to the hub with the desired color.

On your raspberry pi, all you need is docker. Use the .env.local file to store configuration and push it into the container at runtime. You’ll need your SB topic subscription’s connection string, plus your local Hue Hub’s IP and path to your light group.

todo

UI for adding user endpoints
ARM template for Azure resources
finish code for creating SB topics when new user onboards

:bowtie:

Find me at @AzureAndChill with any questions or concerns!

Using NSwag and SwaggerUI with Azure AD B2C-protected APIs

John Patrick Dandison — Mon, 02 Dec 2019 23:45:11 +0000

Interested in hosting SwaggerUI/OpenAPI docs for your B2C-protected APIs?

NSwag

Swagger/OpenAPI is a way of defining your APIs through a common markup - from that markup, you and your customers/API consumers can autogenerate client code for your API. But what if you want to host a decent UI for developers to test your API? SwaggerUI is an interface that has been around for a while - it may look familiar, lots of APIs use it for sharing docs. ‘Test-in-browser’ for APIs is super helpful for devs who are using your API, but what do we do if that API is protected by a Bearer scheme using something like Azure AD B2C? Oauth2 flows aren’t much fun to code by hand and can be a big stumbling block for your API consumers to get started using your API. Anything we can do to lower the barrier to entry will help encourage adoption.

In dotnet, we have the NSwag package that has OpenAPI/Swagger doc auto-generation from your API controllers, plus some client-generation code, and of course, SwaggerUI, all shipped as middleware. More docs on wiring this up for your app can be found here. Let’s dig into how we can use UseSwaggerUi3 with OAuth2Client to give your consumers a first-class API doc experience using NSwag and B2C.

B2C setup

First we need a B2C-protected API registration, some scopes exposed by that API and a client app (SwaggerUI) that can request access to those APIs. We’ll also need at least one sign-in policy. You can check out the docs here for getting your B2C tenant created and configured with an Identity Provider and user flows.

API app

If you already have a B2C-protected API, you can skip this part. First we need to create a new app registration, indicating it’s a webapp/api. Make sure you also give it an App ID URI - this will be important for defining scopes.

Next let’s define some scopes. Scopes are permissions that other applications can request from your application. Applications requesting these scopes are only allowed to perform operations within that scope, regardless of what other permissions the user may have. Scopes give us more control over how external apps integrate with our services and the kinds of data/actions they can execute. For example, if you ran a photo sharing service, you may have scopes like ‘PhotoLibrary.Upload’ or ‘PhotoLibrary.Read’ - this way, my super awesome camera app could upload photos to the user’s photo library, but not read or modify photos that are already in the library. Well-scoped APIs are important, especially today when so much of our digital lives is centralized around few providers. Do I really want to give a camera app in the store permission to upload photos to Google Photos but also get access to my Gmail and Calendar? Probably not.

In B2C, defining scopes is done via ‘Published Scopes’ under your API’s app registration. Add whichever scopes you deem appropriate.

If you didn’t define an App ID URI in the earlier step, you’ll need to do it before adding scopes - it’s under the Properties blade of your app registration.

We’ll also need to configure aspnetcore to use Bearer authentication for your APIs. Check here for a full sample. Without this, your APIs are unprotected and none of the work we do here will have any effect.

SwaggerUI client app

Next we need to create another app registration in B2C. This app registration represents your SwaggerUI app, which will effectively be a client of your API. Because your API has published scopes, we’ll also want users to be able to request those scopes in the tokens they request via SwaggerUI, so we’ll need to make sure permissions are granted to allow the SwaggerUI client permissions for the appropriate scopes.

Create a new app registration, again marking it as a webapp/api. You’ll also need to make sure to allow implicit flow and set a reply url. You can do this during app creation or within the Properties pane after creation. In this case, I’m using kestrel (not IIS Express), so my reply url is https://localhost:5001/swagger/oauth2-redirect.html.

Once you’ve created your app registration, we need to allow the SwaggerUI client app to request specific scopes from your API. Note that not all scopes may be appropriate here. For example, if your API exposes operations that don’t make sense for a user to request, or aren’t applicable to your user-facing API (e.g., some sort of batch or ETL process, or a service-to-service method), you may not want to allow a user to request that scope from the UI.

In B2C, go to API Access under the SwaggerUI app registration - Add a new one, find your API from earlier and enable the appropriate scopes.

Save that app and our B2C configuration is complete.

dotnet setup

First let’s add some nuget packages:

NSwag.AspNetCore and Microsoft.AspNetCore.Authentication.JwtBearer.

In our actual software, let’s head over to Startup.cs or wherever you have your aspnet startup class. Here, under ConfigureServices we want to add our OpenApi/Swagger doc configuration, in addition to the OAuth2 configuration.

In our OAuth2 configuration, we have a few values to keep in mind. Remember that these are the scopes that are published by your API and the SwaggerUI application registration was assigned access.

b2c_tenant_name is the name of your b2c tenant - in my case, jpdab2c
Your list of appropriate scopes (in the format of your app id uri/scope name, e.g., jpdab2c.onmicrosoft.com/your-api/read)
Your sign-in flow’s policy ID (this usually starts B2C_1, the example below shows b2c_1_susi_v2, the name of my sign-in policy - this is the specific policy a user would use for sign-in).
Your authorize and token URLs for the specific sign-in policy you want to use for SwaggerUI - this may be different from the one users would use to get into your application, if you wanted different pieces of information or requirements for your developer’s flows vs active users. Note the URLs are policy-specific. You can get this from the metadata discovery document under the ‘Run Now’ view of your user flow/policy, or using this format: https:// **b2c_tenant_name**.b2clogin.com/ **b2c_tenant_name**.onmicrosoft.com/v2.0/.well-known/openid-configuration?p= **B2C_1_user_flow_name**

public void ConfigureServices(IServiceCollection services)
{
    // snip
     services.AddAuthentication(opts => opts.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(opts =>
        {
            opts.Authority = $"https://login.microsoftonline.com/tfp/b2c_tenant_name.onmicrosoft.com/b2c_1_policy_name/v2.0/";
            opts.Audience = "client/application ID of api";
        });
    // see docs for more config options for AddJwtBearer

    // Add security definition and scopes to document
    services.AddOpenApiDocument(document =>
    {
        document.AddSecurity("bearer", Enumerable.Empty<string>(), new OpenApiSecurityScheme
        {
            Type = OpenApiSecuritySchemeType.OAuth2,
            Description = "B2C authentication",
            Flow = OpenApiOAuth2Flow.Implicit,
            Flows = new OpenApiOAuthFlows()
            {
                Implicit = new OpenApiOAuthFlow()
                {
                    Scopes = new Dictionary<string, string>
                        {
                            { "https://<b2c_tenant_name>.onmicrosoft.com/your-api/user_impersonation", "Access the api as the signed-in user" },
                            { "https://<b2c_tenant_name>.onmicrosoft.com/your-api/read", "Read access to the API"},
                            { "https://<b2c_tenant_name>.onmicrosoft.com/your-api/mystery_scope", "Let's find out together!"}
                        },
                    AuthorizationUrl = "https://<b2c_tenant_name>.b2clogin.com/<b2c_tenant_name>.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_susi_v2",
                    TokenUrl = "https://<b2c_tenant_name>.b2clogin.com/<b2c_tenant_name>.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_susi_v2"
                },
            }
        });

        document.OperationProcessors.Add(new AspNetCoreOperationSecurityScopeProcessor("bearer"));
    });

    //snip
    services.AddControllers();
    // ...
}

Next let’s tell aspnet to enable the UI. The code below includes the entire Configure method used in aspnetcore3’s API template - I’ve included it for posterity but yours may/will look different depending on your configuration.

Here we have a couple of values to note:

ClientId is the client ID/application ID of the SwaggerUI application’s registration. You can get this from the Properties pane of your client app’s registration
AppName is a display name that shows in the SwaggerUI interface

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

    app.UseHttpsRedirection();

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    // additions for OpenAPI and SwaggerUI
    app.UseOpenApi();
    app.UseSwaggerUi3(settings =>
    {
        settings.OAuth2Client = new OAuth2ClientSettings
        {
            ClientId = "bb893c2d-fca9-446e-92f7-c4a400491005",
            AppName = "swagger-ui-client"
        };
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

Now let’s try it out!

Let’s go

Run your app, then head to https://localhost:5001/swagger. Your APIs should have been automatically discovered and you’ll notice an ‘Authorize’ button in the top left corner. Click it and you should see a new modal dialog with some options for requesting a token. It’ll look something like this:

Check the boxes for the scopes you’d like to request, then click Authorize. This should redirect you over to B2C where you can sign in. This policy in my B2C tenant has some UI customization applied:

Once we signin, we get redirected back to our SwaggerUI, token in-tow:

Now when we try out one of our API calls, SwaggerUI handles tacking on the bearer header for us:

And finally, if we go take a look at the token we received at jwt.ms, you’ll note the scopes we requested in the SwaggerUI modal are also available:

:bowtie:

Find me at @AzureAndChill with any questions or concerns!

Automating non-RBAC AKS and kubectl with Azure AD service principals

John Patrick Dandison — Tue, 19 Nov 2019 20:08:17 +0000

This came across my desk this morning and it happens frequently enough that I figured it worth writing about (write once, refer frequently!). Cloud services are made for automation from the ground up - automation is how you reach maximum efficiency of both the resources you create in addition to the people creating & managing them. Of course, with automation, we still need security around who/what can login and manipulate those resources. Today we’re going to look at using the Azure CLI with service principals & kubectl.

Why not user accounts?

If we take a trip back in time, when people gasp! deployed and managed servers in their own datacenters, we’d create accounts in Active Directory or wherever and use them as service accounts. These service accounts were typically treated differently (e.g., with different policies, or different management attitudes) and used for servers, services and applications to get access to other resources. Your SQL Server might have its own domain account, your IIS appPools would run under a domain account, all sorts of things. But until late in the 00s, with the introduction of managed service accounts, these ‘service accounts’ were largely just ‘accounts’ that were used for services. They were not really any different from the account you or I might use to login to our PCs.

Once we transitioned to Azure AD, these types of habits continued.

SCENE A non-descript office building somewhere in the world.

(USER sits at large table. As USER sits, TABLE reveals itself to have a large touchscreen built in. “SUR40” flashes across the screen.)

USER. OK, apps team needs a ‘service account’ for deploying their app in Azure…, hmm…

(USER flips through stack of post-it notes. We see various URLs, like manage.windowsazure.com, portal.azure.com, aad.portal.azure.com, account.activedirectory.windowsazure.com, etc.)

USER. Ah! Here it is.

(USER opens web browser on TABLE. A Silverlight logo briefly appears, followed by a bugcheck. USER, defeated, pulls Surface Laptop out of bag and places it on TABLE.)

USER. I need to get the details of this ticket out of my email.

(After a lengthy pause, Outlook opens, then quits. USER grumbles indecipherably about Access, Exchange and JET databases before deciding to go straight to the ticketing system.)

USER (Calling to someone off stage). What’s our TF Service URL again?

VOICE OFF STAGE. I’ll send it to you on our Teams team. It’s contoso.visualstudio.com. Make sure you build an ARM template for anything you need to deploy. It’s called azure devops now by the way…

USER. Thanks. I don’t have vscode on my laptop so I’ll have to use VS Online for this. OK, new service account - let’s go to Users, Add New..

USER (to self). It’s called Azure Active Directory , so surely it must be the same, right? Microsoft wouldn’t give multiple disparate things the same name or rename the same thing every six months, right?

Using user accounts for automation is a Bad Idea™ and we should strongly consider otherwise. There are many reasons, but here are the first ones that come to mind:

Process - how do users on/offboard at your company? How frequently are passwords changed? Do you want to be on the hook for updating n services every time you need a password change or reset?
Availability - similar to above, what happens when your password expires and you’re on vacation? Do all of your services go offline?
Modern authentication pipelines & experiences - things like MFA, conditional access, security keys, passwordless - all of this goes out the door if you’re using a username & password non-interactively.
Security - what kind of services are available to your user account? What kind of lateral movement would an attacker be able to execute with your credentials?

Many people have written many words on this topic, so I’ll move on - but the message is clear - do not use user accounts for automation!

Service Principals

So what should we use? Azure AD offers Service Principals - these are effectively ‘service accounts,’ but we have far more control over both the scope of privileges & access granted to the principal, in addition to being able to tightly control both credential and lifecycle. For example - Azure AD SPs can use passwords or certificates for authentication. An organization with a centrally-managed certificate authority can rotate certificates on a schedule, keeping credentials entirely available yet out of the hands of developers. Beyond that, Managed Service Identity offers managed service principals tied to a resource (very much like managed service accounts from AD) where credentials are completely managed by Azure, but the service principal can be assigned permissions & rights just like any other principal.

RBAC vs non-RBAC AKS clusters

There are two ways to use AKS clusters in Azure - with or without Azure AD integration, usually referred to as ‘RBAC-enabled’ in most of the docs. The key difference here is related to the management vs. data planes of the Azure resource, in this case the AKS cluster. For example, think about an Azure VM. I may have management rights to deploy/restart/change the VM’s Azure configuration (disks, networking, resource group, etc), but may not have an account to RDP to the VM and make any changes there (the data surface). Similarly, I may have the ability to manage a storage account or SQL DB - change properties, move to different groups, add data sync partner regions, etc - but I may not have access to the data within those resources.

In a non-RBAC cluster, we have management rights within the Azure portal to manage the resource, including getting credentials for kubectl. The difference between this route and the RBAC route is the type of credential - in a non-RBAC scenario, I’m using a service principal to fetch/generate a credential for AKS, but the credential itself is disconnected from the service principal. It is merely access to generate a credential for the management interface. In an RBAC or Azure AD-enlightened cluster, not only will my service principal potentially be used to manage the cluster, but I can also connect to the cluster as the service principal which offers a greater level of granularity to the types of management operations allowed within the cluster itself, e.g., roles that are more granular than what is populated within the Azure management surface.

For an RBAC cluster, check the docs here instead.

In our specific scenario, let’s look at how we can create a service principal for use with a non-RBAC-enabled aks cluster & kubectl. This is fetching credentials, but not connecting as the service principal.

Creating the service principal

This is pretty straightforward, if you have permission within your Azure AD tenant. In most cases you will. If you don’t, you’ll have to talk to your admin 😒 Get logged into your az cli:

az login

Once we’re logged in, hit it with this (full documentation with a ton of options for creating these is here):

az ad sp create-for-rbac --name "my-aks-automation-sp-name"

Note that this SP is different than the one you configured when you created your aks cluster. This is a general purpose SP that you can use for all sorts of things (although I’d suggest using just one per task, with granular permissions). They’re free, so create as many as you want.

The output of az ad sp create-for-rbac will give you a chunk of info - notably, your new service principal’s ID (shown as appId in the response). If you go the password route (e.g., you didn’t include a certificate), you’ll also get a password and the name of the Azure AD tenant the SP was created within.

Hooking our SP up with some permissions

Next we want to grant our SP some rights to resources. You can do this in the portal or CLI. In the portal, go to your resource - in our case, your AKS managed cluster. You only have to assign the rights once so no one will judge you for doing it from the portal. You can also dig around to find the right role IDs and assignment scopes, but there are lots of docs for that. If you have a lot of clusters it may be worth that effort. I’ll do a follow up if anyone asks.

Once you find your AKS cluster, click Access Control (IAM) and add a role assignment. Search for your SP (the appId field will work, or the name as listed in the output of the az ad sp command earlier). Find an appropriate role. In my case, Azure Kubernetes Service Cluster Admin Role is what I was looking for. Select that, then make sure you Save/Add the role assignment.

Logging into the CLI with your newly minted SP

Now that our roles are assigned, let’s jump back to the CLI. You can do this in your current CLI but, of course, this can be made a part of your deployment scripts through your deployment tool of choice - if it can run az-cli, it can be automated.

If you want to be absolutely sure it’s working, clear all existing credentials first using az account clear. Once we’ve done that, let’s get logged into the CLI with your SP. All of the required info for this came out of the output of the az ad sp command.

az login --service-principal --username "your-service-principal-appId" --password "your-service-principal-password" --tenant "your-service-principal-tenant.whatever"

Of course, if you used a certificate you’ll need to make sure your cert is available to the cli and the command switches will be a bit different. Refer here. You can ensure your login was correct by checking the output - under user.type, you’ll see servicePrincipal. You can get back to this at any time with az account list.

`kubectl` as an SP

Lastly, we need to get our aks credentials for kubectl:

az aks get-credentials -g *your-resource-group-name* -n *your-aks-cluster-name*

Make sure it all works with kubectl get nodes

:bowtie:

happy automating!

Retrofitting OIDC to legacy systems via reverse proxy

John Patrick Dandison — Wed, 30 Oct 2019 08:24:18 +0000

Obviously we want systems that use modern authentication. In the case of Azure AD, you get the good stuff, like Conditional Access and a whole host of new authentication mechanisms, like Windows Hello & FIDO2.

This is a big jump, however, especially for old apps. And by old, I mean old - running on unsupported or deprecated platforms (or versions of those platforms), where the skillset doesn’t exist in your circle to update it, or where the vendor who created the platform has ceased to exist. Consider too that some legacy systems may be on-deck for total replacement, either with custom dev or off-the-shelf systems, where we want to keep costs as low as possible.

Like most modernization projects, there are different ways to approach the problem - in this case, I’m focused on the ‘moat-building’ method, where we dig out and isolate the problem systems and proxy access through more modern systems. This is a bit quick-and-dirty, but for systems that are slated for replacement or just can’t be touched, it’s a low-impact way to wrap new functionality around an old problem. You can apply this to all sorts of parts of a system as well - e.g., extracting and shipping data out of an old system into a new system and schema while slowly moving referencing bits over to the new system.

Let’s dig in.

Reverse proxying

Since we’ve got a web app and we want to add only authentication, it’s relatively straightforward. We need to:

Authenticate the user, using a typical oidc-tango
Redirect to identity provider
Consume and validate issued token
Read claim data
Transform some claim data before forwarding along
In our specific case, we need specific values from the claims to be forwarded in a specific header

Layout

Our layout is straightforward. We have our original old app (we’ll call it old-app.example.com) and our front-end (myapp.example.com). We’ll need to make sure DNS resolves on the Apache host for old-app.example.com and that our old app server is configured for that host header or to accept all names. If it’s not in your local DNS, you could add it to /etc/hosts for local resolution.

Next we’ll want to make sure myapp.example.com resolves to our Apache server. You would likely want to use named virtual hosts here, although you could get away with * if you wanted. My virtual host on :80 is just redirecting to :443 - yours may need to do something different.

Lastly you’ll want to make sure you have any TLS certs available and installed on the Apache host.

I’m using Apache 2.4.* on Ubuntu 18.04, with binaries for mod_auth_openidc 2.3.3, which is available in the universe repositories.

Considerations

Since we’re usurping the user path to the app, we’ll need to make sure we manipulate the network environment & DNS in a way to make the app either inaccessible or unusable if someone was to hit it directly. If hosted in Azure, this could be something like a two-subnet VNet, one subnet with the app and the other with the proxy, with NSGs locking down the app subnet to only allow traffic from the proxy subnet. On-prem there are myraid ways to segment networks and restrict access.

You’ll also want to host with TLS, Azure AD reply URLs will require https except in the case of localhost.

Apache config

For apache, we’re going to use mod_auth_openidc which is an OIDC-compliant relying party/client module for OpenID Connect.

Let’s take a look at the config.

Results

The mod_auth_openidc package includes all the claims as passthrough headers, in addition to our custom header with our transformed value. My source claim in this case was preferred_username, which we transformed via apache to X-jpda-header-loc.

The advantage to this method is potentially many apps could live behind this proxy, with very little additional effort to onboard more. Of course the tradeoff with proxying is a single choke point for traffic, so carefully consider which apps should be grouped behind specific instances.

Private App Service-to-App Service calls in multitenant PaaS

John Patrick Dandison — Fri, 14 Jun 2019 18:11:10 +0000

Recently, Shannon & I got an interesting request from a customer who is using multi-tenant App Services (e.g., non-ASE), but wanted to keep communications restricted to their virtual network. If you’re familiar with Azure App Services, typically the way to achieve this is via an App Service Environment (ASE). ASEs are single-tenant, dedicated nodes running the App Service stack in your virtual network - this flips the ‘private’ bit as they have RFC 1918 IPs from within your VNet. This means you can do pretty much whatever you want with networking - use 17 firewalls in front of it, access vnet or on-prem resources, whatever. Problem is, they can get a bit pricey, at least relative to multi-tenant App Service. Internal ASEs can have a bit of deployment drama too, since you need to manage DNS and get wildcard certificates for your ASE (wildcard certs being particularly difficult to get from security & ops teams). Fortunately, with some (very) recent additions, this is possible using a combination of ‘New’ VNET Integration (gateway-less) and Service Endpoints/IP Restrictions in Azure. Let’s dig in.

Layout

We’ve got:

jpd-app-1, a web app (API) with it’s own App Service Plan
jpd-app-2, another web app (API) with it’s own App Service Plan
a vnet, vnet1, with three subnets, jpd-app-1-subnet, jpd-app-2-subnet and default
a VM for testing, in the default subnet
The two apps & vnet live in the same region

We need jpd-app-1 and jpd-app-2 to talk to each other and also be accessible from the VNet, but not from the internet at all.

Integrating with the VNet

First we need to get integrated to the VNet from each of our app services. We need to keep the app service integrations in their own subnets, so we can delegate the subnet to the App Service. First we need to register the Microsoft.Web service endpoint. If you’re creating a new VNet, you can do this at creation time. If not, it’s easy to enable afterward.

During creation:

After creation (from the VNet –> Service Endpoints pane). Enable it on all the subnets you want to access our App Services from.

Once you’ve enabled them, head to the Networking pane of the first App Service (jpd-app-1 in my example).

Configure VNet Integration, then choose Add VNet (Preview). Choose your vnet, then your subnet.

Do this for both of your App Services, integrating each into their respective subnets. At this point, our app services are now connected to vnet1 - if we had resources we needed to access in the VNet, like a VM, a SQL Managed Instance or even something on-prem via site-to-site VPN, we’d be able to by this point. The app services are exposed to the internet, however. We’ve enabled access from the App Services to the VNet, but we haven’t restricted access to the App Services to only the VNet just yet. For that we’ll use Access Restrictions.

Access Restrictions

Next we need to enforce the access restrictions. Back in the networking pane of your App Service, you’ll see ‘Access Restrictions.’ This is where we’ll add our vnets. By default, your App Service will allow all traffic from all sources. You can leave the default Allow All rule, since as soon as we add our own restrictions, the Allow All rule becomes a Deny All, with our rules taking priority.

You’ll also note there are two hosts listed - <yourapp>.azurewebsites.net and <yourapp>.scm.azurewebsites.net - the first one is your app, the second one (.scm.) is the backstage view of your web app, the Kudu console. You can restrict these independently. Make sure you add restrictions for both the main site and Kudu/scm site if you don’t want any access from the internet!

Now let’s add our restriction! Since this is jpd-app-1 and it’s integrated into the jpd-app-1-subnet subnet, we need to add two rules:

Access from jpd-app-2-subnet subnet
Access from default subnet
Deny everything else

First the jpd-app-2-subnet rule. Make sure you choose ‘Virtual Network’ in the type. Then choose your vnet (vnet1) and your subnet for the other app that needs access (jpd-app-2-subnet). Repeat for (default) to enable the rest of the vnet and any other vnets/subnets that may need access.

Repeat for the other app

In your other app (jpd-app-2), do the same thing. Add access restrictions, only this time choose the subnet of the other app (jpd-app-1-subnet).

Testing

If you go to your app in a browser from your local machine, you should get a 403, ‘web site stopped.’ This is the experience for app services that are restricted - it’s a 403 Forbidden, stopped is a bit misleading here.

From your web app’s kudu console (<yourapp>.scm.azurewebsites.net), which is either accessible only from the VM on your vnet, or from the internet, if you didn’t add a restriction, we can do a curl to the other app to make sure our configuration is all square. tcpping isn’t valid here, because the site does respond to ping - as it is available on the internet, but returning 403.

curl -sI https://<yourapp>.azurewebsites.net

This should return some HTML/markup. If it’s a 403, something is wrong. If you get a 200/OK, you’re in business!

Note: you may notice that my URLs changed near the end - I added a bad rule so I had to trash the two app services and recreate them. Don’t put zero (0) as a priority for a rule!

I haven’t tried this with Functions on a consumption plan yet, but that’s coming next. Stay tuned!

Geo-replicating Azure Service Bus with guaranteed ordering

John Patrick Dandison — Tue, 23 Oct 2018 14:20:35 +0000

Photo by Slava Bowman

Recently, I had an interesting question come across my desk from a customer:

How do we ensure Service Bus message ordering and get active/active geographic availability?

We’ve solved parts of this in numerous ways over the years — Service Bus supports paired namespaces — but with a list of caveats that include out-of-order messages. It’s also a question of send availability vs. receive availability. We want our producers to always be able to send messages — that means our receivers/consumers will need to be smarter, but we’ll get into that in a bit.

In our specific scenario, global message ordering is of lesser importance than transactional or scoped message order — consider 10 transactions, 0, 1, 4, and 5 are related, 2, 3, and 6 are related, and 7, 8 and 9 are related. Those three batches can be processed in any order, but the messages within the specific batch or scope need to be processed in order. We see this issue frequently when customers are integrating with legacy systems or mainframes.

For a more concrete example, let’s say I’m tracking a lot of shipments. I have many shipments and each shipment has a collection of statuses. Those statuses are serial — a package destined for Charlotte from Seattle probably wouldn’t end up in Des Moines before departing Seattle.

Here’s some data:

However, if I have multiple packages, I don’t really care if package A or package B has its statuses updated in my backend system first, as long as the order of the status messages for each specific package stays consistent.

Another example — change-data-capture out of a database system. If I run an INSERT after a DELETE, even though the DELETE happened first, my data isn’t going to be correct.

Back to our shipment tracking scenario. First we need a way to ensure ordering of messages within our Service Bus queue or topic. We’ll use Message Sessions for that. Message Sessions have some other tradeoffs, however — a session ID is effectively a partition key. It means that data with that key is stickied to a particular data store. It makes sense when you think about it; messages distributed across multiple data stores would require a lot more processing server-side to collect and order.

In-order processing implies some other tradeoffs too — by definition, messages are processed in order, serially, by a single consumer at a time— no processing parallelism here (well, at least not within our individual sessions — we’ll get there soon).

Messages within a session are FIFO — but not necessarily our sessions themselves. We may have many sessions to process, which we would want to process concurrently. Remember, we only care about order guarantees within the scope of our session/shipment. This way we can still ensure timely message processing without impacting our ordering requirements.

In a single Azure region this is no big deal. We have our Service Bus namespace in, say, East US, and our producers and consumers live in the same region. Full-region failures in Azure are certainly quite rare, but not completely unheard of. Service degradation or service-specific outages are still a concern too, along with dependent services (e.g., when a storage outage causes cascading failures of other services within a region). For our customer, they’re deployed into two regions in the US, and App Service, SQL DB, storage, etc are all geographically replicable in one way or another (or stateless). Service Bus was the one thing we didn’t have a compelling answer for, so we decided to build them a way to achieve it.

Let’s start with the code — it’s here: https://github.com/jpda/azure-service-bus-active-rep — we’re going to use:

Two Service Bus namespaces, in different regions.
A strongly-consistent Cosmos DB collection, as a message journal
Message Sessions in our Service Bus queues

Send Availability

To maintain send availability, we’re going to setup two independent Service Bus namespaces and create a session-enabled queue within each namespace. You could do this with Topics as well, if your case requires that.

Each sender will mark the session with some sort of deterministic ID or domain unique key. In our shipping scenario, a tracking number would be an excellent session key. It could also be some other unique ID that represents the scope of the messages being sent — customer ID, transaction ID, etc. Your sender should send the message to both queues, with identical session and message IDs.

In practice, the Session ID represents the ID of the entity you would like to ‘lock’ — because the consumers will attempt to record their work items in the Cosmos DB collection using the entity ID (session or message) as the document ID, if there is a document ID collision, the consumer will receive an exception and refetch the entity to get the latest status before beginning processing. We’ll dig into this below.

You’ll also notice in the Sender that we’re setting the ScheduledEnqueueTimeUtc to now + 15 seconds on one of the queues. We’ll address this later but it’s primarily to reduce churn and prefer a ‘primary’ region over another.

https://github.com/jpda/azure-service-bus-active-rep/tree/master/azure-service-bus-active-sender

Receive Availability

Receive availability gets tricky when you have multiple copies of the same message, especially in an integration case where you don’t have full control over the final destination of the data. In our case, we’re interacting with a mainframe (among other systems) and don’t want to add undue stress by deduplicating messages via querying the mainframe.

Instead, our consumers follow a fairly simple (albeit chatty) pattern:

Open a MessageSession
Create new document with SessionId or SessionId_MessageId as the Document ID
If we succeed at creating the document, we then update the status in the document (e.g., Status: Working)
If we get a 409 (Conflict), we pull the latest version of the document from Cosmos and check status
If the status is Pending, we update the status to Working, attempt to write again, wait for 200
If we succeed, then we start processing the message
When we’re complete, we update the document again and Complete the Service Bus message.

That’s a lot so we’ll break it down a bit.

First we start receiving a MessageSession. This locks/hides all other messages with that SessionID in the specific queue, so we can be sure this consumer will process them in the order received.
Before we start processing the message, we record in our journal (our Cosmos DB collection) the session ID or session/message ID composite. Because we’re using this as our document ID, if there is a conflict (e.g., another consumer has already created the document), Cosmos will return a 409 Conflict — at which point we know another consumer has started reading the session in one of our queues.
If that journal write is successful, we then attempt to update the document — updating a field called Status to Pending or Working.
This update follows the same rules; if the document we have updated is older than what is in the database, Cosmos returns an error code — at which point we fetch the latest version, check status and decide from there.
If the update to status succeeds (e.g., we’ve updated the status to Working) we can start to work.
These two operations being discrete (instead of as a single operation) means we keep the window for changes small.
When we’re done processing the message, we can Complete the message to remove it from the queue and begin processing the next.
The other consumer in the secondary region will pull the document, see the status as ‘Working’ and Abandon the message; abandoning here will cause the message to unlock, and the next consumer will attempt to pick it up. When a consumer reads the message, checks status and sees a status of Completed, the message in the secondary queue will be Completed(note, in the code sample today, the consumers are not abandoning the messages, they are looping with a sleep/wait to recheck message status).

In a failure case, where one of the consumers has failed, we have two stages of failure:

The processing logic in the consumer has died, but not the process (e.g., the process hosting the processing logic is still alive) — in this case, our processor could attempt to reprocess, or in the case of an irrevocable failure, update the journal status for that message or session to Failed or Faulted, and move the message to the dead letter queue for manual remediation.

If the consumer has died completely (as in, the process is completely dead), we can use MessageWaitTimeout on the SessionHandlerOptions we use to configure the SessionHandler to set a reasonable timeout. Once that timeout duration has passed, the session is unlocked and our next consumer will pick up the session, check status in Cosmos and continue processing.

https://github.com/jpda/azure-service-bus-active-rep/blob/master/azure-service-bus-active-receiver-lib/DataReceiver.cs

Entity Locks

Your choice of entity lock has some implications. If you choose to lock at the Session level, your secondary receivers will abandon the session, at which point your primary consumer is expected to process the entire session. The risk here is you may need to manage which messages have been processed in the session in case of a failure — e.g., Session ID 1 has messages A B C and D. A and B process correctly, but C causes the consumer to die; the secondary consumer will need to either reprocess all messages in its copy of the session (as it doesn’t know which messages have been processed), supporting at-least-once delivery, or it needs a message processing log to ensure it doesn’t process a message a second time.

If you go the session + message composite ID route, where you’re logging each message in a session, you’ll be able to keep your two queues in sync both at the session level and the message level. As messages change state within the primary queue, as the secondary processors pick up that change, they’ll dispose of the messages to mirror that (e.g., Session 1 Message A, primary has completed, journal updated, when Session 1 Message A secondary checks Cosmos with that ID and sees it is completed, it will complete the secondary message). The risk here is a potential out-of-order case where the secondary gets ahead of the primary, because of an unknown failure with the journal. I haven’t figured out a case where this would happen, as the messages should be in the same order in both queues, but theoretically:

Primary Message 1 → Cosmos record written → Processing beginning
Secondary Message 2 → No Cosmos record written → Processing beginning

Load balancing

In our scenario, we have a set of legacy systems, some are single instance, some are on-premises. We’d prefer the majority of our traffic go through a single ‘primary’ Azure region, closest to our on-premises systems, but failover to a different region in case of a region fault.

In addition, this model is similar to products we’re already using (like SQL DB geo-failover), so we’d already be following this primary/secondary type of pattern in any case.

That said, this same pattern could be used for processing messages in any region, by any consumer, for potentially greater scale and throughput.

Additional notes + thoughts

As we said earlier, the senders here are dictating which entity to lock — if, for example, we want to allow individual messages to be locked (vs an entire session), the sender can use a completely unique or more granular session ID (perhaps a composite, like PackageId_ShipmentStatusId), which would be reflected in the journal. In this case, our primary and secondary consumers could consume the session independently in each queue. The receivers don’t care what entity is being locked, as long as the entity locking (and by extension, the entity ID generation scheme) is consistent.

We’re writing messages with ScheduledEnqueueTimeUtc to the secondary queue with a 15 second delay, primarily to prefer our primary region over the secondary. Provided everything is operating normally, this should provide ample time for the primary set of consumers to receive, check and record work items before the message even appears in the secondary queue.

This is a work in-progress, so feedback is welcome.

Generic ListAdapter for Xamarin.Android RecyclerView

John Patrick Dandison — Thu, 09 Aug 2018 16:23:14 +0000

I’ll preface this to say I know literally nothing about Android (or mobile, in general) development. I’ve used Xamarin for about 7 hours now and I think it’s neat, but my only goal is to get up a stub of an app to act as a client for the real work, which is a bunch of Azure stuff. This might be useful to someone or it could be a complete Dunning-Kruger moment for me, only time will tell. Proceed with caution.

After reading a bit about ListViews I found out about RecyclerView, which has some cool viewport management stuff to reclaim memory for items you’ve scrolled past while queuing up new items about to come into viewport.

Image from Xamarin blog post here

Anyway, I have two collection types for my stub app, Contacts and Conversations. It’s pretty straightforward, but as I was working through the adapter → viewholder stuff, it seems duplicative.

Let’s start

I went though the Xamarin blog post, adapting what was there to my needs and types. I’ve got:

Contact— my actual entity, in this case Name and Email
ContactsListRow— the axml item template markup
ContactsAdapter— the adapter that actually inflates the view and binds the data
ContactAdapterViewHolder— a holder object that keeps references to the views within the RecyclerView template (e.g., the TextView)

As I started replicating this for a different collection, it dawned on me this is actually a lot of the same code.

If we look at the ContactsAdapter, we see a lot of the same thing:

A generic collection of our items
Linking a ViewHolder to a layout
Binding an entity item to a ViewHolder

That’s really about it. Take a look:

Notice there’s really not a whole lot of specific stuff in here. Let’s look at the reusable one:

The only specific stuff we need to know about is

T — Type of collection
V — Type of ViewHolder
Action<T,V> — a method that takes our item and our viewholder and binds them

Let’s look at usage — you’ll notice we really just pushed some code around to different places. Here’s our usage in something like MainActivity.cs. Our binding logic has moved to the anonymous method, and we’re explicitly telling our ListAdapter the type of our collection and our ViewHolder.

So far I think Xamarin is pretty neat. I don’t foresee a career shift to mobile development anytime soon but this is at least making it a lot easier! More to come on the Azure bits we’re wiring up here soon.

DEV Community: John Patrick Dandison

DarkSky to WeatherKit: from API keys to signed JWTs

Enter WeatherKit

Get all of your pieces

Testing with Postman's excellent JWT signer

JWT Payload

Variables & pre-request script

JWT Header

Ready! Let's get the weather...! Right?

Ok so NOW we can get the weather?

Now what?

Local executable

Remote

Next, we'll pick!

425show @ Build 2021

Learn Live: Application types in Microsoft Identity (5/25, 3p ET)

Quick hits: Azure AD B2C with the MSAL v2 Angular alpha

Just what *is* the /.default scope in the Microsoft identity platform & Azure AD?

Quick background

Scopes & permissions

Let's order some business cards!

Dynamic consent

/.default

When must I use the /.default scope?

Connecting to Azure blob storage from React using Azure.Identity!

What is blob storage?

But how do we ensure secure access?

Enter Azure AD & Storage Blob Data RBAC

Bill of Materials

Setting up our blob storage account

Azure AD setup

Now we can write some code!

Stay connected!

Creating a Teams presence publisher with Azure Functions, local and cloud

Teams Presence

Let’s build!

Presence updater job

Authenticating users and asking for consent

auth-start

auth-end

Token caching & MSAL

Publishing to subscribers

Subscribing to updates and manipulating our Philips Hue Hub

todo

Using NSwag and SwaggerUI with Azure AD B2C-protected APIs

NSwag

B2C setup

API app

SwaggerUI client app

dotnet setup

Let’s go

Automating non-RBAC AKS and kubectl with Azure AD service principals

Why not user accounts?

Service Principals

RBAC vs non-RBAC AKS clusters

Creating the service principal

Hooking our SP up with some permissions

Logging into the CLI with your newly minted SP

kubectl as an SP

Retrofitting OIDC to legacy systems via reverse proxy

Reverse proxying

Layout

Considerations

Apache config

Results

Private App Service-to-App Service calls in multitenant PaaS

Layout

Integrating with the VNet

Access Restrictions

Repeat for the other app

Testing

Geo-replicating Azure Service Bus with guaranteed ordering

Send Availability

Receive Availability

Entity Locks

Load balancing

Additional notes + thoughts

Generic ListAdapter for Xamarin.Android RecyclerView

Let’s start

Just what is the /.default scope in the Microsoft identity platform & Azure AD?

/.default 

`auth-start`

`auth-end`

`kubectl` as an SP