One of the key drivers for using IBM API Connect is its ability to provide enterprise grade security for the API providers. IBM API Connect (APIC) provides multiple features which can be used for easily securing APIs. These features can also be used in combination to implement a defence-in-depth strategy.API Connect Security Features
1. DataPower Gateway: APIC uses IBM DataPower Gateway (DataPower) to realize its gateway functionality. DataPower is available as physical appliance running locked down secure firmware. This greatly reduces the risk vector making it suitable for DMZ deployment. Some other key features of DataPower which enhances API security are:
a. DDoS Protection, explained here
b. XML and JSON Threat Protection
c. SQL Injection Protection
The APIs on APIC are hosted and processed fully in the gateway alone, this ensures all requests are “processed” within the secure DataPower confines only.
2. TLS Profiles: The integration with both providers and consumers can be secured at the transport layer via TLS profiles. This can be used to ensure that the connection channels are authenticated, private and reliable. APIC v10 provides support for the latest standard TLS 1.3 too.
The TLS profiles can be used to protect inbound and outbound traffic separately. They can be one-way or enforce mutual authentication. The profiles can also be segregated by provider.
Please refer to https://developer.ibm.com/apiconnect/2018/09/14/tls-profiles-ibm-api-connect/
to learn more about various TLS profile configuration option in API Connect.
When should this be used?
TLS can be used when there is a need to secure network layer transportation of data.
3. Mutual Auth using Application Certificates: API Connect also supports the identification of connecting application using mutual authentication which relies on certificates that can be validated at the API layer. When consumers create their application to use the API, they use the required certificate. The client then uses this certificate or pass it as header while making connection to the API server. This certificate detail can be then validated in the API implementation using the variables described at https://www.ibm.com/support/knowledgecenter/SSMNED_v10/com.ibm.apic.toolkit.doc/rapim_context_var.html#rapim_context_var__cert-variables
The article https://developer.ibm.com/apiconnect/2018/09/28/oauth-2-0-mutual-tls-certificate-bound-access-tokens-ibm-api-connect-v5-0-8/
describes how mutual auth using certificates was used to securely generate tokens. The same principles can be used to secure any API.
When should this be used?
Application certificates can be used to ensure that the connecting application is a trusted application. This can be used to provide additional security for the API.
4. Message Level Security: API Connect supports message level security through signing and encryption. Besides providing native support for certificates through Crypto Objects, API Connect also allows integration with JSON Web Key (JWK) and specialised Hardware Security Modules (HSM) for greater security.
b) HSM: DataPower supports both factory-fitted HSM modules and integration with network SafeNet Luna HSM appliance. They can be used where there is a requirement to provide FIPS 140-2 Level 3 support for cryptographic security standards.
When should this be used?
Message level security is the most commonly used way to secure APIs. Message signing is used to verify the identity of the sender while encryption can be used to ensure privacy of the messages.
5. Security Profiles: Besides providing certificate-based message level security, API’s can be secured through multiple other built-in and extensible approaches. Let’s discuss these built-in approaches:
a) Basic Authentication – The API client passes user credentials in the HTTP authorization header as Basic Authentication type which can be then validated against either an LDAP registry or an authentication URL.
b) Client ID (and Client Secret) – This is another simple mechanism to secure the API. They are generated while creating the consumer application. Using a Client ID security profile ensures that only registered users can access the API. If client secret is also used, it validates the caller against the registered authentication details.
c) Native OAuth, OIDC – APIC supports OAuth RFC6749, the token-based authorization protocol to allow access to resources without giving out the credentials of the consumer. When using the built-in OAuth/OIDC security profile, APIC acts as the OAuth/OIDC provider.
A sample OAuth implementation is described at https://community.ibm.com/community/user/imwuc/viewdocument/secure-apis-using-oauth?CommunityKey=2106cca0-a9f9-45c6-9b28-01a28f4ce947&tab=librarydocuments
APIC also supports PKCE RFC 7636, which is an extension to OAuth to further harden the security for authorization code grant flow. To learn more about PKCE and how it can be implemented with APIC please refer to https://developer.ibm.com/apiconnect/2018/07/09/leveraging-pkce-oauth2-api-connect-v5/
d) Third party OAuth, OIDC: APIC also supports third party OAuth/OIDC token validation through Introspection URL as described in RFC 7622. This is useful when customers want to reuse an existing OAuth/OIDC provider but want to use APIC as the gateway.
e) JWT: JSON Web Token (JWT) can be used to securely exchange claim, for example user data, in the form of tokens. These tokens can be encrypted, signed or both.
JWTs are widely used as session tokens, generated once the user has authenticated. APIC can be used to generate JWT and then validate it in subsequent calls. Please refer to https://developer.ibm.com/apiconnect/2016/08/16/securing-apis-using-json-web-tokens-jwt-in-api-connect-video-tutorial/
to understand JWT can be used to secure an API.
f) Custom security variations can also be implemented using gateway scripts, for example:
i) JWS detached signature as described at RFC 7797. This is used when we want to ensure that the integrity of the message is not compromised using signing certificates, but the payload isn’t in JWS format. An extra header containing the detached signature is added in the request by the client which can be verified within the API by comparing the header and jws derived using the payload.
ii) JWT Assertions as defined in RFC 7523 can be used to request an access token when a client wishes to utilize an existing trust relationship and avoid the user re-authentication. The following article describes a sample implementation: https://medium.com/@tom_91498/client-assertion-grant-type-with-ibm-api-connect-5aa50bfb3f46
6. Rate Limiting
API Connect provides the ability to restrict the usage rate of its API. Combinations of APIs are offered as products and these products can have multiple plans which are assigned rate-limits and throttle limits. The consumer subscribes to a rate plan and is thus restricted by the limits of the plan for a specific application.
This security feature, driven by DataPower, helps protect the systems where the Provider APIs are deployed from undue load. This can also be used to provide varying quality of service to the different API consumers.Conclusion
We have discussed various ways in which API providers can use API Connect to secure their APIs. This is extremely helpful as it helps in offloading security concerns from the API providers and also provide consistent security policies across multiple APIs as well as multiple providers.
If you are interested to learn more about APIC or security with APIC, please visit
- Principles for API Security : https://community.ibm.com/community/user/imwuc/viewdocument/principles-for-api-security-white?CommunityKey=2106cca0-a9f9-45c6-9b28-01a28f4ce947&tab=librarydocuments
The author is grateful to Aiden Gallagher for reviewing the article and providing invaluable inputs.