Unlike Chapter 4, API Creation, and Chapter 5, Modernizing SOAP Services, which utilized local development tools such as API Designer and Local Test Environment (LTE), this chapter will require you to have access to an existing APIC cloud implementation. This APIC cloud access can be provided by your company’s APIC cloud administrator.

The exercises in this chapter will require you to have the following access:

• API Manager UI.
• Access to the mock authentication URL service: http://httpbin.org/basic-auth/user/passwd. This service returns HTTP Response Code 200 for the username=user and password=pass credentials. For any other username and password values, this service returns HTTP Response Code 401.
• Access to https://stu3.test.pyrohealth.net/fhir/Patient/d75f81b6-66bc-4fc8-b2b4-0d193a1a92e0 from your API Gateway.
• Access to a curl tool for executing tests.

Once you have access to these, you are ready to start exploring various API security features available in APIC.

Out-of-the-box security capabilities of APIC

When securing APIs with APIC, you are provided with three out-of-the-box security capabilities that can be applied. These are as follows:

• API key: This method involves configuring Client ID and Client Secret security definitions as part of defining an API. Once defined in the API’s Security definition, a consumer may pass values for these API keys as part of a request’s query (X-IBM-Client-Id, X-IBM-Client-Secret) or header (client_id, client_secret).
• Basic authentication: This option allows you to perform API authentication by validating the supplied credentials against an Authentication URL or an LDAP-based user registry.
• OAuth: The OAuth option allows us to secure APIs utilizing the standards set forth for OAuth2 (and OIDC).

These three capabilities should generally solve most of your API security concerns. When choosing between these security capabilities, you utilize a two-step process within an API definition. Figure 7.1 identifies these two steps:

Figure 7.1 – Out-of-the-box security options

Step 1 is where you either choose or create a new security scheme. In step 2, you apply one or more of the security schemes to your API. The OpenAPI Specifications (OAS) terminology identifies these steps as Security Definition and Security Enforcement (or Security).

Of these three OOTB security options, the utilization of the API key method requires implementing only steps 1 and 2 described here. There is no further setup needed for the API key, whereas Basic authentication (Basic) and OAuth2 methods require you to separately create security providers before these can be utilized in the security scheme step. You will learn how to accomplish this next.

Preparing for the APIC security implementation

Basic authentication and OAuth2 require integration with various servers. They require configuring resources (user registries and OAuth providers) in the Cloud Manager or API Manager. As an architect or administrator, you will need to know how these resources are accomplished. As a developer, you will only be concerned about having access to the configured and functioning resources. This section will give a high-level introduction on how resources are configured for utilization by the provider organization’s developers. Figure 7.2 shows you the Resources configuration page:

Figure 7.2 – Configuring Resources

This page is available in API Manager and Cloud Manager interfaces under Home | Manage resources. It allows creation of the user registries (Local, LDAP, Authentication URL, and OIDC), TLS references, OAuth providers, and Billing. The security components described in this chapter revolve around user registries and OAuth providers. You will be creating these resources in the API Manager interface.

While there are many variations on how you can create these resources, here you will learn how to configure a simple user registry and an OAuth provider. You will learn to define a user registry next.

Note

You must have the necessary permissions to the API Manager to perform these tasks. Typically, you should belong to either of the following two roles to be able to manage user registries: Organization Owner or Administrator.