The last few sections provided a comprehensive overview of APIC’s OOTB security features to secure APIs. But by no means are these the only security features that you can use. You can build almost any security mechanism using a combination of user-defined policies and GatewayScript policy. You can further secure your services using Transport Layer Security (TLS) profiles, a User Security policy (for authentication and authorization), a Client Security policy, and even apply a SAML-based authentication to your OAuth provider. SAML and OAuth integration can be achieved by modifying your OAuth provider implementation to include a GatewayScript policy (to extract the SAML assertion from a request), a Client Security policy (to pass the SAML assertion to an authentication registry), and a custom authentication registry endpoint to validate the SAML assertion. You can build your authentication endpoint (for SAML assertion validation) within DataPower and expose it to APIC. Refer to Figure 7.34:

Figure 7.34 – Overview of SAML and OAuth integration

Again, the possibilities of expanding upon OOTB features are limitless because of the built-in flexibility of the APIC components. As the saying goes, “The sky’s the limit”.

Summary

This chapter covered multiple methods provided by APIC to secure the APIs (or resources, as they are often called). Security is a vast and multi-layered subject, one of the most critical layers being authentication of parties seeking access to these Resources. These parties could be a typical user, a Resource Owner, or a Client/Application that intends to access these Resources. A comprehensive platform, such as APIC, provides many techniques to apply security to its protected Resources, and authenticate various parties that are trying to access these Resources.

This chapter was about exploring details of many such API security methods provided by APIC. All the security methods, except for the API Keys method, depend upon the setup of a user registry. If the security mechanism is OAuth and OIDC, then the setup also requires setting up an OAuth provider resource first. You covered these setups in the early part of this chapter. In the Preparing for the APIC security implementation section, you reviewed the LUR and performed the detailed steps for setting up an Authentication URL registry. You were also introduced to the LDAP user registry and OIDC user registry (this is only used for APIC user authentication).

The rest of the chapter was dedicated to exploring various security methods to secure the APIs through examples. You built examples to secure the APIs using the API key (client ID and client secret) method, Basic authentication using the Authentication URL user registry, OAuth/OIDC security, and by using JWT policies.

In each of these examples, you also learned the testing methodology to test secured APIs.

With all this information, you can appreciate the lengths and depths the APIC framework goes to in order to fulfill the API security needs of various audiences while keeping up with the latest industry security standards. Hopefully, by applying this knowledge, you can now secure your APIs and protect them from any kind of unsolicited access from rogue actors out there. Let’s all of us do our part to “keep it safe” out there! You will next learn one of the other critical aspects of APIs – message transformations.