When you start creating new elements in your API Management, consider the following recommendations.
The order of policies is important and has a huge impact on the applied rules, e.g. use the BASIC Authentication policy before the Rate Limiting policy. Otherwise unauthorized requests will reduce the rate limit. |
Level | Recommendation |
---|---|
API | On API level, you will typically use modification policies, such as URL Rewriting or API Key. |
Plan | On plan level, you will typically use limiting policies, such as Rate Limiting. This way, each plan will allow for a different amount of requests. |
Client | On client level, you will typically apply authentication and authorization policies, such as BASIC Authentication or Authorization, or other security policies. |
For detailed explanations about the usage of policies, the policy chain and the policies available in Scheer PAS API Management, go to page Policies.
API keys are not encrypted and visible:
So, API keys need to be handled in a secure way - otherwise attackers may be able to use the API key to gain access to your system.
As per definition, API keys are used to identify technical clients only and, subsequently, to apply related policies. Do not use API keys to authenticate users. |
Authentication should always be implemented via a dedicated security policy (see Policy Configuration, category Security Policies and page API Security: Authentication and Authorization).
Do not delete APIs, plans, or clients and recreate them if you want to change policies or settings. Instead:
If your clients have been granted access to a developer portal (see Developer Access to APIs), they can try out your APIs using a testing UI. To be able to easily use your APIs, it is important to provide them with extensive API documentation.
API With Good Documentation
API Lacking Documentation
Refer to Documenting a REST Service for more information on REST documentation and how to add documentation to xUML services.