Microsoft Graph

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of this topic with the link here. This article continues to elaborate on the best practices in working with the Microsoft Graph.

Microsoft Graph enables integration with the best of Microsoft 365, Windows 10 and Enterprise mobility and security services in Microsoft 365, using REST APIs and client libraries. It uses the concepts of users and groups to elaborate on these functionalities.

A user is an individual who uses Microsoft 365 cloud services. Throughout Microsoft Graph, it is the focal point of whose identity is protected and access is well managed. It is the data associated with this entity and the opportunities to enrich the context, provide real-time information, and deep insights that make the Microsoft Graph so popular. The services supporting this entity are the Azure AD and most productivity, collaboration intelligence, and education services.

A group is the fundamental entity that lets users collaborate and integrate with other services which enable scenarios for task planning, teamwork, education and more.

The Graph Explorer helps to know the API and is the easiest way to start experimenting with the data available. Proper REST requests can be made and the responses are representative of those encountered programmatically which eliminates surprises and errors during implementation.

Authentication for Microsoft Graph is made easier using the Microsoft Authentication Library API, MSAL which acquires an access token.

The best practices for consent and authorization involve the following:

-          Using least privilege so that the APIs are called only with what permission is necessary.

-          Using the correct permission type based on the scenario which is particularly important for delegated permissions. If the code runs without a signed-in user, it can lead to vulnerability.

-          Configuring the application properly for end-user and administrator experiences.

-          Using multi-tenant applications so that the customer have various application and consent controls in different states.

Responses can be large for the requests made to Microsoft Graph. Pagination can help browse the results efficiently.

Handling of expected errors is required from the application using the Microsoft Graph for robustness and user-convenience. Certain errors are retriable while others need to be translated to the user.

Adding members to existing enumerations can break applications. Evolvable enumerations provide a better alternative. They have a common sentinel member called the unknownFutureVaue that demarcates known members that have been defined in the enum initially and unknown members that are added subsequently or will be defined in the future. Members of evolvable enums can be references by their string values.

These are some of the considerations towards the best practice in working with Microsoft Graph.

 

Microsoft Graph

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of this topic with the link here. This article continues to elaborate on the services and features in the Microsoft Graph.

Microsoft Graph enables integration with the best of Microsoft 365, Windows 10 and Enterprise mobility and security services in Microsoft 365, using REST APIs and client libraries. We use the concepts of users and groups to elaborate on these functionalities.

A user is an individual who uses Microsoft 365 cloud services. Throughout Microsoft Graph, it is the focal point of whose identity is protected and access is well managed. It is the data associated with this entity and the opportunities to enrich the context, provide real-time information, and deep insights that make the Microsoft Graph so popular. The services supporting this entity are the Azure AD and most productivity, collaboration intelligence, and education services.

A group is the fundamental entity that lets users collaborate and integrate with other services which enable scenarios for task planning, teamwork, education and more.

The services included in the Microsoft 365 portfolio are:

1.       Identity and Access Management service supported by Azure AD which creates and manages directory resources.

2.       Calendar which is managed by Outlook that is used to setup appointments and meetings.

3.       Files which are used to manage and share on OneDrive and SharePoint

4.       Mail supported by Outlook which helps users communicate, organize messages

5.       Notes supported by OneNote which lets users plan and organize ideas and information

6.       Contacts manager on the web, mobile, and desktop devices.

7.       Workbooks and charts which let users use Excel spreadsheets to do complex calculations, track analyze and generate reports

8.       To-Do tasks which let users manage their personal tasks across work and life. It is integrated with Outlook, Teams, Planner and Cortana.

9.       Cloud communications supported by Teams and Skype which lets apps and services interact with users

10.   Sites and lists which are web-based platform for users and Microsoft 365 groups to share, organize, manage, and discover content

11.   Tasks and Plans which enable users in Microsoft 365 groups to create plans and track progress

12.   Teamwork supported by Microsoft Teams which enables hub-and-chat based workspace for teams to share files, notes, calendar, and plans.

13.   People supported by Azure AD, Outlook, SharePoint and more to get information about persons as ordered by their relevance to a user.

14.   Profile and Profile Card which provides lightweight mechanism for storing and retrieving information within a tenant

15.   Document insights which use advanced analytics and machine learning techniques

