Introduction
Note : With this blogpost approach, You no need to Add Azure AD as Identity Provider in the
SAP BTP, Cloud Foundry environment account i.e Integrate Microsoft Azure AD with SAP BTP, Cloud Foundry environment
This blog post covers Usecase how easily( i.e with very less development effort) &
efficiently Interact with Windows 10, and Enterprise Mobility and Security services in
Microsoft 365 products using
Microsoft Graph in your business application running
SAP Business technlogy Platform (BTP) in scenario
without immediate interaction with a user i.e call Microsoft Graph with not on behalf of a user , this Blog post approach you use , when user authorization not required to access resources i.e it is like a technical user/service user approach without the presence of a signed-in user. These types of applications are often referred to as
daemons or service accounts. These apps call Microsoft Graph with their own identity and not on behalf of a user. In many cases, these are background services or daemons that run on a server without the presence of a signed-in user. With this blogpost approach we can avoid lot of Boilerplate code Integration of
MS Azure &
SAP Business technlogy Platform (BTP) to get an authentication token from Azure AD using the OAuth 2.0
client credentials grant flow
Your business application has requirements like sending acknowledge/confirmation email, monitor an application anonymous mailbox, Creating/Updating a calendar event, creating an teams ,MS-Teams online meeting , an email service runs overnight, your company migrated all users to Office 365 (Microsoft 365)
The preferred (new) way for interacting with Microsoft 365 programmatically is by using the
Microsoft Graph
You can read here news about deprecation of older techniques(
https://developer.microsoft.com/en-us/graph/blogs/upcoming-changes-to-exchange-web-services-ews-api-...
Microsoft Graph enables you to integrate & interact with the best of Microsoft 365 products, Windows 10, and Enterprise Mobility and Security services in Microsoft 365, using REST APIs and client libraries.
Microsoft Graph exposes
REST APIs and client libraries to access data on the following Microsoft cloud services:
- Microsoft 365 core services: Bookings, Calendar, Delve, Excel, Microsoft 365 compliance eDiscovery, Microsoft Search, OneDrive, OneNote, Outlook/Exchange, People (Outlook contacts), Planner, SharePoint, Teams, To Do, Workplace Analytics.
- The Microsoft identity platform supports different authentication types based on your business application architectures requirements
You can read
here Microsoft recommendations for these app architectures:
WebApp, Mobile Apps, Desktop Apps, Web Apps, Daemon apps, Server-side apps
https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios
To Get access on behalf of a signed-in user (SSO)
Please follow my other
blogpost
Get access without a user(Technical User)
Tokens can also be acquired by apps running on devices that don't have a browser or are running on the Internet of Things (IoT)
You can read here
Authentication and authorization basics for Microsoft Graph
Follow
Best Practise for consent and authorization in your application:
As a developer, you decide which permissions to request for Microsoft Graph, What is type of application & then request to App in Azure AD .
Usually your organization Azure Admin will take care of creating app & giving scopes are per your application architecture requirements)
Solution – Efficient Approach
1. Azure Admin responsibilities
Ask your organization Azure Account Admin to Register your application & Configure permissions for Microsoft Graph on your application in
Azure portal as mentioned in
https://docs.microsoft.com/en-us/graph/auth-register-app-v2
Generally every company would have one Azure Admin & process defined to take care of App Registration in Azure AD, Configure
Graph API Scopes for your application Usecase so follow your organization process
2. SAP BTP Subaccount Admin/Space Admin responsibilities
SAP BTP provides the
Destination Service, using which your application can reach to any other cloud service or system or SAP S/4HANA Cloud tenant. In our case we are going to use
Destination Service to connect to Microsoft 365 via
Microsoft Graph
Ask your SAP BTP Subaccount Admin /Space Admin to create destination as described in this blog post
Destination:
Screenshot
Your Azure App Configuration details acquired from your Azure Admin (Pre-Requisites-1 )
3. As a Developer
Use the
SAP Cloud SDK which can reduce your effort when developing an application on SAP Business Technology Platform by building on best practices delivered by the SAP Cloud SDK. The
SAP Cloud SDK provides
Java libraries,
JavaScript libraries, project templates, and a continuous delivery toolkit.
SAP Cloud SDK comes with two variants—one for Java and one for JavaScript/Type-Script—and provides libraries, project templates, and a continuous delivery pipeline that you can use immediately.
Dependent on your application architecture choose either
Cloud SDK for Java
Cloud SDK for JavaScript (Node.js)
- With the SAP Cloud SDK, you can get the result in a single line of code by using the Destination Accessor class of the SDK that gives you an instance of the SAP BTP destination service
HttpClient httpClient = HttpClientAccessor.
getHttpClient(DestinationAccessor.
getDestination(connectionName).asHttp());
Here connection Name is Destination Name you can get from your BTP CF Space Admin/Subaccount Admin
- Then to call a Microsoft Graph API resource
Your
resource URL will include the resource you are interacting with in the request, such as me,
user,
group,
drive, and
site & to access additional resources, like me/messages or me/drive,
me/sendMail
HttpDestination destination = DestinationAccessor.
getDestination(connectionName).asHttp();
HttpUriRequest request =
new HttpGet(destination.getUri()+"v1.0/Users/{id}/sendMail");
Advantages
- Reduced lot of Boilerplate code required for Integration
- As code becomes less then less maintenance cost
- Seamless Integration
- Totally Security:
- Allow to change configure in different environments (DEV, QA,PROD) for different SCP accounts without touching your code
- In Built Quality
- Less Total Cost Ownership (TCO) will become less if MS 365 Azure integration is requirement for one more than one application then every application needs to perform manual steps stated in “Manual Approach Section”
- Re-Usability
- Less Technical Debt
- High Scalability
- Note : With this blogpost approach ,you no need to Add Azure AD as Identity Provider in the SAP BTP, Cloud Foundry environment account to Integrate Microsoft Azure AD with SAP BTP, Cloud Foundry environment
In this document I also would like to briefly write about other approach as a Developer we have to take care below Manual Steps. In this Manual approach we have to take care lot of low-level integration & boot strapping.
Manual Approach:
To use Microsoft Graph to read and write resources on behalf of a user, your app must get an access token from the Microsoft identity platform and attach the token to requests that it sends to Microsoft Graph
- POST HTTP Call to https://login.microsoftonline.com (oauth2/v2.0/token) to get an access token
- To achieve Step1 in Java application generally we either use org.springframework.web.client.RestTemplate & store Azure Configuration in Yaml file
- That is, to call an external system, you construct the HTTP request manually by adding the respective headers and security information manually.
- Parse Token Response & read Access Token
- Then to call a Microsoft Graph API Azure you attach the access token as a Bearer token to the Authorization header in an HTTP request
Note: Here as a security best practise we should not hardcoded-url
In general, applications shouldn’t be hardwired to resources (like text files or database systems), but be rather coupled loosely to them. Backing services are the best practice to couple resources to applications running in Cloud Foundry environments. Therefore, SAP encapsulates the necessary business logic and the persistence layer for those tasks and makes it easy to consume as a backing service (Destination service).
Reference : https://blogs.sap.com/2018/10/08/using-the-destination-service-in-the-cloud-foundry-environment/
Or To securely store Azure configuration in Database we must write code to store & retrieve in Database, Similarly if we choose Configuration in Azure Pass vault also we must write code/ With this blog approach we can avoid lot of
Boilerplate code
To use the destination service, you must carry out the following steps:
- Retrieve login credentials from environment variables stored in the destination service.
- Using these login credentials, generate a JSON web token (JWT) through the SAP BTP user account and authentication (UAA). Add this JSON web token to the HTTP request header for authentication.
- Formulate the service endpoint you wish to call and send the HTTP request.
- to call an Microsoft 365 you construct the HTTP request manually by adding the respective headers and security information manually
- you also need to perform all tasks related to the handling of the HTTP request such as building the request URL
- Establishing the connection
- Handling the response and parsing it.
Notes & References:
Microsoft Azure is enterprise cloud platform. Microsoft 365 which is a software as a service (SaaS) product, Microsoft 365 uses Azure Active Directory (Azure AD) to manage user identities behind the scenes. Your Microsoft 365 subscription includes a free Azure AD subscription
- Microsoft 365 for enterprise overview
- Sign up for a Microsoft 365 subscription with your Azure account
Android, Angular,ASP.Net , iOS Swift,Node.js, PHP, Python, React, Ruby, Xamarin
https://developer.microsoft.com/en-us/graph/quick-start
https://docs.microsoft.com/en-us/azure/active-directory/develop/sample-v2-code
Azure-Samples
https://github.com/Azure-Samples?page=3&query=active-directory
Microsoft Graph Samples, SDKs :
- https://developer.microsoft.com/en-us/graph/gallery/?filterBy=Samples,SDKs
- Follow Best Practise for consent and authorization in your application:
- Use the correct permission type based on scenarios. If you're building an interactive application where a signed in user is present, your application should use delegated ermissions, where the application is delegated permission to act as the signed-in user when making calls to Microsoft Graph. If, however, your application runs without a signed-in user, such as a background service or daemon, your application should use application permissions.
Note: Using application permissions for interactive scenarios can put your application at compliance and security risk. It can inadvertently elevate a user's privileges to access data, circumnavigating policies configured by an administrator.
· Using the Destination service in SAP BTP, Cloud Foundry Environment
· Connect to OData Service on Cloud Foundry Using SAP Cloud SDK JAVA
· Get Started with SAP Cloud SDK for JavaScript / TypeScript
· Create Your First Application with SAP Cloud SDK for JavaScript