{ Community }
  • Academy
  • Docs
  • Developers
  • Resources
    • Community Articles
    • Apigee on GitHub
    • Code Samples
    • Videos & eBooks
    • Accelerator Methodology
  • Support
  • Ask a Question
  • Spaces
    • General
    • Edge/API Management
    • Developer Portal
    • API Design
    • APIM on Istio
    • Extensions
    • Business of APIs
    • Academy/Certification
    • Analytics
    • Events
    • Integration (AWS, PCF, Etc.)
    • Microgateway
    • Monetization
    • Private Cloud Deployment
    • Insights
    • IoT Apigee Link
    • BaaS/Usergrid
    • BaaS Transition/Migration
    • Apigee-127
    • New Customers
    • Topics
    • Questions
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Academy/Certification /
avatar image
0
Question by Emilia Ipate · Jul 11, 2016 at 08:56 PM · 172 Views policiesspike arrestbusiness

spikeArrest as a solution to provide privileged access to API

Hi there,

In the Foundation Training > Securing your API > SpikeArrest from academy.apigee,com, video min 06:13, it is mentioned that spikeArrest can be used as a business usecase where "you have a spikeArrest set to a particular value for particular applications that are associated with particular products. Product A has 100tps against this backend while Product B has 50tps they can do against this backend".

I don't understand how exactly the <identifier> can be used in such case to provide privileged access to APIs. Can you please post a working example?

Thank you a lot,

Emilia

Comment
Add comment
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Close

1 Answer

· Add your answer
  • Sort: 
avatar image
2

Answer by sudheendras   · Jul 12, 2016 at 01:23 AM

Hi @Emilia Ipate Welcome to Apigee Community!

If you use a simple SpikeArrest policy (like below) without an identifier, it's applied to all API calls.

<SpikeArrest name="SpikeArrest">
  <Rate>20ps</Rate>
</SpikeArrest>

Using <Identifier> tag you can uniquely identify and apply spike arrest against individual apps or developers. For e.g. This spike arrest policy restricts 30 transaction/second, per App (identified by API key).

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
    <DisplayName>Custom label used in UI</DisplayName>
    <Rate>30ps</Rate>
    <Identifier ref="request.queryparam.apikey"/>
</SpikeArrest>

As you can see the <Rate> element is hardcoded to 30 per second. You can also make this dynamic by referring to custom variable defined in an API Product E.g. In this configuration, we are referring to a custom attribute called 'spikearrestlimit' and applying it on individual apps.

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
    <DisplayName>Custom label used in UI</DisplayName>
    <Rate ref="verifyapikey.Verify-API-Key-1.apiproduct.spikearrestlimit"/>
    <Identifier ref="request.queryparam.apikey"/>
</SpikeArrest>

To support your scenario, you would set spikearrestlimit to '100ps' for Product A and '50ps' for Product B.

Hope this helps!

Comment
Add comment Show 3 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Emilia Ipate · Jul 12, 2016 at 07:12 AM 0
Link

Hi @sudheendra1,

Thank you for your answer. I understand it but it raises some extra questions for me.

Let's say I use the spikeArrest policy as a business usecase to allow application App1 to make 30ps on backend Bk1 and 50ps on backend Bk2, while application App2 to make 20ps on backend Bk1 and 40ps on backend Bk2.

Then, if I understand correctly, I need at the application level 2 custom attributes: "spikearrestlimit_for_bk1" and "spikearrestlimit_for_bk2".

Using these custom attributes can easily become unmaintainable when dealing with allowing privileged access to 10 backend services because:

- I need to specify unique attribute name for each backend.

- the operation person who will manually indicate the values for each application needs to type correctly each custom attribute.

- the spikeArrest policy needs a complex javascript to check which policy applies: if filled in then the custom attribute on the app level otherwise if filled in the custom attribute on the product level otherwise the default level in the target endpoint.

There must be an easier solution to solve this situation by organizing better the API proxies, products. Could you please advise?

Thank you,

Emilia

avatar image sudheendras ♦ Emilia Ipate   · Jul 12, 2016 at 01:51 PM 0
Link

Hi @Emilia Ipate It's recommended to use a SpikeArrest policy to protect your target backend against severe traffic spikes and denial of service attacks. If your requirements are around business use cases then use the Quota Policy instead. The Quota policy gives you more flexibility. You can apply a Quota at both API Product and API proxy level. Like SpikeArrest you can apply Quota based on Apps & Developers as well.

Typically you group your APIs into Products and apply a limit. Let's say based on the subscription level : Gold, Silver and Platinum and apply three different quota limits. If you like to set different limits per API proxy, then configuration might become messy & soon become unmaintainable as you rightly indicated.

You can place policies sequentially and put a conditional statement to see a policy needs to be executed or not. You don't need to do this check in JS. You need to be careful though. As the combinations increase your proxy configuration becomes complex.

avatar image Emilia Ipate sudheendras ♦ · Jul 13, 2016 at 09:05 AM 0
Link

Hi @sudheendra1,

You suggest that I can put policies sequentially... I don't fully understand this solution:

- I should add a quotaLimit policy which runs if the "limit" custom attribute at application level is filled in

- I should add a quotaLimit policy which runs if the "limit" custom attribute at product level is filled in

But it's possible that both attributes are filled in and then both policies will run when in practice I want only the limit set at the application level to run because it overrides the product quota.

Your answer

Hint: You can notify a user about this post by typing @username

Up to 5 attachments (including images) can be used with a maximum of 5.0 MB each and 25.0 MB total.

Follow this Question

Answers Answers and Comments

33 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

  • Products
    • Edge - APIs
    • Insights - Big Data
    • Plans
  • Developers
    • Overview
    • Documentation
  • Resources
    • Overview
    • Blog
    • Apigee Institute
    • Academy
    • Documentation
  • Company
    • Overview
    • Press
    • Customers
    • Partners
    • Team
    • Events
    • Careers
    • Contact Us
  • Support
    • Support Overview
    • Documentation
    • Status
    • Edge Support Portal
    • Privacy Policy
    • Terms & Conditions
© 2019 Apigee Corp. All rights reserved. - Apigee Community Terms of Use - Powered by AnswerHub
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Create an article
  • Post an idea
  • Spaces
  • General
  • Edge/API Management
  • Developer Portal
  • API Design
  • APIM on Istio
  • Extensions
  • Business of APIs
  • Academy/Certification
  • Analytics
  • Events
  • Integration (AWS, PCF, Etc.)
  • Microgateway
  • Monetization
  • Private Cloud Deployment
  • Insights
  • IoT Apigee Link
  • BaaS/Usergrid
  • BaaS Transition/Migration
  • Apigee-127
  • New Customers
  • Explore
  • Topics
  • Questions
  • Articles
  • Ideas
  • Members
  • Badges