16.   Analytics uses advanced analytics and machine learning techniques to provide insights.

17.   Cloud printing which uses Universal Print API for simple, rich, and secure print service

18.   Corporate management of devices by enrolling, configuring, and managing them

19.   Cloud PC which works with Windows 365 cloud PCs using the Microsoft Graph API

20.   Device Updates which provide control over the approval, scheduling, monitoring, and safeguarding of content delivered from Windows update.

21.   Multi-tenant management which lets managed service providers to remotely manage multiple customer tenants

22.   Service Health and communications which provides access to the health status and message center posts about Microsoft Cloud services.

23.   Usage reports which use Microsoft Teams, OneDrive, Outlook, SharePoint, Skype for business and Yammer.

24.   Security integration which provides a unified gateway to security insights and actions across Microsoft and ecosystem partners.

25.   Cross device experiences which enable application experience that go beyond a single device

26.   User notifications which enable cross-platform notification experiences

27.   Reports which enable activity and usage-information of a supporting service

28.   Education which provides information relevant for education scenarios, including schools, classes, students, teachers, and assignment information

29.   Customer booking which targets organizations to enable their users and customers to book services directly

30.   Financials which enable management of financial data, automation and securing of the supply chain, sales management and improved customer service.

 

Microsoft Graph

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of this topic with the link here. This article continues the developer experience before talking about the operations.

Microsoft Graph (aka MSGraph) provides rich context for applications such as who are out of office, what documents they have been working on, etc. It provides deep insights generated from usage patterns, such as trending documents, best team meeting times, or who people typically work with. It provides real-time updates which helps to respond to changes in the data such as to reschedule a meeting based on responses, notify others when a file is modified, or continue a process after it has been approved. It builds solutions that target enterprise users in Azure and Microsoft 365, consumers in Office online or both.

The Graph Growth and telemetry landing page is a central hub for telemetry on Microsoft Graph. It provides a centralized dashboard to view the data.

Authentication and authorization are simplified with MS Graph.  There is a single authentication protocol and a single resource. Clients need to manage just one token, one sign-in and a single set of permissions scopes to consent.  Each of the data access to dedicated stores behind the MSGraph uses a separate identity. Workloads don’t share identity. Once the authentication and authorization complete at the entry point of the MS Graph APIs, the resolved user, application and permission scopes are passed around to the data stores accessed. The On-behalf-of flow in Oauth2 is leveraged for this purpose. The access token is not passed directly to the stores behind the MSGraph to avoid token replay attack. The Protected Forwarded Token pattern applies to Azure Active Directory and MSA accounts as well.

The MSGraph APIs can be improved for better customer satisfaction with the following strategies:

1.       Separate out the high data volume services as premium services

2.       Separate out the high data volume with added value as high-speed lanes

3.       Use the marketplace for ISV solutions.

4.       The monetization occurs with Azure Consumed Revenue where the revenue is associated with usage of Azure metered and suite services.

5.       The APIs must be written such that it satisfies the customer’s need for automation, integration and reporting

6.       It should help the ISV partners to integrate for success

7.       It should support backend scale up and out for a needed backend reliability.

8.       It should provide modern authentication aligned with Azure AD.

9.       It should support testability for its functionalities.

10.   Admin and end-user's persona can be separated

11.   The API usage must be seamless across backend data access.

 

Microsoft Graph: 

This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on cloud protection. This article describes Microsoft Graph.

 

Microsoft Graph provides a unified programmability model and similar in its utility as a Kusto cluster and database. The Microsoft Graph model allows Microsoft Graph Connectors to access data from different data sources and provides a common way to query the data. It is the gateway to data and intelligence in Microsoft 365. It can also act as a source for downstream Azure data stores that require data to be delivered. The Microsoft Graph Data Connect provides a set of tools to streamline secure and scalable delivery of Microsoft Graph Data.

 

The emphasis is on heterogeneity of data in the form of files, messages, meetings, user, people, devices, groups, calendar, coworkers, insights, chats, teams, and tasks. The unified programming access it provides can access data in and across Microsoft services including the Cloud, the hybrid cloud and the third-party cloud. A thin aggregation layer is used to route incoming requests to their corresponding destination services. This pattern of data virtualization is not uncommon, but the collection of data and the unified model provides an incredible opportunity for developers.

There are three challenges that Microsoft Graph aims to solve. These are:

