I have the exact same issue as this question, however it looks like OP dropped off from troubleshooting.
I am accessing this endpoint:
GET https://graph.microsoft.com/v1.0/users/[UPN]/drive/
However the response is lacking the quota property (and an empty owner property):
{
"#odata.context":
"https://graph.microsoft.com/v1.0/$metadata#drives/$entity",
"id": "[ID]",
"driveType": "business",
"owner": {
"user": {}
}
}
I can confirm via http://jwt.calebb.net/ that the Files.Read.All permission scope is applied to the application (in fact, I've ticked every box in the Azure app).
The token is being generated at the tenant level using the tenant's Account Object Id (ie, not on the user level).
Based on some quick testing using the Microsoft Graph Explorer:
https://graph.microsoft.io/en-us/graph-explorer
It appears to me that the result you are getting (with an empty owner property, and lacking quota) is a result of the fact that you do not have access to another person's drive information.
Specifically if we try the following query, using the Demo Tenant Available by the Graph Explorer:
https://graph.microsoft.com/v1.0/me/drive
I get all the data you are looking for. Even if I specifically call out the UPN of the demo user:
https://graph.microsoft.com/v1.0/users/alexd#a830edad9050849NDA1.onmicrosoft.com/drive
It works. However, if I try to query ANOTHER user:
https://graph.microsoft.com/v1.0/users/admin#a830edad9050849NDA1.onmicrosoft.com/drive
I get exactly what you posted above.
You should make sure that you are logged into the user account which you would like to query their Drive's quota information. I believe this will fix your issue.
EDIT:
I just noticed in your question that you mention you are getting an App Only Token. My guess is that this information is not available at the App Only Level, and again, requires a user to be signed in to get their specific drive information. I might need to follow up to understand if that is really a requirement here. But I hope you can, in the meantime, verify the fact that using a user token, you are able to resolve the drive information about that user.
Related
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I have created a .NET Core 2.0 API and published it to Azure. I have an API Management (APIM) instance fronting that API and doing all the wonderful things that it does. However, there is one thing I cannot seem to wrap my head around or find any documentation for. Authorization on operations. (Not to be confused with authentication, which I have working very well).
My API is a simple RESTful service with CRUD actions. Let's take a read operation for example:
GET /api/owner/{ownerid}/thing/{thingid}
In this case, what I want to be able to do is to grant users permissions to READ THINGS within a specific OWNER. The same user may not have read permissions with a different owner. If the user has permissions, 200 OK; otherwise, 403 Forbidden.
Leaving this completely carte blanche, what are some suggestions for implementing this? I assume an inbound policy for each operation within APIM is where the action will take place? If so, how?
Update 1
I was informed of the possibility of using the same validate-jwt policy at the individual operation levels to append to the validate-jwt policy at the root. The idea is that the root policy validates that the user is authenticated while the operation policy checks for specific claims. This appears to work well, but is that the correct method, or just a hack?
Update 2
For the validate-jwt option to work, the permission model would need to align well with roles and groups; otherwise, it's just as much work as setting up your own custom database wherein at least you benefit from your own rules. In the end, I put the permissions in an Azure Storage Account table (any database will do) and used a send-request (with appropriate caching) to gather permissions based on the current operation and user. It works well, but "feels wrong". I am happy to share details to anyone who wants. In the meantime, I'll leave this open for now in case someone has a better idea.
Ultimately the only way to do so is by using policies at operation level. you can use validate-jwt to check for specific claims, you can check some other credentials that are passed to you as a part of request. Or you can use send-request to call some other service and ask for user permissions. In APIM itself there is no place to store any user related data besides some basic info, thus it is required for such authorization information to come from outside of APIM.
In the end it appears that there is no built-in solution. Rolling your own permission model and then validating it yourself is the way to go.
However...
This can still be done in APIM. As I mentioned in my second update, I was able to make a custom solution work. The way it was done was to use an inbound policy at the "all operations" level to retrieve permissions. (A caching mechanism was used so as not to retrieve the permissions on every single call.) Then, each operation determines if the user has permission to that specific operation based on the parameters that were passed in. (That is also cached.)
The result is that the root API has no authentication or authorization built-in, but APIM does and the appropriate behavior is observed.
Still, the preference would be an RBAC approach. For example, imagine the individual operations being seen as services as in this role definition:
{
"Name": "{rolename}",
"Id": "{roleid}",
"IsCustom": true,
"Description": "{roledescription}",
"Actions": [
"GET {myapi}/owner/{ownerid}/*",
"POST {myapi}/owner/{ownerid}/*",
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/subscriptions/{subscriptionid}"
]
}
If that were possible, we could create roles, assign them to users/groups at the subscription level, then have the claims automatically passed to APIM where they can be evaluated like any other claim.
First of all, I am no developer. I manage an Office 365 server for my company and I would like to do some heavy reporting using excel.
I have learned of Microsoft Graph and how I could get my data with it.
I created an app in Azure Active Directory, and I tried to set it up.
I added authorizations for Microsoft Graph, including Read All users full profile.
I add one Read directory data permission for Windows Azure Active Directory too.
I clicked on the Grant Permission button.
In the manifest, I changed those parameters to true :
oauth2AllowImplicitFlow
oauth2AllowUrlPathMatching
Now from Excel (2016), I am trying to add a new OData Source, and tried
https://graph.microsoft.com/v1.0/users
I entered my credentials (as Global administrator) using the Professionnal Account tab, and unfortunately, I only get Resource Access Denied (Sorry if the message is not accurate, I get it in another language).
Could anyone give me a hand in telling me what I have missed, please ?
Thank you in advance.
I had similar issue and found that the problem might be that incorrect flow is being used to authenticate.
Warning: once you change your permission and grant them it may take up to 30 mins for the permission to be granted.
First of all, please check your access token (you can decode it easily using https://jwt.io. As a result you should receive this part in your decoded payload:
"roles": [
"User.Read.All"
],
If you don't see it it means that permission is not granted properly. As you wrote that you enter the credentials I assume that you use authorization code grant flow.
To resolve this you you can first check whether you granted application permission or delegated permission to your app. You can look at this page to see the difference. If you want to use application permission you can use client credential flow. If you want to use delegated permission you can use authorization code grant flow.
In application settings > Required permissions you can check which permissions you granted and correct it, if needed:
If you are using authorization code flow you can also add delegated permission to your app and check if new access code contains required role (keep in mind that some permissions might be available only in one of the categories - however, Users.Read.All is available in both).
Source
We have multiple Azure accounts for our various environments. I'm able to create schema extensions on the accounts we use for preproduction and development but for our production Azure account I'm unable to create schema extension even though setups are exactly identical.
Like our other accounts I use OAuth 2.0 token of a global admin and make HTTP POST to https://graph.windows.net/ourinstance.onmicrosoft.com/applications/ourmultitenantappId/extensionProperties?api-version=1.6 with the payload:
{
"name": "SA",
"dataType": "String",
"targetObjects": [
"User"
]
}
Graph API returns with HTTP 403 Forbidden with Authorization_RequestDenied error message.
I have definitely verified user account I'm using has global admin access role, I have created multiple global admin user accounts in old Azure portal and the new Azure portal, I have compared all user and multitenant app settings between the production Azure account and preproduction Azure account and have compared the manifests as well but to no avail.
I have done all these checked for at least 5 times. I'm at a loss why I keep getting Authorization_RequestDenied error message.
Anything I could have possibly missed?
As far As I know, there are two kinds of 403 error.
First one is like that Insufficient privileges to complete the operation. For this issue, please ensure the app has Directory.ReadWrite.All permission.
And the second one error is like The size of the object has exceeded its limit. Please reduce the number of values and retry your request. This error occur when if an application tries to set a value for an additional extension property on an object for which 100 extension property values have already been set. At present, there is no work around for this issue please check whether there are schema extensions which is not used and unregistered the extension.
Got the problem resolved through Microsoft Support.
Turns out OAuth token didn't have necessary permissions despite the fact I have added permissions needed in UI. I had to explicitly grant admin consent to the application using https://login.microsoftonline.com/{tenant-id}/oauth2/authorize?client_id={client-id}&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2F&response_mode=query&resource=https%3A%2F%2Fgraph.windows.net%2F&state=12345&prompt=admin_consent
This was working fine for many months and now it's just a blank space. I get the following error: Error from Instagram: The access_token provided does not match an approved application. How can I get a new access_token for an existing client??
You need to check you application hasn't been put into sandbox by Instagram. They made big changes to their API on the 1st of June and if you had it submitted your app for review it will be put in sandbox mode and only sandbox users will be able to use it.
Even if you are not in sandbox mode you may need to get your users to reaurhorize your app due to new scopes being used to control access to everything other than basic user information.
Check Instagram Developer Docs for more information on the changes
You need to check your Access token's Scope and asking for login permission
where some new Scope had been added ex:public_content Added. Also don't forget to check for requirements Scope for API you are using and if it's need and Authentications "Valid access Token". where also had some changes.
basic - to read a user’s profile info and media
public_content to read any public profile info and media on a user’s behalf
follower_list to read the list of followers and followed-by users
comments - to post and delete comments on a user’s behalf
relationships - to follow and unfollow accounts on a user’s behalf
likes - to like and unlike media on a user’s behalf
And take look about **Sandbox API behavior of your application not life yet :**
API Behavior
The behavior of the API when you are in sandbox mode is the same as when your app is live, but comes with the following restrictions:
Data is restricted to sandbox users and the 20 most recent media from each sandbox user
Reduced API rate limits
The first point is important and it means that the API behaves as if the only users on Instagram were your sandbox users, and the only media ever posted were the last 20 for each of these users.
For example, if you query the /users/{user-id}/ endpoint and the {user-id} is a sandbox user, then you will get the normal API response; but if the {user-id} is not a sandbox user, you will get a APINotFound error.
As another example, let's consider an endpoint that returns a list of media: /tags/{tag-name}/media/recent. The response returned by this endpoint will contain only media with the given tag, as expected. But instead of returning media from any public Instagram user, it will return only media that belongs to your sandbox users, restricted to the last 20 for each user.
Good luck
The following video clearly explains what steps to follow to get this working with the new auth
https://www.youtube.com/watch?v=0k4RhTS94Hw
Kind Regards
Sandeep Sahoo