I am developing a office add-in.
This office Add-In is supposed to retrieve the term store from SharePoint.
By following this tutorial:
https://learn.microsoft.com/en-us/office/dev/add-ins/develop/create-sso-office-add-ins-aspnet
I managed to get an access token to be used for Graph api. However the Graph does not expose any way of getting the term store. Is there a way we can generate an access token to be used with SharePoint and maintain the SSO?
It might be possible by registering an Azure AD v1 app but I could not find any documentation describing that.
I have a similar requirement, but in my research I wasn't able to find a good solution for this scenario.
I think it is probably possible to use a provider hosted SharePoint add-in. And then use the Authorization Code flow for obtaining an access token. Since the SharePoint add-in is trusted it will not require user login.
Of course this does mean the add-in needs to be deployed in SharePoint. If your Office add-in is distributed through the store this isn't really a great solution.
Hopefully there are other ways of achieving the same.
You could call SharePoint Online APIs (via REST or CSOM) with Azure Active Directory Apps. To call APIs secured by Azure AD, your app must acquire an access token from Azure Active Directory.
Please first refer to this document for integrating applications with Azure Active Directory. Then use Azure Active Directory Authentication Library (ADAL) to easily authenticate users to cloud or on-premises Active Directory (AD), and obtain access tokens for securing API calls.
Related
For my current ASP.NET Core MVC application I authenticate directly with a web app registered in Azure AD Portal. This provides me with an access token so on the backend of my web application I can use MS Graph with my users specific account (ie add files to their onedrive , email, etc). However, my organization also has Okta which a lot of applications authenticate against. So I was trying to determine to authenticate through Okta (which has a much cleaner sign in process IMO) as well as authenticate against Azure AD and get an access token. Through my research I found something in my web application registration in Azure AD called Workload Identity Federation. This led me to this useful video
https://www.youtube.com/watch?v=wZ0gCJYMUKI
and also microsofts info site:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation
This seems to answer what I want which is to use Okta but allow me to still use MS Graph for my users since it will authenticate against Azure AD (correct me if I am wrong and this is for something else). My issue is none of these resources really go into depth regarding how the access token is passed to my application so I can use MS Graph. My research this is called client credential flow since my application only has delegated permissions so it requires the users to log in and it basically allows my web app to act on their behalf when using MS Graph. So I am trying to understand and fill this void of information regarding how client credential flow fits into Workload Identity Federation and is this the solution to my problem.
I'm confused about the guideline I have to follow to embed some Power BI reports in a react app. I've been reading this documentation but I don't understand why I need an Azure AD app. By now I've created four Power BI reports and I've published them to the web (making them public and accessible for everyone). So, I've got four PBI links to access them. But I want to create a web app (probably with React) to embed them all in one link.
I understand that Azure covers authentication features, but my app will only show information, doesn't need users to log in or something. So, I guess Azure helps to authenticate to the PBI account I'm using. But if this is the case, why PBI doesn't ask me for authentication when I share the reports links with anyone?
Thank you in advance!
You need Azure AD app to have identity for your application, to authenticate to Azure AD (using MSAL for example) and for using the Power BI REST APIs. Check the following article: https://learn.microsoft.com/en-us/power-bi/developer/embedded/register-app
Since you are already logged in you don't need to login to PowerBi again, There are two ways to embed your PowerBI reports,
Publish to web -> Does not require authentication (Public reports)
Embed with authentication -> Hyperlink and token based ( Requires Azure AD)
You can check more information here
I'm following a guide online to generate an access token to access Microsoft Dynamics 365 Customer Engagement: https://eax360.com/dynamics-365-online-connect-using-postman/.
All of it works fine, however I am wondering why delegated Admin permissions need to be supplied in Azure Active directory during app registration. I have seen a lot of guides explain that permissions must be delegated but the above site documents the process well. As a general rule, I thought that starting with the lowest security permissions was the norm. I am new to Azure AD so thoughts are very much welcome.
If your app will be a client which allows the authenticated user to perform operations, you must configure the application to have the Access Dynamics 365 as organization users delegated permission.
Application permission means that you want your app to access Common Data Service without a user.
So whether to use delegated permission in Azure app registration depends on your needs. It is not mandatory.
But we can see that the Application permissions in Azure app registration is gray out. This is because Microsoft provides a different way to implement it.
We need to create a Common Data Service application user an then bound it to the registered app. After that, we could connect using the application secret. See the details here: Connect as an app.
I'm building a service where each user has a calendar, I want to sync users 365 calendar events into their calendar, the tricky part seems to be, that this should be done repeatable by background job on the server, to keep them in sync.
I feel like I've read a bible of documentation from Microsoft, but still gotten nowhere. I eventually stumbled upon this article https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds which allows a server to query the graph api, on behalf of users. This is exactly what I want.
Having created a Azure account, and Active Directory service, I found that only users within the tenant can use this, which makes it rather useless, requiring to add users manually from azure panel.
AADSTS50020: User account 'm#****.com' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application 'c0193dea-5145-430a-9c90-325f1229a1fc' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
So I'm back at square one, how can I achieve what I described?
I'm not looking for a code implementation, merely a description of how to navigate the monstrosity of Microsoft.
Thank you
Update: Accordingly to Marc link. I tried to flick the multi tenant option, and change the endpoint to use common instead of tenant id. Sadly i'm still getting the same error.
You cannot sign-in to AAD with a non-AAD account using the v1 Endpoint. If you want to use a consumer Microsoft Account (#outlook.com, #hotmail.com, #live.com) then you need to use the Converged Auth model provided by the v2 Endpoint.
I have a walkthrough for the v2 Endpoint that you might find helpful: Microsoft v2 Endpoint Primer. It is similar to the v1 Endpoint but you'll need to register via https://apps.dev.microsoft.com rather than the Azure Portal. Also, v2 apps use Scopes instead of Resources and are multi-tenant out of the box.
This is a broad a question for Stack Overflow. That said, you're incorrect about Azure AD. It is absolutely not limited to a single-tenant. You do however need to register it as a multi-tenant application:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
We've been running an Angular app in a custom masterpage during the last year, using the Sharepoint REST api to retrieve user properties, data from lists etc., which has been working fine. As the application is hosted on Sharepoint Online, accessing the page requires a login thus making the request digest available so further authentication is not necessary.
Now however, we want to start using some of the functionality in the Microsoft Graph API. From what I can gather this requires OAuth2 authentication against the Azure Active Directory, involving among other things a redirect to the AAD login page.
Does this mean I have to:
1) Login via the organizations (standard Microsoft) login page to access the Sharepoint Online site.
2) Redirect to the Azure AD login page and back again?
Or can I leverage the login that the user already did when logging into Sharepoint Online?
Sorry if the question is a bit vague, we are all still very new to this.
When registering your application on Azure AD you will give the app access to Files/Sharepoint REST api and Microsoft Graph API. See this picture the app has access to several apis (Exchange, Graph and AD) you must add sharepoint APIs in your case.
Regarding the authentication, I am afraid that the Sharepoint model does not provide a token that will enable you to request the Graph API see this. You will have two authentications, one to access the Sharepoint site, as you said, and the other "within" the sharepoint iframed add-in to log into your AAD's registered app. This will be an OAUTH process through login.microsoft.com. Have a look at my Outlook add-in Keluro Mail Team on the Office store, I think it is similar to what you want to achieve.
You can use the same token from graph.microsoft.com. I have a sample using Asp.Net Core 1.0 and the.Net ADAL but the same authentication flow is used when using ASP.NET 4.6. Just make your auth request against ms graph on startup then acquire access token to auth against SharePoint.
https://github.com/edrohler/com.ericrohler
Hope this helps.