1.       The inability to write an application agnostic of any given environment – previous endpoints were defined per user/per-tenant and resulted in applications that had to be rebuilt for each customer.

2.       The absence of a unified authentication/authorization model for all Office users requiring developers to build applications to serve different populations.

3.       The inconsistency in the format of the data returned that causes difficulty in correlating data across the workloads.

 

When the programmability model is unified, the cycle of api development involving the steps to think about the scenarios in which the API will be consumed, design the API to meet those scenarios, design and implement authentication and authorization, publish the API in beta form, publish the API documentation, publish SDKs and support the community, become faster. The developers find that they can allow the users of their applications to use a single token to access data across all workloads, use an end-to-end environment with resources such as sample queries, sample data and tools such as Graph Explorer, and explore REST APIs or SDKs to access the platform endpoints to build the applications on Graph.

 

 

 

 

Microsoft Graph: 

This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on cloud protection. This article describes Microsoft Graph.

 

Microsoft Graph provides a unified programmability model and similar in its utility as a Kusto cluster and database. The Microsoft Graph model allows Microsoft Graph Connectors to access data from different data sources and provides a common way to query the data. It is the gateway to data and intelligence in Microsoft 365. It can also act as a source for downstream Azure data stores that require data to be delivered. The Microsoft Graph Data Connect provides a set of tools to streamline secure and scalable delivery of Microsoft Graph Data.

There is a single endpoint https://graph.microsoft.com, to provide access to rich, people-centric data and insights in the Microsoft cloud. REST APIs and SDKs can be used to access the endpoint, and this powers the applications that support Microsoft 365 scenarios that span productivity, collaboration, education, people, and workplace intelligence. It includes services that manage user and device identity, access, compliance, security and helps protect organizations from data leakage or loss.

The Microsoft Graph exposes data from Microsoft 365 services, Enterprise Mobility and Security Services, Windows 10 services and Dynamics 365 Business Central. Microsoft 365 core services include Bookings, Calendar, Delve, Excel compliance eDiscovery, Search, OneDrive, OneNote, Planner, SharePoint, Teams, To Do, and Workplace analytics. The Enterprise Mobility and Security Services include Advanced Threat Analytics, Advanced Threat Protection, Azure Active Directory, Identity Manager, and Intune. Windows 10 services include activities, devices, notifications, and Universal Print. The Dynamics365 Business Central has its own data ecosystem.

The primary use case for Microsoft Graph is to open the Microsoft 365 platform for developers. The graph-explorer helps query and view this data

Data Connect and Graph APIs provide access to the same underlying data but in different ways. Data Connect works with bulk data so that extracting and moving large amounts of data is easy.  Microsoft Graph APIs are more suitable for accessing discrete sets of data in real time. So if we want to get all of last year’s emails, then we would run Data Connect but rely on Graph APIs to get specific emails.

Data Connect involves some setup and overhead before the bulk operations on data. This can be about 45 minutes regardless of the data and all pipelines will take at least that long. It might be a negligible cost for large amounts of data but using it for something lightweight is not recommended and the Graph APIs are more suitable for that.

The billing for Graph APIs is on a pay-as-you-go basis and the billing unit is multiples of 1000s of objects, where 1 object maps to 1 individual instance of an entity in Microsoft 365 such as an email, file, or message. There are no charges to use User, MailboxSettings, Manager, and DirectReport.

Service principals are required for Microsoft Graph Data Connect which uses it as an identity for getting authorized access to Microsoft 365 data. Before data connect can copy data, an administrator must approve a Privileged Access Management Request. Either all the users in the user list must have Workplace Analytics license or all those users must not have it. There is no mixed mode user list for Data Connect users.

 

Azure ARM Resource provisioning with secrets:

Introduction: Secrets are passwords, certificates, symmetric keys, managed service identities and other such closely guarded and sensitive information that must be both generated and renewed for accessing resources services on Azure. One of the requirements for using a secret store is the automation of these routines. Some secrets must be deployed with their own resources. For example, virtual machines and virtual machine scale sets can be designated with the use of certain secrets. Similarly, storage accounts can also be provisioned with the use of secrets that can be requested over encrypted web traffic. These must be deployed as part of PaaS V2 offering for these scenarios. PaasV2 is a term denoted for managed applications involving infrastructure such as – Virtual Machines, Virtual Machine Scale Sets (VMSS), Service Fabric, Elastic-AP, Azure Container Service etc. Integration of the secret management routines with the Compute Resource Provider is necessary to enable this PaaS integration. A use case for using secrets with compute is when a PAAS deployment requires VMSS to span one or more fabric controllers with each fabric controller managing a fabric tenant. Secrets are serviced by a service that is available regionally for such use case.

