Will the scope prerequisites become specific to each API call?
For example, my current problem:
I want a non-admin user to be able to create an event on a group calendar [Group Post Events], but the API call requires the Group.ReadWrite.All scope, which means that only an admin can create events on a group calendar.
This means that there should be a MyGroup.Calendar.ReadWrite scope (or similar). Can we expect a change on this prerequisites?
Anyhow, thanks Microsoft Graph team for the daily improvements. This project is exciting.
Yes, we have a user consentable group permission scope in the works. See: Regarding admin consent for Group Permission Scope in Microsoft Graph API
Related
I have multiple Office365 private groups that I created using Outlook. I would like to be able to list, add and remove users using a Python script (or any other language). I am familiar with Microsoft graph API, and I have used it before.
I tried to use the graph API to manage the groups, but the permissions required to manage the group (Group.ReadWrite.All, GroupMember.ReadWrite.All) need an administrator's consent to be used. I cannot get admin consent within my organization, so is there another way to achieve this?
I'm trying to extract the share permissions for a Calendar through Microsoft Graph (or even the old Outlook REST API) but it seems that there is no Graph endpoint to get a calendar's sharing permissions.
When fetching a calendar's details, the closest I found was isShared on the Calendar resource - but that doesn't give me the full data I see from the Web UI:
Basically, trying to receive the equivalent of Google Calendar's ACL list.
Am I missing anything?
Since you cannot share the calendar through the graph api, or open a calendar from some other user that they shared with you, there is no point in showing the ACL.
You might have better luck using the Exchange Web Service (or EWS) they do have those properties on folders. https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/folders-and-items-in-ews-in-exchange
Or if you really need it in the graph api (since the EWS is no longer the recommended way to talk to Office 365) you can create a ticket on UserVoice (if it doesn't exist already).
I am using ng2-adal to integrate my Angular app with Azure AD login. My application should only be accessible to certain groups within my organization. Currently when I query the adal-service for user-info the jwt doesn't contain any groups information.
I figure I would query Microsoft Graph API to get /me/memberOf info but I get Access denied to this information and require an Admin to grant me permissions to view this data.
Is there any other way of getting this information or do I have to bug my IT dept to enable READ permissions for groups?
I'm afraid so, anything that looks at Groups requires Admin Consent.
It certainly seems reasonable that you should be able to see your own membership (/me/memberOf) with User.Read. That said, I'm far from an information security expert there may good reasons for not allowing it.
Regardless, I would highly recommend adding this suggestion to the UserVoice. They do have
In outlook I can lookup all users in my organisation, including phone number, address etc.
I guess using EWS I could do the same...
With Azure AD graph (https://graph.windows.net) I can get ALL(!) properties on all (GAL) users as well - without the option to select a smaller property subset…
In Microsoft Graph (https://graph.microsoft.com) I can get all users (GAL), but not (all) properties like phone number, title etc. without an admin allows access… Why is this different (more restricted) than the other APIs ?
ex. the permission; Directory.AccessAsUser.All (Access the directory as the signed-in user)
In Microsoft Graph user is UNABLE to consent
In Azure AD Graph - does NOT require admin
Using the /me/people (in preview) in Microsoft Graph I can get all properties on a lot of users in my organisation - but not all. And I might get some users that my nearest colleague can’t (why? - is it still buggy)
Every one tell you to use Microsoft Graph but it seems to be more restricted than the old APIs
I'd be interested to know a little more about the restrictive nature that you are describing. For the most part (with respect to Directory/Azure AD), Microsoft Graph exposes the same data secured by the same permissions model as Azure AD Graph. Please see https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#user-permissions for more details on the available user permissions and what they allow.
What you might be seeing with Microsoft Graph is the fact that when you query the /users entity set in v1.0 (i.e. GET https://graph.microsoft.com/v1.0/users) Microsoft Graph will return only a key set of user properties by default. The user entity type is pretty big, and growing all the time - it has more than 40 properties and 25 navigation properties. Serializing and de-serializing large objects, especially when paging collections can be expensive and non-performant, both for the client and for the Microsoft Graph service. Hence we return a default set. If you want other properties then you need to use the $select parameter. For example: GET https://graph.microsoft.com/v1.0/users?$select=displayName,givenName, officeLocation,postalCode,state. This is documented here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/user_get for example, but we are working on making some improvements to the documentation in this area too. If you want to see the full set of properties exposed by the Microsoft Graph user entity type, please look at the schema here: https://graph.microsoft.com/v1.0/$metadata.
[NOTE: $select is not supported in Azure AD Graph API, so we always return the full set].
The people API - ../me/people is about the people who you (the signed-in user) communicate with most often - it could also contain people outside of your organization. Hence, the list of people is likely specific and different for each user (even colleagues). It also is not the full directory of users in your organization.
I'd also like to get to the bottom of why you are seeing a difference in terms of consent - Directory.AccessAsUser.All always requires admin consent for web apps (for both Microsoft and Azure AD Graph).
Hope this helps,
Since Graph is a self-documenting language, I wanted to use this to my advantage and write PowerShell functions to automatically generate cmdlets based on metadata. I've got a lot of this complete, but am having problems figuring out scopes. Is there a way to find scopes? It's not stored in the metadata and the documentation doesn't have scopes listed for everything (for instance, nothing in Excel has scopes listed).
The Graph Explorer seems to request correct permissions, so that has access to this list somewhere.
It depends on which API you are looking for.
Scopes for Azure AD Graph API is at https://msdn.microsoft.com/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes.
There is a huge list for different parts of the Microsoft Graph API at https://developer.microsoft.com/en-us/graph/docs/authorization/permission_scopes.
When you first sign in to Graph Explorer, you give it these permissions:
Based on the descriptions and the link above you can figure out what the scope name is for each of the items in the list. (E.g. the first one is Mail.ReadWrite).
When you create an application in Azure AD, you configure which applications it needs access to, and what access it needs. That results in the list which the user grants access to on first signin.