Is there a limit on the count of Authorization Rules (Shared access policies) an Azure Event Hub can have?
The number of authorization rules per namespace just can be 12. If the number is larger than 12, the subsequent requests for authorization rule creation are rejected. For more details, please refer to here
Related
We are currently developing a cloud solution that would require 2000+ clients to publish events (1-2 per second) into an Event Hub. We built a prototype that gives each client a Shared access policy (Authorization Rule), and creates a SAS token with a publisher policy as defined here
We thus are able to identify the publisher of each event by inspecting the x-opt-publisher system property, and to revoke access to the Event Hub for each client at any time, without having to resort to token expiry and renewal.
However, we recently learned that the maximum amount of SAPs / Authorization rules is 12, so this solution ultimately will not work.
Is there another solution to this problem? Our goals are:
Avoid having to use token refresh, as this would require adding code to all clients.
Being able to revoke access to the Event Hub instantly in case a client either gets compromised, misbehaves, malfunctions due to a bug, or the associated customer's contract is terminated
Avoid having to use a frontend service authenticating the clients, as we are talking about a substantial additional system load (5000 requests per second)
Avoid having to use IoT hub, as the costs are far higher than with our solution, and we do not need all that functionality
Thanks in advance
You don't need to create a dedicated SAS policy for each device or publisher. Please note that a publisher should only own a token signed for itself and should not be able to access the SAS policy key.
Feel free to check the publisher policy document here for more details.
I'm building a serverless application with AWS Lambda and API Gateway. In order to prevent DDOS attacks doing a large number of requests costing me lots of money, I've set up a usage plan with a request quota (e.g. 10K requests/month). This requires an API key to be passed as header by callers.
This seemingly works well, but I also need to enable CORS for this service. For that I need to allow for an unauthorized OPTIONS request ("CORS preflight" request) as browsers don't support sending any special header there. But then I can't seem to find a way for enforcing a quota and I'm back to square one: an uncontrolled number of those requests could cost an unforeseeable amount of money. Is there any way to exclude this possibility?
To enforce a quota on OPTIONS requests, create a web ACL in AWS WAF & associate it to a stage of your API in API Gateway. Add a rate-based rule in the web ACL that blocks all OPTIONS requests beyond the rate limit you specify. Rules in web ACLs can be configured specifically for this, as shown below:
For a screenshot-guided tutorial of this entire process, see my blog post.
You are not paying for any unauthorized calls to API-Gateway.
AWS is picking up this charge.
You are paying after the request is authorized and only if it does not exceed your usage plan.
So if somebody is doing a DDOS on your API without authentication it is free of charge.
If somebody is doing a DDOS with a valid api key you will only pay until your usage plan is exceeded.
Find more information here.
Requests are not charged for authorization and authentication
failures.
Calls to methods that require API keys are not charged when API keys
are missing or invalid.
API Gateway-throttled requests are not charged when the request rate
or burst rate exceeds the preconfigured limits.
Usage plan-throttled requests are not charged when rate limits or
quota exceed the preconfigured limits.
So make sure to have authentication enabled on your API and a usage plan in place for all the authenticated requests.
For a stage belonging to an API in AWS API Gateway I have the option to limit Default Method Throttling. Does this limit the total number of requests per second, or the number of requests from a particular client per second?
Default Method Throttling (like Account Level Throttling) is the total number of requests per second across everyone hitting your API.
Client-level limits are enforced with Usage Plans, based on api-keys.
For more detailed information about API Gateway throttling checkout:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-usage-plans.html
If I create a public endpoint using AWS API Gateway, the entire world could access it. This would be a problem because the end point would trigger an AWS Lambda function. If we assume that I can't query a data source to determine the frequency that the incoming IP address queried the resource in the past, what would be the best practice for protecting this end point from abuse? Do I have any other security options?
I realize I could use a reCaptcha but this would still invoke the AWS Lambda function and would incur costs if done a million times over a short window of time.
A very simple way of protecting your API gateway
Use AWS Cloudfront with TTL 0 and pass custom headers from AWS Cloudfront to API gateway
Use AWS WAF with AWS Cloudfront
AWS API Gateway also handles some basic level of DDOS attacks.
Kindly also view these blogs for securing AWS API Gateway
https://aws.amazon.com/blogs/compute/protecting-your-api-using-amazon-api-gateway-and-aws-waf-part-i/
https://aws.amazon.com/blogs/compute/protecting-your-api-using-amazon-api-gateway-and-aws-waf-part-2/
You are probably looking for throttling limit configuration or usage plan definition:
To prevent your API from being overwhelmed by too many requests,
Amazon API Gateway throttles requests to your API using the token
bucket algorithm, where a token counts for a request. Specifically,
API Gateway sets a limit on a steady-state rate and a burst of request
submissions against all APIs in your account. In the token bucket
algorithm, the burst is the maximum bucket size.
When request submissions exceed the steady-state request rate and
burst limits, API Gateway fails the limit-exceeding requests and
returns 429 Too Many Requests error responses to the client. Upon
catching such exceptions, the client can resubmit the failed requests
in a rate-limiting fashion, while complying with the API Gateway
throttling limits.
As an API developer, you can set the limits for individual API stages
or methods to improve overall performance across all APIs in your
account. Alternatively, you can enable usage plans to restrict client
request submissions to within specified request rates and quotas. This
restricts the overall request submissions so that they don't go
significantly past the account-level throttling limits.
References:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-usage-plans-with-console.html#api-gateway-usage-plan-create
I have published an API with tier availability as bronze.
When I subscribe to that API as a different user in the store, bronze will be the only available tier to subscribe.After subscription, when I try accessing the API, I am able to hit it many times in a minute without any restriction. Why does it not restrict me for 1 request per minute?
Thanks
Are you using your local install of WSO2 API Manager or API Cloud service? In API Cloud, the tiers are all presetup and work flawlessly as far as I can tell.
For your local API Manager set up the couple things I would look at are:
Check whether the APIs that you set up require authorization - if you set them up as public without authorization key requirement - then I think there is no tier enforcement either because your tier cannot be verified without authorization.
Check your ties.xml to ensure that the throttling level for the tier is properly set up: https://docs.wso2.com/display/AM170/Managing+Throttling+Tiers