Accessing Other Tenants Data via Microsoft Graph API [closed] - microsoft-graph-api

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I have an Azure tenant and the Azure portal has partner access to all my clients. My requirement is to fetch contracts of each of my partner using the Microsoft Graph API.
I created an application inside my azure instance following the documentation guide. Am able to obtain an access token using https://login.microsoftonline.com/tenantId/oauth2/token endpoint (where tenant id will be my azure tenant id) for the GraphAPI resource and am able to use the GraphAPI rest calls to fetch the contracts as well as the subscribedSkus of my tenant.
However how can i access the subscribesSkus of my clients?. Do i need the tenant id of each of my clients and obtain the access token for each client using the endpoint mentioned above? Does that means i need to create an app on all of my clients azure active directory instance?
Several references for similar scenarios like this can be found across the internet but there is no concrete documentation available in microsoft which assists me to proceed further.
Any insights into this will be really helpful.

This isn't possible, you need to have credentials and obtain a token for each of the tenants you wish to access.

Related

Azure Active Directory multiple nodejs client as the same client [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am developing an Nodejs application and using AAD to secure an Azure function.
There would multiple Nodejs clients but I don't need to have a single user for each one of them (all the instances are should be treated as the same client).
How should I go about implementing this and is there any security concerns?
Edit
The protected resource is an Azure Function with a HTTP trigger.
I just want to limit the access to people who have the NodeJs client Installed. I don't want the user to enter his credentials. My question is which flow should I use and how should I go about that?
If you do not want to use the user's credentials, then please evaluate the Azure Active Directory v2.0 and the OAuth 2.0 client credentials flow.
This type of grant commonly is used for server-to-server interactions that must run in the background, without immediate interaction with a user.
While this advised solution may not look like an exact fit, you can use the admin consent and make this work for you. There are additional considerations like securing the credentials on each machine that you also have to look at.
in the client credentials flow, permissions are granted directly to the application itself. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action, and not that the user has authorization.
If this looks promising, then also look at the azure-activedirectory-library-for-nodejs to get you going.

How to determine which grant type was used for an access token [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have an API configured in WSO2 API Manager that allows multiple different OAuth 2.0 grant types (client credentials and openid).
My API requires a different behavior depending on whether it was called via an access_token generated by client credentials vs openid. How can the API verify whether this access token provided was generated via client credentials or openid?
Edit and Solution:
I have found a way to do this. The following WSO2 Documentation shows how to configure the API Manager to pass a JWT that includes some token specific information. In that token you will find the "http://wso2.org/claims/usertype" claim. If your api is being accessed via client credentials grant type its value will be APPLICATION if its being accessed via openid or SAML it will be APPLICATION_USER. I haven't found documentation that specifically outlines this scenario but it seems to work.
I don't think there's a direct way of doing this unless you write your own code to get this information from IDN_OAUTH2_ACCESS_TOKEN table.
But using some hacky way you should be able to do this without much effort.
For example,
1) In case of you already knowing the application creator's name (or a userstore domain), you can get the owner of the token as mentioned in this blog post and compare it with the application owner's name. The owner of the tokens which are generated by client-credentials grant type is always the same as the application owner. However this methods has a limitation that you can't differenciate when application owner calls the with API OICD token and client credentials grant type.
2) Enable JWT tokens and then take your decision based on user claims.

Test C# Web API app for Windows Azure locally [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Is there a way where I can develop a Windows Azure locally without having to create a Windows Azure account?
The reason I'm asking is because I am creating a Web API using C# and a frontend technology (I haven't decided which one yet) and I want to use AAD for my authentication using my user's Microsoft account, and want to test it first if my use case is fit for it without having to subscribe to Azure first.
Thanks!
Based on my understanding, there are two things you want to accomplish:
Build/test a WebAPI using C#.
Use AAD to authenticate your users. Your users will sign in using their Microsoft account.
For #1, you really don't need an Azure account. You could simply create a WebApi application using Visual Studio and test it locally. If the intended backend database is SQL Server, then again you can test it locally by installing SQL Express.
For #2, again you don't need to have an Azure account unless your application does something related to Azure (for example, permission to execute Azure Resource Manager API on behalf of the user). If you simply want your users to sign in using their Microsoft account, you could create an application that uses Azure AD v2 endpoint. To create such application, all you need is a Microsoft account for yourself. You can read more about Azure AD v2 here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-appmodel-v2-overview.
You would need some place to host your application once you want folks other than you to test the application. At that time you would need an Azure account if you decide to host this application in Azure.

endpoints common vs tenant id

I am developing a python app running on embedded linux to access office365 calendar via the EWS interface. I plan on using impersonation to access data.
I have registered my app with azure AD and retrieved the endpoints which contain a tenant id. But I have learned that using the common endpoint seems to work just fine in refreshing the access token.
what are the advantages or limitations in using the tenant id instead of just using common?
Take a look at http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/. The common endpoint does late binding to the tenant based on the users login details. The article does add "For line of business applications you do NOT want to late bind the tenant, in fact you want to ensure that the caller comes from your specific tenant and no other! In that case, use of common is not appropriate."

How do I generate public documentation for my Rails 3 REST Service? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
So I'm building an application in Rails 3 using Devise as my authentication mechanism. I have all my controllers and views working. Our web site is humming along. Now we'd like to export our routes to 3rd party developers. The problem is how.
Here's the list of things I think I need to figure out.
Third party authentication. I am trying to get it straight in my head what I need to do. We have an existing user base and tokens have been generated for all of them with the Devise authentication model. Now I need to provide some kind of security. My current line of thinking is to set up an OAuth Provider to manage private keys and then somehow set up our web app as one of the applications the 3rd party developer can gain access to. Is that the correct line of thinking or am I over-engineering it?
Generate public facing documentation for our REST endpoints. While the rake routes is nice for internal developers, I really think we need something more along the lines of swagger-ui. the problem is rails doesn't generate the appropriate json/xml calls for swagger-ui. Which as I understand it are required in a true REST service. Such as resource listing, and operations listing on a resource.
Thanks in advance for any direction you can give me in these arena's!
I'm biased about Swagger (I work on it at Wordnik) and will point out that we'll add ruby server support to automatically generate the description layer like we do with Scala.
I would definitely recommend OAuth if there is a security element for your users. That is, you want someone to be able to edit multiple users details via their service then used 3-legged OAuth (Provider, User, Client). Otherwise go for the 2-legged OAuth (Provider, Client.)
If you want to implement a 3-legged OAuth API then I wrote a tutorial which is available here. It uses Devise and Oauth2.
As for the documentation, I would go as far as to write custom documentation instead of relying on tools. Twitter have a very well documented API, I use that as a basis for the RESTful APIs I write.

Resources