Microsoft 365 Community Building a partner offering with Azure AD secured multi-tenant APIs and Viva Connections Adaptive Cards extensions, 15 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Implementing custom Azure AD secured APIs for Viva Connections ACEs (series 3/4)

Description

In this video, you can see how to develop Azure AD secured multi-tenant APIs that you can consume from Adaptive Card Extensions (ACEs) for Microsoft Viva Connections.

Here you can find the source code of an end to end reference solution used in the videos: https://github.com/pnp/spfx-reference-scenarios/tree/main/samples/ace-pnp-contoso-orders

Video Presenter: Paolo Pialorsi (PiaSys) | @paolopia

Here you can find additional information about the topic covered:
- Playlist on the four video series -
- PnP Contoso Orders - Reference Solution - https://github.com/pnp/spfx-reference-scenarios/blob/main/samples/ace-pnp-contoso-orders/docs/Introduction.md
- Scenario API implementation details - https://github.com/pnp/spfx-reference-scenarios/blob/main/samples/ace-pnp-contoso-orders/docs/APIs-Implementation-Details.md
- Overview of Viva Connections Extensibility - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/viva/overview-viva-connections
- Build your first Viva Connections Adaptive Card Extension - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/viva/get-started/build-first-sharepoint-adaptive-card-extension

Additional resources:
• Learn more about the Microsoft 365 Patterns and Practices community at: http://aka.ms/m365pnp
• Visit the Microsoft 365 Patterns and Practices community YouTube channel: https://aka.ms/m365pnp-videos

A

Welcome to this video about implementing custom azure id secure, the pis for viva connections, adaptive card extensions, I'm paolo pelorsi and I'm a proud member of the micro35 pmp team.

A

This is the third episode of a series of four videos about how to create adaptive card extensions being able to consume a backend multi-tenant api, and in this video we focus on the back-end api implementation.

A

First of all, from a hosting point of view, you can host the back-end api in an azure function, app which is generally speaking, easier and better than hosting the solution in asp.net core api website on azure, because you can leverage the consumption mode of function, apps, which scales really well and cost less than a hosted web application.

A

From a multi-tenancy requirement. Point of view, you will have to configure your api to support custom permission scopes and you will have to implement your own custom logic for authentication and automatization from a technical implementation point of view. You will leverage the penance injection inside the function app as well as you will rely on the max.identity.web package in order to have an easy authentication for access tokens that you will get in your functionapp requests.

A

Last but not least, we can use the preview capability of function filters to check the permission scopes in request that we will get on the api side. So let me move to the demo environment and let me show you the actual implementation of a sample, multi-tenant backhand api for adaptive card extensions.

A

So here we have the visual studio solution for the backend api, which is implemented as an azure function and, first of all, let's have a look to the packages that we are referencing in this solution and specifically to the microsoft.identityweb and the max.net.sdk.

A

Functions and the azure function extensions one. Then this is a function app configured to use dependence, injection and as such in the startup.cs file.

A

We define this to be the function startup and we have the configure method where we configure the authentication using the add authentication core method targeting the service collection right here in the service builder, we specify that we want to configure authentication using the jwt better token authentication, because we are going to use open authorization and access tokens released by azure active directory to authenticate and authorize the consumptions of our api, and then we also say that we want to add microsoft, identity, web api authentication to our solution, and by doing that, we also specify the configuration to rely on which would be the configuration of the azure function in the published function on azure and right now in my local solution will be the local dot set into json file, where I specified the instance of azure active directory that I want to use, which is the general one.

A

The idea of the tenant, where I registered the multi-tenant application the client id of the application that I registered as a multi-tenant app and the audience which will be the unique uri of the application that I will register image ready and all of these topics will be covered in much more detail in the next episode number four.

A

Then we also configure still in the startup cs, that from a jwt, better options, we want to have the issuer, validation and right now, for the sake of simplicity.

A

We validate every issue, but in a real scenario, you should have a table of trusted tenants that you want your solution to be provided to so, for example, if you sell a solution as a multi-tenant api, most likely, you will have a list of all of the tenants who have a subscription a valid subscription to consume your api, and when you will get a token issued by any uh tenant you will have to validate if that tenant. That issuer is in the list of customers with an active subscription.

A

Again just for the sake of simplicity. Here we simply reply with the same issue that we've got to say that every subscription will be good. Every issue will be good, then we have the actual functions in the function app, and here we have an orders function class where we define all of the functions which will become actions provided by the api. For example, the get orders one is a function in get orders which will be available as a get with the orders root and inside that one.

A

We simply get the orders for the current user, using some plumbing logic inside the function, to generate a random list of orders for the currently consuming user. What is important right now is this attribute function, authorize, which is a custom one that I created, and you can see there is a message. It is not really deprecated, but it is just because it relies on a functionality which is still under preview, and as such we have to see these.

A

This highlighted information. Now we declare here with this attribute that, in order to consume the get orders method, we can either have the orders that read permission, scope or the orders dot. Full control permission, scope in the access token provided to the api when consuming it, and thanks to this attribute the function authorized attribute, which relies on the function filters functionality which is still under preview.

A

I can say that whenever we execute a request, so on executing async, I'm overriding this method from the base class and I can say okay, first of all, let's try to get the context. The http context of the request.

A

Once I've got it, let me first of all authenticate the access token that will be injected in the request in the authorization header of the request, and I rely on the microsoft.identityweb package to do that, so that I will simply make this method call and the validation will happen under the cover based on the configuration settings that I defined right here, then, once I've validated a successful request from a valid access token, I can get in the context the user, which will impersonate the user defining the access token that I will receive, and I can search for these scopes.

A

If I have scopes configured in my attribute and if I have a valid identity for a claim identity in the claims principle of the current request, I can search for the scope claim so for the permission scopes defined in the access token, and if there is any of the required permissions like, for example, in this scenario or does not read or orders dot full control. Well, we can authorize the access to the request. Otherwise, we will say that this is not a valid request.

A

It is an unauthorized request and if it is an unauthorized one, we will simply reply back with a 403 http status, meaning that the access is forbidden so again, really simple and easy from a function. Point of view. You simply rely on the attribute and you configure in the startup, with dependence injection all the authentication pipeline to have open authorization in place.

A

Here you can find a list of useful resources like, for example, the source code of the pmp contoso orders, end-to-end reference solution that we are using in this series of videos, as well as an overview of viva connection sensibility and a tutorial about how to build your first sharepoint adaptive card extension.

A

That's it thank you for watching this video and, let's see you in the final episode of this series,.