Microsoft Graph Api V2.0

[Jovanna Ponder]

Asper this announcement made on Feb 2021, Microsoft graph now provides option to have granular permissions level using Sites.Selected application permission for the AD application instead of granting permission for all the sites in the tenant. The permission Sites.Selected does not provide access to any SharePoint site collections for the application unless the AD application has been assigned with permission roles read or write by an Admin. On this post let us see how to grant a site permission (Read or Write) to an AD Application with Sites.Selected permission by using postman client. As of the time I am writing this post there is no user interface to assign permissions to specific site collections for the application.

This step is grant permission for the Azure AD application with Sites.Selected application permission to a given site collection. Perform the following steps to grant the role (Read/Write or Read and Write) to the AD app (APP 1)

There is a PnP PowerShell cmdlet to grant access to SharePoint site for the registered AD application with Sites.Selected permission. The command to grant permission can be executed by the Site Collection administrator after creating a connection to the site

If there is any error related to permissions, make sure the admin consents to Sites.FullControl.All for the Graph tool. There is also an SPFx community webpart developed by a community member with User Interface for this operation

On this post we have seen how to grant access to Azure AD which has the Sites.Selected permission. You can also grant permission/role to an app with sites.selected permission programmatically. If you are using SharePoint API instead of Graph API in the Azure AD app registration, Sites.Selected is available on Application Permission as shown below

Hey David! Thanks for reading the post, yes it a much sought after feature. As far as I have tested, it has few issues when comes downloading files from SharePoint libraries. These issues has been brought to Microsoft product teams attention. I recommend you to wait until it is generally available. Please do take a look at the roadmap for this feature

-us/microsoft-365/roadmap?filters=&searchterms=Sites.selected

Agreed. I did raise a support request couple of months back, after investigation they have closed the request stating that the feature is still in development & the issue has been brought to product teams attention. The only channel available is the Road Map link or by contacting Microsoft support Team.

Thank you for this informative article. Permission from Postman/Powershell is not getting applied to site after successfully running above instruction. Is there any issue at microsoft end with APIs/commands?

If you work in the Microsoft ecosystem, it's hard to ignore something as big as Microsoft Graph. Imagine that you're new to the Microsoft ecosystem and your boss just attended a Microsoft conference, and everyone's talking about Microsoft Graph, as they often are. Your boss feels that your product must integrate with Microsoft Graph because apparently, it'll help people and organizations get more done. That can't be a bad thing, right? It's your job now, as a developer/architect, to figure out this amazing technology called Microsoft Graph. This is where you start hitting the search engines trying to educate yourself.

I guess that's nice. It's a developer platform, I'm a developer, I'm on some kind of platform, like maybe Java or C#. I'm not 100% sure yet what this means, but I'm intrigued. I narrow my search to Microsoft docs.

"Microsoft Graph is the gateway to data and intelligence in Microsoft 365. It provides a unified programmability model that you can use to access the tremendous amount of data in Microsoft 365, Windows 10, and Enterprise Mobility + Security. Use the wealth of data inMicrosoft Graphto build apps for organizations and consumers that interact with millions of users."

Wow, so this is a developer platform, and a gateway to data and intelligence. As a developer, the line about the unified programmability model makes some sense. But I'm not sure if I want to interact with millions of users. I think I'll need to read up on what this Microsoft 365 thing is that they're talking about. I've heard of Office 365. Did they rename it? More search bingeing is in order.

Gosh! We seem to have a department of confusing documentation at work here. Just tell me already what Graph is and how I integrate with it. I figure that you're just as frustrated, so I wrote this article. If you've never heard of Microsoft Graph, and your boss has the sudden urge to use it, what does it mean to you, the developer?

Before I go much further, I have no doubt that no matter what words I pick to describe Microsoft Graph, someone is going to poke holes into my wordsmithing capabilities. That's okay, this is how I understand Graph. But wait a second! Before I explain what Microsoft Graph is, you need to know what Azure AD and the Microsoft identity platform are. Let's take a short detour into Azure Active Directory and the Microsoft identity platform first.

