Can I add tenant wise policy in wso2 api manager - wso2-api-manager

I am using wso2 api manager ,I would like to add policies for the tenant like if a tenant has 2 users and I need to enable that tenant to use one API upto 5 request only and another API unlimited when tenant is selected a specifc policy named "free" and also need to enable unlimited request to both APIs when tenant selected another policy eg:"Standard"
Also In this case i need to count the requests by both users in this single quota.
Means that if 1st user from the tenant sent 3 request and 2nd user of same tenant sent 2 request , i need to stop any more request from any users under this tenant ,Is it possible to do so ?
Thanks for the help in advance

You can add different policies at different levels and these are applied at tenant wise.
https://apim.docs.wso2.com/en/latest/design/rate-limiting/adding-new-throttling-policies/#adding-a-new-advanced-throttling-policy
This is how throttling applies in API Manager.
Also you can define custom policies where you can apply globally or tenant wise. https://apim.docs.wso2.com/en/latest/design/rate-limiting/advanced-topics/custom-throttling/#custom-throttling

Defining a custom policy for a tenant using the admin console will solve your use case. Building a siddhi query precisely will give a wide range of customizability to your implementation. Also, check out this link where you can learn more about throttling related use cases.

Related

How can I control the access of an API at definition/operation level in WSO2 API store console?

Ex: Lets assume I have a 'Calculator' API and it has below operations/definitions.
1.addition
2.multiplication
I want restrict user with addition operation and remaining operations should not be visible/access in store console.
Is there any way to achieve this?
You can restrict the access for each resource by configuring scopes for each resources. If the user has access token binding to the particular scopes only can invoke the resources restricted with the scopes. Documentation has detailed useful information regarding this - https://wso2.com/library/articles/2017/01/article-an-overview-of-scope-management-with-wso2-api-manager/

Firebase browser key API restrictions

When creating a new project Firebase generates browser API keys automatically in the GCP API credentials. This is the same API key that is set in the Firebase Web client SDKs and is publicly available.
By default the key has no restrictions, so it's prone to quota stealing for every API enabled for that project. Surprisingly I have not found information about securing this key in the Firebase documentation.
So I took two extra steps to secure the key:
Added HTTP referrer restriction to allow requests from my domain only.
Added Identity Toolkit API to the list of allowed APIs. Experimentally I've figured out that it's enough for Firebase Auth and Firestore to work.
Added Token Service API. This is needed for refresh tokens to work and keep the authentication.
My question is mostly related to points #2-3. What are the APIs that needs to be enabled for various components of Firebase to work on the web?
I also enabled those same two APIs, but I used the Metrics Explorer to see what the various Firebase-created keys had been using based on actual traffic.
In GCP,
Go to Monitoring -> Metrics Explorer
Click 6W in the time range above the graph
Resource Type, start typing consumed_api and select it
Metric, choose Request Count
Group By, type credential_id, select it, then type service, and select it
Aggregator, select sum
By now, the legend for the graph should list all the credential ids and which services they used in the last 6 weeks. You should be able to figure out the APIs from the service.
You can use Filter to filter by credential_id if the results are too noisy.
By default the key has no restrictions, so it's prone to quota
stealing for every API enabled for that project.
This is indeed possible and I am able to make e. g. Google Maps API call with the auto generated Firebase API key.
Such preconfigured behaviour was certainly unexpected and I am now experimenting with the restrictions as per the extra steps described in the original question.

Set policy and role in AWS to connect API Gateway and DynamoDB

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

Explicitly allow usage of production API

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

How to query PingFederate

I am new to Ping Federate and have a few questions. I am trying to understand from an architect's perspective a number of things around querying and APIs. I understand Ping Federate supports attribute-query request. This seems very much doable but only appears to work for querying additional attributes based on the current SAML instance.
What I am trying to understand is what options exist for querying a 'user list' or querying attributes for specific users? I need to check users for changes in specific attributes or have a means to be notified of changes to specific attributes. Based on the following somewhat related link, I believe it is not possible:
In PingFederate, is there an API to query a list of users and a list of groups?
But, I would think architecturally something like this should be possible. Is there a way to query PingFederate in the manner above? Or have it notify you of changes? Directly or indirectly?
Regards...
Attribute Query is not restricted to an ongoing user session if that's what you're worried about.
See here http://documentation.pingidentity.com/display/PF72/SP+Services#SPServices-1110907 for the endpoint that a PingFederate SP would use to execute an attribute query to a partner SAML IDP. The latter IDP may use PingFederate as an IDP (which I believe is what you're looking for) or any other SAML implementation that supports SAML Attribute Query.
Wrt. notifications: PingFederate implements the SCIM (http://www.simplecloud.info/) protocol for this purpose (http://documentation.pingidentity.com/display/PF72/Configuring+Outbound+Provisioning) so you could use that to get notifications.

Resources