Skip to content

Azure Active Directory Support

YingXue edited this page Aug 18, 2022 · 19 revisions

Requirements

Per security review, we will need to enable AAD auth flow. The requirement is as simple adding AAD support, but there are many implications we will go through in this doc.

What we will do

We will allow users to login in through AAD. After the users has successfully logged in, we will present users with a list of subscriptions and the IoT hubs, so the users to pick and choose, and from where, they will be use the App as if they've added a IoT hub connnection string.
As a preparation step, we need a first party app pre-authorized to ARM. Here is the ICM we filed for this pre work.

What we will not do (scope, limitations and considerations)

We will not allow users to use a hybrid of both authentications, meanning they will either use AAD to login in, or use IoT Hub connnection strings. Explictly, we have the following scenarios:

  1. First time users will pick AAD or Hub connection string. We will save their preference in Local Storage
  2. Returning users will be presented with either a connection string page or a button to login through AAD based on the preference they've picked before
  3. We will always provide a way for users to repick the preference.

RBAC is not part of work scoped, but should be scoped as soon to follow. The reason being, once we enable AAD, we would allow users who disabled connection string to start using the app. Though connection string needs to be enabled in order to monitor event hub device telemetry (to be verified), which is the majority of what our users are doing. With this consideration, we are decoupling the RBAC work believing we are not making the current situation worse.

The AAD authentication will only be enabled in Electron mode as the MSAL library we are going to use is in Node. In browser mode, we will not be able to use this auth flow (not through npm start). Please refer to the Dev Manual regarding to how to debug Electron.

Prerequisite

Security Consulation is recommended because there is a decision that we need to make and we need to know if there is any security implications, and that is can we pass plain access token from Electron's node server back to the client side. We have the following reasoning:

  1. Passing the token back allow our code to converge earlier.
  2. We don't have to write too many IPC boilerplate code.
  3. The node server is in the same user box as the client

Some investigations we will be doing is MSAL at client side (turns out it's not intended for electron):
https://www.npmjs.com/package/@azure/msal-react
https://review.docs.microsoft.com/en-us/identity/microsoft-identity-platform/msal-js-wrapper-intro?branch=main

Per the preliminary security review, since Explorer is an open source project, it does not need any formal approval on this sort of design choice, and we can always update accordingly as we go.

High level design

What we currently have:

  • We have a connection string list view for users to add/edit/delete IoT Hub connection strings.
  • When users add a new connection string, we will update the connection string stored in Local Storage, making the most recent one appearing to the top of the list (index 0).
  • Services will make use of first connection string from Local Storage to make API calls, by generating Sas token from it.

What we need:

  • User will be able to choose login through AAD vs use Hub connection string.
  • By making the initial choice, the app will set a login a preference value in Local Storage.
  • User will be able to switch auth mode.
  • In AAD mode, IPC will either broker the ARM token between node and client, or it will be fully responsible to grab hub listed by subscription, let user pick a hub, and get the key (connection string).
  • Services calls in **service.ts will be updated accordingly grabing the right connection string (based on the auth selection preference stored in Local Storage) to make API calls.

Detailed design

image Link to the ascii flow

image