Azure Active Directory (Azure AD) is a cloud-based identity and access management service. The Microsoft identity platform is an ecosystem that's a superset of Azure AD. When you log into Office 365, you're logging into Azure AD. When you log into Microsoft Teams, you're logging into Azure AD. Given how flexible and extensible Azure AD is, there are many variants of the user experience that the end user may see. Some may be on iOS. Some are in the browser. Some are federated to ADFS (Active Directory Federation Services). Some use SAML, some use OpenID Connect. Modern authentication, which is another ill-defined umbrella term, is quite flexible. Azure AD is Microsoft's flavor of modern authentication and so much more.

Now back to Microsoft Graph. Microsoft Graph is a bunch of programmable features that are protected by the Microsoft identity platform and are accessible from any platform. And when I say a bunch of programmable features, it's mainly three: APIs, connectors, and Data Connect.

These APIs are all protected by the Microsoft identity platform. Let me really simplify this for you: If you've ever called an OpenID Connect-protected API, calling a Microsoft Graph API is exactly the same. In fact, with the SDKs that Microsoft provides, it's even easier. And by SDKs, I mean not just the SDKs that allow you to authenticate to any Azure AD-protected endpoint, such as MSAL, but there are also MS Graph SDKs that really eliminate the friction for you.

Microsoft Graph connectors are how your non-Microsoft systems provide data to the Microsoft cloud. There are a lot of connectors available for Microsoft Graph, as can be seen here -us/microsoftsearch/connectors-gallery. These connectors make it possible for all those data sources to input data into the Microsoft cloud, and make it available for services such as Microsoft Search. As an example, there's a connector available for MSSQL. This means that Microsoft search can now make MSSQL searchable. How neat is that?

These APIs and connectors are great. But as an organization invested in the Microsoft ecosystem, your lifeline - your data - is sitting in the cloud. You can call a bunch of APIs, but sometimes you need lots of data to do further insightful work. Maybe you're trying to write an AI model that analyzes your user's emails, for instance.

You can imagine that calling API after API under the users' delegated permission can get cumbersome very quickly. In fact, it's not going to scale at all. It's precisely to get around this problem that Microsoft Graph Data Connect exists. It allows you to work with the data in popular Azure datastores, such as Azure Data Lake or Azure Blob storage. You can then analyze that data using Azure Data Lake analytics or Azure SQL database, and really your imagination is the limit at that point.

My point is that in the back of your mind, you might be thinking that for bulk data processing, there must be some kind of controls built inside of Microsoft Graph Data Connect. After all, you don't want anybody reading just anybody's email; you want some controls on this ecosystem. Random access would entirely defeat the purpose of consent. You'll be glad to know that Microsoft Graph Data Connect has a lot of controls built in so an administrator can set up various rules, and exceptions that define exactly what data is exposed when using Microsoft Graph Data Connect.

A very large and key part of Microsoft Graph are the APIs that it exposes. These APIs are protected by the Microsoft identity platform. To understand how you call these APIs, you must have a basic understanding of how APIs work in the Microsoft identity platform.

These APIs are accessible using standard OpenID Connect mechanisms. This means that in order to access this API, you have to pass in an access token. The access token is a string you pass into the Authorization header in your HTTP request to the API. It typically has a whole bunch of information, such as the validity, who it was issued to, a signature, and much more.

Reading all users' emails is something that a background process, such as a daemon or a CRON job, would do. Here, the user's identity isn't important, but the application's identity is important. However, if I say that I wish to read the logged-in users' emails, I must know who the logged in users are.

Before I move off the topic of permissions, there's one more important thing for you to know, and that's the concept of effective permissions. As the name suggests, effective permissions are the permissions that your app has when it makes a request to an API. But there's a key difference in how effective permissions work in delegated permissions and application permissions.

For delegated permissions, the effective permissions of your app are the least privileged intersection of the delegated permissions that the app has been granted by consent and of the privileges of the currently signed in user. In other words, your app when using delegated permissions will never have more privileges than the signed in user.

3a8082e126