The workflow involves an application deployment using ARM Templates which in turn creates VMs and VMSS using a regional Compute resource provider that relies on say Fabric controllers. The regional secret provider service will push to the fabrics secret cache which improves the scale up/down of resources without relying on the service providing the secrets. Once the resources are created, they can individually poll for updates to their secrets using the endpoint for the service that generates and renews the secrets.

The following components are involved to implement this workflow.

• A configurations layer which provides the implementation for registered features usage. Usage of the secrets provided by the secret management service is supported for subscriptions that have been registered with a specified feature flag. Customers must use approval workflow to register their subscriptions with this feature flag.

• VM & VMSS controllers: which implement the various APIs that are invoked by ARM. The VM/VMSS validations also happen in this layer.  The provisioning of resources with secrets must conform to the provisioning of regular resources. Just their ARM Templates will be different because they will have the reference to the provisioning of a secret. Deployments can be parallelized across locations.

• State reconciliation that creates the async operations and persists the goal state for a given definition of VM/VMSS involving the secrets.

• The state reconciliation might involve both a composition of states such as for the VM pipeline and VMSSS pipeline. Each pipeline is further sub divided into multiple blocks responsible for driving the pipeline to its desired state. Blocks can be executed in parallel and when required to be synchronized. A state reconciliation will require a state seeking engine that implements a graph traversal and state machine workflow.

 

 

 Sovereign clouds continued… 

This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on sovereign clouds. This article talks about Azure AD authentication in National clouds.  

National clouds are physically isolated instances of Azure. The difference between Commercial, GCC and GCC High Microsoft 365 environments is important to correctly align the compliance needs of the businesses. Commercial Microsoft 365 is the standard Microsoft 365 cloud used by Enterprise, Academia and even home Office 365 tenants. It has the most features and tools, global availability, and lowest prices. Since it’s the default choice between the clouds, everyone qualifies and there are no validations. Some security and compliance requirements can be met here using tools like Enterprise Mobility and Security, Intune, Compliance Center, Cloud App Security, Azure Information Protection, and the Advanced Threat Protection tools. Some compliance frameworks can also reside in the commercial cloud, and these include HIPAA, NIST 800-53, PCI-CSS, GDPR, CCPA etc. but not government or defense compliance because the cloud shares a global infrastructure and workforce. Even some FedRAMP government compliance can be met in the commercial cloud, but it will be heavily augmented with existing tools and will require finding and patching gaps. 

Each cloud instance is separate from the others and has its own environment and endpoints. Cloud specific endpoints include OAuth 2.0 endpoints, OpenID Connect token request endpoints and URLs for app management and deployment which means an entire identity framework is local to the cloud instance. There’s even a separate Azure portal for each national cloud instance.

Applications can continue to use modern authentication in Azure Government cloud but not GCC High. The identity authority can be Azure AD Public and Azure AD Government.  

Applications can integrate with the Microsoft identity platform in a national cloud but they are required to register their application separately in each Azure portal that’s specific to the environment.

The workflow for authentication is claims based. A claims challenge is the response sent from an API indicating that an access token sent by a client application has insufficient claims. It could be due to one of many reasons such as conditional access policies not met for the API or the access token has been revoked. A claims request is made by the client application to request the user back to the identity provider to retrieve a new token with claims that will satisfy the additional requirements that were not met. Applications must declare the client capabilities in their calls to the service. Then they can use enhanced security features and must be able to handle claim challenges. This is usually presented via a www-authenticate header returned by the service API.

The MSAL library provides the following sample to communicate the client capabilities:

_clientApp = PublicClientApplicationBuilder.Create(App.ClientId)

 .WithDefaultRedirectUri()

 .WithAuthority(authority)

 .WithClientCapabilities(new [] {"cp1"})

 .Build();

 An API implementer can receive information about whether client applications can handle claim challenges using the xms_cc optional claim in the application manifest.