Ref: Microsoft Graph API : Restrict scope of calendar.readWrite and Audit mailbox access by Application Permission
Same issue here...are there any other solutions besides limiting to a specific email or security group.
Our issue is having the app permissions Calendars.ReadWrite. The main concern is that sensitive attachments are accessible via the API. Is there maybe a way to block specific http requests? Or other way limiting access to such sensitive information
At this point we do not find any way to block specific http requests on your attachment.
By Default when using the Calendars.ReadWrite as a App Permission it allows the App CURD events of all calanders without sighin.
Provide access to the data in the entire tenent.
Best Practice is to Stick with least privilage permissions.
Try to Use Calendars.ReadWrite.Shared delegated permissions to your AAD application.
Related
We are looking at integrating our apps with Openid connect for our react based apps. We have ui and relevant permissions based on user - menus, navigations etc.
Can anyone point to spec or suggest on how do we handle such permissions in relation to openid connect or oauth. Basically how do we make this permissions available to ui, one approach is dedicated API for ui permissions again authorized by access token.
Another approach is permissions in token itself. Scope is one way of holding info, but it is for delegated access. Hence we are thinking to use multivalued custom attributes for holding roles and permissions in access token. But these permissions can also be huge sometimes and thinking hence if it is good idea to keep permissions in access token.
Any valuable pointers or any design approaches for handling ui permissions list please let know, we highly appreciate it.
The most flexible option is a custom API endpoint. An access token should hold important identity values such as these:
User ID
Roles
Company ID
Tenant ID
Country Code
Subscription level
These are claims, and are populated at runtime for each user, unlike scopes, which are fixed at design time.
Access tokens are designed only to be used by APIs, and clients should never read their payload. A good practice can be to return opaque unreadable access tokens to clients, to enforce this.
The actual permissions for a role can be looked up by the API once, then cached. This is preferable to storing large payloads in access tokens.
Finally, permissions for UIs may originate from two data sources: the identity data and your business data. The API can combine a result from both data sources, and transform the result to what the UI needs. Eg which columns are visible, which are read only and so on.
I have a service that will be registered in Azure AD as an App. It will have one app registration per region (West US, East US, etc.). Clients calling this service need to acquire an access token. The audience of the access token MUST be the corresponding service for the region. The services are segregated regionally so that an access token for a service in one region cannot be used to access the service in another region. This is by design.
Is there a proper way/recommended best practice for the application discovery?
I have explored the idea of using Graph API. In the model:
Each of the registered services will be created using a templatized naming convention e.g. -. There is a concern here that without proper coordination within the tenant where these apps are being registered, we could end up with a name collision.
A “discovery app” (application registered for the sole purpose of usage for discovery) will have Application.Read permission the Graph API. Authentication here will be based on a X509 certificate for greater security.
Using an access token acquired against the discovery app, Client will query Graph API for the intended service app audience matching on the name. Once that app info is obtained, we’ll have the service app id. Again, concern from #1 above still stands - another application registered with same name will also be found.
Client will then use service app id obtained to acquire an access token to talk to the service.
Any help/direction would be much appreciated. Want to make sure I am not re-inventing the wheel if there is already an appropriate pattern to doing this.
Your design is feasible. Of course, you need to make reasonable adjustments to the names of app registrations to eliminate the influence of name collision.
I have a suggestion that you could add these service app registrations into a security group and use Microsoft Graph (Beta version) to list them with a filter (templatized naming convention).
Reference here:
GET https://graph.microsoft.com/beta/groups/{id}/members?$count=true&$filter=startswith(displayName, 'a')
ConsistencyLevel: eventual
Please note that $count=true and request header ConsistencyLevel: eventual is necessary.
There is a property appId in the response which is what you need. In this way, the influence of name collision can be avoided as much as possible.
I want to have an architecture made up of these devices / programs with different roles (which are all separated, none of these roles must exist in one and the same instance):
CLIENT
AUTHENTICATION-SERVER
AUTHORIZATION-SERVER (there can be a multitude of these)
RESOURCE-SERVER (also many possible)
And:
I don't want to use any websites a user has to navigate to.
From my studies of OAuth and Open ID Connect I would assume that a Client could get an ID_TOKEN (after authorization) from an AUTHENTICATION-SERVER and could then request ACCESS_TOKENS to different resources from the AUTHORIZATION-SERVERs.
I guess the method I described allows identity theft on the client side.
I cant find a way to easily get id tokens from an authorization server to a client (which I could then use to authenticate to multiple authorization servers). My clients are trusted. I want to use native apps and implement open id connect among them anyway.
I do not want to use any websites as of now and still need to be able to have a secure communication with associations of claims to users and everything. Are OpenID Connect and its possible 'Flows' appropiate for this? Are there any other implementations that would allow the flow I described (or mabye derivations of OpenID Connect)?
It's not recommended but if you really don't want to use a browser (which is somewhat anti-OAuth/OIDC and is full of limitations) then ResourceOwnerPassword grant type is the one you'll need to use. This will not return an id_token though, just an access_token.
id_tokens exist to support front-channel browser-based sign in flows, they serve no purpose if using the ROP grant type.
Access tokens are issued by the authentication/secure token service (IDS4 in this case) and grant the client (optionally with user consent) access to the resource. The resource then has its own authorization rules to enforce scope and user-related ACL/business rule access controls.
I have a registered a native app (WPF) with AAD and set it up to have permissions to Microsoft Graph. I had a small set of delegated permissions to start. Everything worked great - ie, reading user's calendar.
I have added some additional permissions (SendMail specifically). When I want to use the Graph SDK to send email, I get an access error. When I check the access token returned by ADAL, it only contains the scopes "scp": "Calendars.Read offline_access Tasks.Read User.Read".
Pretty simple ADAL call...
_authClient = HermesAuthenticationClient.CreateAuthenticationClient(clientId, _redirectUri, authority);
var result = await _authClient.AcquireTokensAsync(resource, new PlatformParameters(PromptBehavior.Always));
Any pointers would be much appreciated.
There is a known issue involving changing scopes of an existing application. Because you have already authorized that application using the previous scopes, it is unaware of the additional scopes that have been requested. In other words, the old scopes you authorized are cached and the new scopes aren't recognized.
You'll need to manually revoke permissions for the application under "My Apps".
Alternatively you can generate new id's for the app which will also trigger the "request permission" workflow.
I'm creating an application in with angular and nodejs and I need to be able to read another user's list of events. Right now I am attempting to use "https://graph.microsoft.com/v1.0/users/otherusername#companyurl.com/events" this gives me the 403 "Access is denied. Check credentials and try again.". However, if I use "https://graph.microsoft.com/v1.0/users/myusername#companyurl.com/events" it works(as most would expect). My question is, why is it when I use outlook I can use scheduling assistant to see the events for "otherusername#companyurl.com" without being an admin but in my application I cannot see their events due to credentials?
The library I'm using to connect to microsoft graph api is https://github.com/AzureAD/azure-activedirectory-library-for-js
The delegated permissions I have set in azure are
View users' email address
Sign users in
Read user contacts
Have full access to user calendars
Read user calendars
Send mail as a user
Read directory data
Read all users' basic profiles
Sign in and read user profile
Application permissions (I understand these require admin)
Read calendars in all mailboxes
Graph api permission scopes
Any help is appreciated, thankyou.
Fugal - This is by design. You can use FindMeetingTimes API to schedule meetings with other users. This can be accomplished with just Calendar.Read permission. See http://graph.microsoft.io/en-us/docs/api-reference/beta/api/user_findmeetingtimes for more info.
For you to view another user's calendar using /events endpoint, you need a special permission (something like Calendar.Read.Shared) that we are still in the process of adding. Once we add that, you will be able to use /Events to access any calendar that another user has explicitly shared with you. But if you want to just schedule meetings, FindMeetingTimes should be sufficient.