I am trying to use the Desire2Learn REST API to return semesters, but I'm getting a 403 Not Authorized error.
The request I am making is:
GET /d2l/api/lp/1.1/outypes/semester
I am making this call while authenticated to the system as a student user.
This is a test environment, so I have full control of the student user's permission, but I haven't found which permission setting controls access to the semester org unit. Is it possible for someone with lower level permissions to make this call?
What permission would this user need to be able to make this call?
Thanks!
Student-type user roles are not typically given permission to make calls like this one.
The particular permission at play here is likely Org Unit Type Editor > Can Create and Edit Org Unit Types at the root organization level (you'll notice that the same behaviour is at play around the API call to retrieve the entire catalog of known org-unit types); however, you almost certainly do not want to grant this role permission to a student role: the role permissions for this tool bind together the ability to create and edit org unit types with the ability to see their definitions.
Related
My application is composed of an API layer which is accessable by presenting a Bearer Token, obtained from our Identity Server. Each of our API has a level of scopes that the token must contain in order to be invoked: this means, for example, that if you want to make the API call which "creates a product" you need a write access to products (i.e. the scope "products") while you may just need the scope "products_read" if you only want to retrieve them.
Scopes are bound into the token when you authenticate onto the ID server.
Now, I need this user to be able to perform different operations on different "workspaces". Each workspace administrator can set which permissions each user have. This is, in fact, linked to the scopes that each user will have when operating on that particular workspace.
Right now we have implemented that, if you are trying to access a different workspace, the API layer will check:
if your bearer token is valid (by validating it on the ID server)
if you are authorized to access that workspace
changing associated claims by removing the original "scopes" (set into the token by the ID server) and overwriting with those assigned by the administrator of that workspace
This somehow works, but it stinks because I don't want my application layer (API) to have this kind of responsability and the opportunity to tamper with the token. I want the ID server to handle it and, after the user tries to enter into a different workspace, it generates a new crafted bearer token with correct claims (so the API will just need to trust it).
What's the best approach in doing that? I'm digging into the "custom grant type": may this be the right approach?
Scopes are fixed at design time and the same for all users. I like your use of products and products_read - that is very standard.
When you need dynamic behaviour, implement claims, which depend on who the user is. In your case I would use a workspaces array claim. Since this is a key vaue for authorization, it should be added to access tokens at the time of token issuance. Think in terms of your products scope being composed of claims.
It feels like workspaces and other permissions are part of your business data rather than your identity data. At the time of token issuance, IdentityServer should send identity attributes (eg subject claim) to an API endpoint you provide. which returns business attributes (workspaces). I believe in IdentityServer this is done via a custom profile service.
I'd try to avoid different tokens for different workspaces, since that will be awkward in terms of usability and code complexity. The standard way to do it would be to redirect the user each time.
The Azure port still uses the Azure AD Graph API in some places. One thing it uses this for is to list API permissions. For this, the portal uses the REST API target GET https://graph.windows.net/myorganization/applicationRefs/c5393580-f805-4401-95e8-94b7a6ef2fc2?api-version=2.0 (example shown for Office 365 Management API). I've searched and cannot seem to find a way to list similar permission sets using the Microsoft Graph API. Is there a way to access this using the Microsoft Graph API?
Ok, was going to upvote one of the previous answers, but my profile is too new. :( You can do this by reading the MS Graph service principal in your tenant as described above. This PowerShell code gives an example (it's used in a command called Find-GraphPermission in the autographps and autographps-sdk modules.
Basic approach is:
Get app-only permissions from the appRoles property of the servicePrincipal
Get delegated permissions from the publishedPermissionScopes property
Each element of appRoles has an id that can be read or written from a given appRoleAssigment object on an app's servicePrincipal in your tenant. Note that each appRole element has a value property that is the common friendly name of the app-only permission (e.g. BitlockerKey.ReadBasic.All
A similar id and value pair exists for each element of publishedPermissionScopes which gives you the delegated permissions. You can use those ids with oauth2PermissionGrant objects under the segment /oauth2PermissionGrants to enumerate consent grants for a given servicePrincipal (and thus app) in your tenant or grant or remove consent
Note that the ids for both appRoles and publishedPermissionScopes are the same in all tenants, so you can actually perform this same mapping of friendly names to ids for any tenant, and use a static snapshot. This can be useful as your application may not be able to read the Microsoft Graph servicePrincipal object. If you store a static version, you'll have the mapping regardless and you'll only miss any new permissions that get added to Microsoft Graph for new APIs.
This file contains a snapshot of the MS Graph servicePrincipal as a fairly readable JSON-like PowerShell hash table: https://github.com/adamedx/autographps-sdk/blob/main/src/common/DefaultScopeData.ps1
For this requirement, you can use this microsoft graph api: https://graph.microsoft.com/v1.0/applications/<object id of the application>
It will response the result like below screenshot(please pay attention to the field requiredResourceAccess):
The content under requiredResourceAccess is the API permissions of this application. The type scope means the permission is Delegated type and the type role means the permission is Application type.
Then please refer to steps below to know which permission does the id under resourceAccess field refer to.
Copy the resourceAppId, in my screenshot is 00000003-0000-0000-c000-000000000000. And request the graph api: https://graph.microsoft.com/v1.0/serviceprincipals?$filter=appId eq '00000003-0000-0000-c000-000000000000'
Copy one of the id under resourceAccess field in the response of first graph api. For example copy the first id a154bxxxxxxxxxxx59 in my first screenshot. And then search this id in the response of second graph api, we can find this id refer to User.Read.All permission.
I am trying to create a flow process to automate creating CSV files which contains the student, teacher assignment, submissions, and submission outcomes. I have registered an app in Azure AD and I can connect to this fine via PowerShell with delegate permissions and see all of the data I need.
However, when I try to connect with application permissions EduAdministration.Read.All, EduAssignments.Read.All and EduRoster.Read.All, I can only see basic Class and Student information. So calling https://graph.microsoft.com/v1.0/education/classes works but calling https://graph.microsoft.com/v1.0/education/classes/CLASSID/assignments does not (I get a "Resource not found for the segment 'assignments'").
As I have an admin account which is a member of the CLASSID team, I can see all of this information if running from graph explorer with delegated permissions.
So, is there something else I need to do to get the application .Read.All permissions working or are there a tutorial of how to connect to graphs with Flow using delegated permissions?
There are a couple of things going on here:
"Resource not found for the segment 'assignments'" Error
You're receiving this error because you're attempting to call the Assignments endpoint in v1.0. Assignments is still in Beta, so you need to use /beta, not /v1.0.
Once you get past the segment error, you will still have a permissions issue. The Assignments endpoint only supports Delegated scopes. The inverse is true for Classes which only return limited information using Delegated scopes. In order to call both endpoints, you'll want to have two separate tokens (one delegated, one application):
For /education/classes/{id}, use the Application scope EduRoster.Read.All.
For /education/classes/{id}/assignments/, use the Delegated scope EduAssignments.Read.
For administrative purpose, especially the deprovisioning process, it'll be useful to know if a user has shared any of his resources (Docs, files etc.) with other users.
Any tips or code that could solve this task?.
You can check what permissions are given to users toward a file by using this drive.permissions.list request:
GET https://www.googleapis.com/drive/v2/files/{fileId}/permissions
The response gives you information about what users are authorized to interact with the file, including user's id, name, role, type ... that you can choose to store in your database.
You can test this by using Google API Explorer
I want to use Facebook as an authentication source for my application (a website) users. I do not want my application to have anything but basic and email permissions. Thus, my application must not be able to publish to a user's wall for example. In other words, I want to restrict the allowable set of values for the scope parameter and I want this restriction to occur on the application's configuration pages (on the Facebook site itself).
Normally this would be easy, just specify 'email' for the scope parameter of the OAuth URL/call.
However in this case there is another factor and this is: a hacker may gain access to the app and change the OAuth call to specify more permissions. Then an unsuspecting user will typically (or at least possibly) grant those permissions and the hacker will be able to grab the OAuth token and perform actions on behalf of that user.
I'm not interested in discussing the whys of this issue, just in finding of there is a way to specify that my application can only use a specific set of values for the scope parameter. Ideally this specification of the scope restriction be done in the application configuration page on Facebook itself.
However, I am interested in alternate solutions that involve using SAML, OpenID or some other authentication only mechanism (even if I cannot get the users email address). I'm not interested in using RPX.
Please note: this is a complex question not a simple one. I have searched far and wide for an answer and have just found what amounts to the opposite of this question.
I'm pretty sure it's not possible to restrict the scope at application configuration level.
I'd say the tidiest workaround would be to query the permissions of a user on signup, check that they match the allowed permissions, and subscribe to the (permissions realtime updates)[http://developers.facebook.com/docs/reference/api/realtime/]. Your app will be notified of any changes in permissions granted to users.
This should allow you to block any server side API calls through application logic, or (ban)[https://developers.facebook.com/docs/reference/api/application/#banned] a user which escalates permissions.