I'm developing a "token debug" system to help the user figure out if they grant all the needed permissions in order to use the platform I'm working on as a developer.
I can observe a behavior that goes against the expectation I have after reading the developer documentation about the requirement to fetch data from lead gen forms.
According to the developers documentation [0] in order to fetch leads for a form via the adFormResponses endpoint the account must have the r_ads_leadgen_automation permission and must have one of the following company page/organization roles: ADMINISTRATOR, LEAD_GEN_FORMS_MANAGER, CURATOR, CONTENT_ADMINISTRATOR, or ANALYST
I have a token that according to the token introspection API [1] has the following permissions:
r_ads,r_ads_leadgen_automation,r_ads_reporting,r_basicprofile,r_emailaddress,r_organization_admin,r_organization_social,rw_dmp_segments
I want to fetch the leads from a lead gen form from a given organization XYZ, if I check the roles [2] of the token I'm using I can see several roles for other organizations but I can't see anything (in any state) for the organization XYZ.
The weird thing is that that very same token is able to fetch leads for a form from that organization [3].
Are there some conditions under which I can't fetch all the roles correctly for a given token?
Thanks,
Alessandro
[0] https://learn.microsoft.com/en-us/linkedin/marketing/integrations/lead-gen/ads-leadgen?view=li-lms-2022-11&tabs=http#permissions
[1] https://learn.microsoft.com/en-us/linkedin/shared/authentication/token-introspection?tabs=curl#enterprise-oauth-token
[2] https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/organizations/organization-access-control-by-role?view=li-lms-unversioned&tabs=curl#sample-request
[3] https://learn.microsoft.com/en-us/linkedin/marketing/integrations/lead-gen/ads-leadgen?view=li-lms-2022-11&tabs=curl#fetch-responses-by-ad-account
Related
We have created an application on the developer program in order to use the linkedin API to retrieve some information. On our app we can check all the permissions that we were granted, so we have created an access token with all the permissions of our app. However, there are some endpoints, such as organizationalEntityFollowerStatistics, that are not working due to some permissions problems. Moreover, in the case of the shares endpoint, we are getting a response, but the elements array is empty when the count field says that exists some elements. On the products tab, we are able to check which permissiones requiere each endpoint in order to be able to use it, and for both of them we have the permissions, however it seems that something is not working correctly.Permissions of the token attached
I'm using Microsoft Graph SDK for .NET Core. I'm trying to get a list of all Office 365 plans in all Azure Active Directory groups within my organization.
I have been reading through a lot of questions, but haven't found a clear answer to my problem: As it's stated in the official documentation, you cannot list plans in a group using client credentials (application permissions), which is the exact authentication method I'm using. Given this, how can I achieve my objective?
As per documentation, the only way to list plans in groups is to use Delegated Permissions, but in that case, and according to the Microsoft Graph permissions:
either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph.
If the signed-in user is a regular user then the application will only access the groups that user is a member of. Bear in mind that there may not be a single user that is a member of all groups.
Is there a way to get my application to list all plans in all groups within my organization?
You can now use application permissions.
Outdated Reply:
Planner currently does not support application permissions. Depending
on what your scenario is, you have couple of options. One option is to
create a user account to be used by your app, and add that user to all
the groups. Then you'll be able to query the plans with the
credentials of that user.
I am trying stream data from the AWS API Gateway to DynamoDB in AWS (directly, without something like lambda). I have looked for several tutorials, such as [1] and [2], who describe exactly this scenario. All of these assume that the right policies and roles are in place. Normally, I play and hack around till I get a working proof of concept, after which I rebuild a proper model, but with access rights I want to make sure I understand what I am doing. For [2], I also found a stack overflow question at [3] from somebody with the same problem that got solved, but not sure exactly how. I also looked at [4], describing API Gateway with Lambda.
Here is my guess:
Create a policy that allows calling from the API Gateway.
"AmazonAPIGatewayInvokeFullAccess" fits the name, but might not
be necessary + overkill with too much access
Create a policy that allows access to dynamoDB.
Here, "AmazonDynamoDBFullAccess" might be appropriate, even
though it might be overkill (too much access), and might only work
from the Management Console
Create a role that has those two policies attached.
Here, I run into the trouble that when I click create role, and
select AWS service, I can not find the correct "service that will use
this role" that has the policies I described above behind it. For
example, when clicking dynamoDB, I get the following "use-cases", none of which seem to relate to the dynamoDB full access policy:
Amazon DynamoDB Accelerator (DAX) - DynamoDB access
DynamoDB - Global Tables
DynamoDB Accelerator (DAX) - Cluster management
My main question is: How do I set the right minimal set of roles and policies to connect AWS API Gateway to DynamoDB (read and write), as described in [1]?
[1] https://sanderknape.com/2017/10/creating-a-serverless-api-using-aws-api-gateway-and-dynamodb/
[2] https://aws.amazon.com/blogs/compute/using-amazon-api-gateway-as-a-proxy-for-dynamodb/
[3] API Gateway does not have permission to assume the provided role DynamoDB
[4] https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html
What you need to do is create an IAM Service Role that allows API Gateway to assume this role. You can easily do this through the UI. When you create a new role, the "Service Role" is selected by default and below the "Choose the service that will use this role" header, you can select API Gateway.
A role is a container of permissions that can be assumed by a certain entity (in our case, an API Gateway API resource). Your role needs "permissions" for the role to have any use. You add this permissions by adding policies to your role. This is explained more in depth here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html
Be sure to read the AWS Service Role part. You say that you need to "Create a policy that allows calling from the API Gateway" but this is incorrect: you need to create a role that can be assumed by API Gateway.
In your case, you'll want specific DynamoDB permissions for your role. Following the least-privilege principle as you mention, you should only add the specific actions for the specific DynamoDB table. The list of possible permissions can be found here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/api-permissions-reference.html
Let's say you only want API Gateway to get items from a specific table. Your policy might look something like this then:
{
"Effect": "Allow",
"Action": "dynamodb:GetItem",
"Resource": "arn:aws:dynamodb:eu-west-1:[aws_account_id]:table/[table_name]"
}
Hope this helps!
This recent new tutorial by ankana likhita sri priya includes starting off in high detail/screenshots of IAM (Policy, Role, etc.): https://medium.com/#likhita507/using-api-gateway-to-get-data-from-dynamo-db-using-without-using-aws-lambda-e51434a4f5a0
I'm exploring WSO2 API Manager platform to use in Open API project. The idea is that we forbid registration in Store and creating users by ourselves. But we also want to give them only Sandbox API as a starting point and then, explicitly allow particular users to consume Production API. Haven't find any information. Is it possible? If yes - where to look?
You can restrict the token generation for the Production endpoints by using Workflows. Follow the documentation[1].
You could configure ProductionApplicationGeneration to use ApplicationRegistrationWSWorkflowExecutor and SandbobApplicationGeneration to use ApplicationRegistrationSimpleWorkflowExecutor.
With this approach if the subscriber tried to generate a token for production endpoints, it will trigger a human task, which needs to be approved from the Admin Portal.
For your requirement, you could write a custom workflow extension which allows restriction by role or user name. For more information on Writing custom workglow extension please follow [2]
[1] https://docs.wso2.com/display/AM210/Adding+an+Application+Registration+Workflow
[2] https://docs.wso2.com/display/AM210/Customizing+a+Workflow+Extension
Thanks and Regards
I have to integrate Docusign with my ASP.Net web application.In our application there are many companies and each company has Administrators and Users.I want to clarify something related to Integrator key required in below mentioned scenarios.
1)If only administrators are allowed to send documents for signing to other users.
In this case,do all the Administrators need to have separate Integrator key for sending documents for signing?
2)If all users are allowed to send documents for signing to other users.
In this case do all users of my application are required to have separate integrator key?
In short I really want to know how users can be managed with Integrator key?
Would it be 1 such account per Company, or 1 per initiator within a company?
Please suggest.
It's actually none of the above. A DocuSign Integrator Key is similar to what other APIs call their API key (Google for instance). It is used to identify a given DocuSign Integration, so you actually only need 1 Integrator Key for your entire integration. You can think of it as a "per app" or "per integration" key, not per user.
See this page in the DocuSign Dev Center for more information.