This is part 3 of my API security blog series. I will be showing an example scenario of how Anypoint platform can be a vital component of a secure API-led architecture and the capabilities to securing the API.
If you missed part 1 and part 2 here they are:
3. Mule runtime Security Capabilities
The Mule runtime addresses a broad set of security concerns with best practice solutions for transport and message level security. Your API can be hosted by Mule, exposed over HTTPS and can facilitate TLS client authentication. Likewise, your API can make calls out to servers over HTTPS and issue client certificates as needed. Keystores and truststores are used to store TLS certificates for these scenarios. Messages that are sent to exchanges and queues on Anypoint MQ, MuleSoft’s cloud messaging solution, can be encrypted. The Mule runtime can also encrypt and decrypt messages, digitally sign them and verify the validity of incoming digital signatures. IP white and black-listing is also available. With these capabilities, the Mule runtime addresses the concerns of exposing highly available APIs that authenticate and authorize incoming calls while guaranteeing message integrity and confidentiality.
3.1 Message Confidentiality on the Mule runtime
3.1.1 Mule HTTPS Connector
An HTTPS listener can be configured with reference to a keystore so that your API can authenticate itself to the App. When client authentication is demanded from the App, the listener can reference a truststore. Similarly, when your API needs to interact with a Server over HTTPS, you can use an HTTPS requester which references a keystore to authenticate itself and a truststore for when digital certificates are not recognizable by the standard Java JDK truststore (cacerts).
3.1.2 Mule Encryption Processor
The Mule Message Encryption Processor can change the content of a message so that it becomes unreadable by unauthorized entities. Mule can encrypt the entire payload of a message or specific parts of the payload, according to security requirements, using different encryption strategies.
3.1.3 Dynamic Data Filtering with DataWeave
For ABAC scenarios (see Attribute Based Access Control 1.3.2) you will need to filter the payloads that your API sends back to Apps based on the degree of access determined either for the App or for the User. DataWeave is Mule’s data transformation engine which transforms between different mime-types using a simple expression language which is common across all data formats. The language can be used to remove and / or mask data fields in the payload, whatever the structure of the payload and the location of the field. The same expression can be stored in a datastore and ‘blindly’ executed by the engine at runtime. In this way you can cater for dynamic transformation logic that you may not necessarily be able to configure at design time. Rather, at runtime based on criteria decided at runtime, you can choose a transformation and apply it to the payload.
3.2 Message Integrity on the Mule runtime
Exposing your API over HTTPS guarantees that it has not been modified in transit. However, authentication andauthorization of the request still need to take place.
3.2.1 Mule Security Manager
Central to authentication in Mule is Mule Security Manager. This is the bridge between a standard mule configuration and Spring Security beans.
3.2.2 Mule Secure Token Service OAuth 2.0 Provider
Mule can act as an OAuth2 Provider, issuing tokens to registered Apps, applying expiration periods to these tokens and associating them to User roles and fine-grained access control known in the OAuth world as scopes. Refresh tokens can also be issued and tokens can be invalidated. Mule can subsequently validate incoming tokens against expiration periods, roles and scopes and thus grant or deny access to the flows in the Application. Scopes represent broad levels of access to the Mule flows. The provided access token must be sent in with each request and can be validated by Mule to ensure it has not expired or been revoked and that it has the scopes that correspond to a particular flow. More fine grained control can also be applied by comparing the role of the user for whom the token was issued with the allowed roles for the flow. The validate filter has a resourceOwnerRoles attribute to specify these. The granularity of access control can be in either the grant or the role.
As we extend APIs outside of our organization we may have to cater for applications belonging to partners. Imagine we were to dynamically expose access to your API to a mobile application. We need only register this new client in your OAuth 2.0 Provider configuration.
3.2.3 Mule Digital Signature Processor
Mule Digital Signature Processor adds a digital signature to a message payload, or part of the payload, to prove the identity of the Message’s sender. Mule can also verify a signature on a message it receives to confirm the authenticity of the Message’s sender.
3.2.4 Mule Credentials Vault
Mule Credentials Vault is for the encryption of properties which are referred to and decrypted by the Mule application at deployment time. These properties are encrypted with a variety of algorithms and are completely hidden from anyone who does not have the key to the credentials vault. At deployment time, the key is passed to Mule as a system property. This key should only be in the hands of authorized personnel.
3.3 API Availability with Mule HA Clusters
A single Mule server hosting your API is not enough to facilitate high availability. To achieve this, you need to host the same API on more than one Mule runtime. With a load balancer in front of the API, you can guarantee that the API will always handle incoming requests as the load balancer chooses between those instances which are healthy.
Reliability on Mule can be achieved by clustering two or more instances of Mule together which is easy using Anypoint Runtime Manager. In this scenario, we configure the Mule VM endpoint as a reliable handoff mechanism immediately after receiving the Message. Another flow processes the Message from that same VM endpoint. If the Mule node which receives the Message from the VM goes down, then another Mule node on the same cluster will pick up the same Message. For reliable processing of Messages between multiple APIs you can use Anypoint MQ (see Anypoint MQ 4.2).
4. Anypoint Platform Security Capabilities
4.1 Anypoint Platform API Solution
Anypoint Platform API Solution is a fully multi-tenant application running on top of Amazon Web Services (AWS) and inside a VPC (cloud VPN). Data, metrics, and metadata cannot be accessed across organizations.
Although Anypoint Platform can manage and enforce the runtime security of your API, the API itself remains wherever you have it deployed. Only the configuration of the policies, metadata about your API and analytics about the usage of your API is stored in Anypoint Platform.
4.1.1 API Adaptability through policies on API Manager
API Management is a discipline which addresses the need to publish your API for consumption by known Apps, registering those Apps and provisioning them with their own ID and secret identifiers, authorizing the Apps to consume your API and adapting the APIs to the potentially different security requirements across the Apps.
The adaptability is addressed with what we call policies. These are encapsulations of the types of logic that usually recur across your APIs. Similar to how aspect oriented programming worked, these logical bundles can be applied to or removed from running APIs without affecting their lifecycle. Security is a prime example of such logic. We explore security policies next.
4.1.2 Secure Communication between the Mule runtime and API Manager
Using the Mule runtime as an API gateway you can host your API. The Mule runtime communicates constantly with Anypoint API Manager to retrieve policies and report back analytical information about the usage of your API. This communication is initiated by the Mule runtime which authenticates itself with OAuth 2.0 Client Credentials. You configure the Mule runtime with a client ID and secret which is configured for your particular organization (or business group) in Anypoint Platform. The ID and secret are used by the Mule runtime to get an OAuth 2.0 token to be used in subsequent calls. All calls are to a RESTful service which is accessible over HTTPS. The Mule runtime is insulated from external network outages since it stores a local cache and can continue to operate even if the Anypoint Platform were to
become unavailable. Regardless, MuleSoft maintains an SLA of 99.99% for Anypoint Platform API solution. Anypoint Platform is certified via WhiteHat Sentinel.
4.1.3 Security Policies
We must return to our discussion about Identity in the light of what Anypoint Platform has to offer in its suite of policies. Some of the following policies are inherently dependent on a mechanism to verify incoming Identity tokens. All of them address security concerns:
- Client ID enforcement: locks down your API for consumption only by a set of known clients.
- SLA-based Throttling: same as Rate Limiting only exceeded calls are queued for next time window.
- HTTP Basic authentication: authenticates using credentials which are configured in a security manager underlying this policy.
- IP blacklist and whitelist: denies or permits calls from only from IP addresses present in this list.
- JSON and XML threat Protection: guarantee the safety of the messages passed to your API.
- SLA-based Rate Limiting: provides different quality of service contracts to your known clients, 10 calls a minute for some, 100 calls a second for others, etc.
- Mule OAuth 2.0 access token enforcement: validates incoming tokens previously issued by Anypoint OAuth Provider upon receipt of client ID and secret.
- External access token enforcement: validates incoming tokens previously issued by PingFederate or Open AM OAuth Provider upon receipt of client ID and secret.
- Cross-origin resource sharing (CORS): permits your API to be invoked by a JavaScript client (an Angular App, for example) which is hosted on a domain different to your API.
The Mule runtime stores the client IDs and secrets of consuming Apps in an Identity Store. When you register a new consuming App in the API Portal, Anypoint Platform generates a new App ID and secret and persists it. Later, when any identity related policy, like SLA based throttling, is applied to your API, the Mule runtime downloads the policy and also downloads the ID and secret for every consuming App registered to consume your API. Thus, when the Mule runtime injects the Policy configuration into your API, it also provides access to a local embedded database of IDs and secrets which the Policy consults to verify the identity of the calling App. When you choose to integrate your Anypoint Organization with an external identity management technology like PingFederate, this assumes the role of administering
and persisting App ID and secrets.
4.1.4 Custom Security Policies
Policies on the Anypoint Platform are snippets of Mule Configuration. As such, custom policies are very easily configurable and can be surfaced on the API Manager portal as siblings to our out-of-the-box policies.
We have a number of custom policies published to Anypoint Exchange. These cover SAML based security use-cases such as the ability to validate incoming assertions, or username tokens.
You can write your own policy to cover any area of logic that is pertinent to your API. For the ABAC scenarios that we described above, you might consider configuring a custom policy which accepts either a full DataWeave expression in the API Manager portal UI at policy application time. This can be executed at runtime on the response payload. (See Dynamic Data Filtering with DataWeave 3.1.3)
If you wish to protect your API with OpenID Connect, you should consider writing a custom Policy to validate incoming tokens against the Authorization Server.
4.2 Anypoint MQ
This is a multi-tenant cloud messaging service offering persistent data storage across multiple data centers, ensuring that it can handle data center outages and have full disaster recovery. For compliance with your data at rest policies, Anypoint MQ allows you to encrypt all messages that arrive in either an exchange or a queue.
4.3 Anypoint Platform Virtual Private Cloud
Mule applications can be deployed either to your on-premises Mule runtime or to our fully hosted and fully managed iPaaS. In most scenarios, Mule applications deployed to the iPaaS will need to integrate with systems in your datacenter. In some cases a hybrid architecture is adopted where Mule applications deployed to the iPaaS must integrate with Mule applications deployed to Mule runtime on-premises. Either way there is a need to establish a secure network between the
cloud and your datacenter.
Virtual Private Cloud (VPC) enables you to connect your organization in Anypoint Platform to your corporate data centers – whether on-premises or in other clouds – as if they were all part of a single, private secured network. You can configure these networks at hardware or software levels.
VPC can be configured to use IPSec, TLS (over OpenVPN) or Amazon VPC peering to connect to your on-premises data centers. IPsec connections can be configured at the hardware level in addition to a software client. If you already use Amazon, you should use VPC peering. Otherwise, IPsec is in general the recommended solution for VPC to on-premises connectivity. It provides a standardized, secure way to make connections and integrates well with existing IT infrastructure
such as routers and appliances.
4.4 Anypoint Platform User Roles and Permissions
In Anypoint Platform, users belong to an organization and have a set of roles and permissions. API versions and deployment environments are grouped under organizations (and optionally under Business Groups too), to access them you need to have an account that owns the necessary permissions and that belongs to its corresponding organization – and to the Business Group if the resource exists in one.
Roles and permissions can be granted for accessing resources that exist in the master organization, or for resources that exist within a Business Group. A user that owns any role of a business group is implicitly granted membership in the Business Group.
Each role contains a list of permissions that define what a user that holds that role can do with the specific resources it scopes. Permissions can also be added at an individual user level, without the need for roles. There are two different types of permissions: those that are for API versions and those that are for iPaaS environments. Keep in mind that API permissions are API version specific and iPaaS permissions are environment specific – they grant you the ability to do
something within a particular API version / environment, not the entire organization. The only exceptions to that rule are the roles API Versions Owner – which grants ownership of all APIs and all of their versions within the corresponding Business Group – and Portals Viewer – which grants viewing access to all portals in the corresponding Business Group.
4.4.1 Federated User Access to Anypoint Platform
Anypoint Platform can be integrated with your organization’s external federated identity provider. Opting to use federated identity management for Anypoint Platform gives your users single sign-on access and facilitates OAuth security for APIs using the same identity management system. Anypoint Platform supports SAML 2.0 identity providers for user management, the following ones were successfully tested working with the platform:
- PingFederate
- OpenAM
- Shibboleth
- Okta
- ADFS
You can set up your Anypoint Platform organization so that when a SAML user belongs to certain groups, it will automatically grant certain equivalent roles in the your Anypoint Platform organization.
5. Anypoint Platform Security Compliance
When Anypoint API Manager manages APIs from the cloud, it stores only metadata about the APIs and the Apps which consume them. The APIs can be deployed on the Mule runtime either on-premises or in our fully hosted, fully managed iPaaS solution. The extent to which Anypoint Platform is compliant with external audits is detailed in the whitepaper “Anypoint Platform Cloud Security and Compliance”. We summarize them here:
- FIPS 140-2: the US government security standard that requires that compliant parties use only cryptographic security modules that have
been certified by NIST. Mule can be configured to run in a FIPS 140-2 certified environment. Note that Mule does not run in FIPS security
mode by default. There are two requirements: - 1. Have a certified cryptography module installed in your Java environment
2. Adjust Mule settings to run in FIPS security mode
SSAE-16 SOC 2: a regular audit report that states whether or not we are compliant with the policies we give our customers. We get these
every January. - PCI DSS Level-1: PCI compliance is a set of requirements designed to ensure that all companies that process, store or transmit credit card
information maintain a secure environment. We complete an onsite assessment every September. - HiTrust: a common security framework (CSF) designed to simplify compliance with technical controls derived from HIPAA/HITECH. Put
another way, it is a way for a service provider like MuleSoft to show compliance with the relevant aspects of HIPAA/HITECH to its clients.
6. Summary Scenario
Let us consider a hypothetical scenario: Mythical Retail have a chain of stores and deliver an e-commerce solution to their customers. One of their business objectives is to increase their revenue by 20% over the next 18 months. To achieve this goal they aim to improve customer loyalty by providing a compelling omnichannel digital experience. This experience will allow customers to shop with ease wherever and whenever they want, receive appropriate recommendations and offers
and see their current loyalty balance in real time. Mythical Retail wants a 360-degree view of their customers’ visits across all touch points. They aim to reward every customer interaction made online and in-store and have a clear view of their customers’ spending habits.
Mythical Retail have adopted MuleSoft’s API-led Connectivity approach to integration and see APIs as strategic assets upon which they can execute digital initiatives. They have invested in clienteling software which can help their sales associates meet and register anonymous customers in-store and identify customers already registered. This software will also provide a mobile point-of-sale (POS) experience. With APIs backboning the clienteling solution as well as the customer’s web and mobile interactions, Mythical Retail can guarantee the uniformity of the customer experience across every touch point.
6.1 Securing the Customer Transactions
Figure 10 is an overview of the APIs and Servers needed to deliver her the capability to place an order on the phone. Katie is a customer of Mythical Retail and likes to purchase online. She uses the iPhone App to make orders.
1. Katie must sign in to the App.
2. The App must authenticate itself on Katie’s behalf and consume the My Shopping API with the relevant degree of access control. Only Katie’s data must be accessible for this interaction.
3. All calls between experience, process and system APIs must be protected.
4. The Order Fulfillment API orchestrates the Orders API and the Tokenization API. The latter is exposed by a third-party credit card processing company and delivers obfuscation functionality to Mythical Retail so that Katie’s credit card details are never stored in their original form in the systems of record. The call to the tokenization API needs to be authenticated, signed and encrypted.
5.The Order Fulfillment API creates a business event which it publishes to an encrypted exchange on Anypoint MQ. The published data must be encrypted and the publication call must be signed, encrypted and authorized.
6. The Customer API subscribes to the event on Anypoint MQ and is responsible for increasing Katie’s loyalty points. The recommendations API is also registered to consume this event and gathers the details of the order to feed into future recommendations accordingly. Likewise, the Payment API subscribes to the event and finalizes the financial transaction. The shipping of orders is the responsibility of Mythical Retail ́s partner. Their Shipping API also subscribes to the same event. All of these subscriptions to Anypoint MQ must be signed, encrypted and authorized.
7. The iPhone App utilizes the Order Tracking API, which is exposed by Mythical Retail ́s partner. The partner forms a separate security context and Katie is not in their Identity Store. Her claim must be recognizable in the shipping context.
8. Interaction with the systems of record must be secured according to the requirements of each Server.
6.2 Anypoint Platform as part of the Security Fabric for Mythical Retail
Figure 11 is an overview of the APIs used to deliver the loyalty experience to Mythical Retail’s customers. All the APIs are deployed to MuleSoft’s iPaaS and managed by Anypoint API Manager. Anypoint MQ is used for messaging between the APIs and PingFederate are used as Identity Provider, MFA Provider, and OpenID Connect / OAuth Provider. All HTTP APIs in this context are protected with HTTPS, and Anypoint security policies are applied to each of the APIs using Anypoint API Manager.
1. Katie signs in to her iPhone App.
2. Part of the digital solution catering to Katie’s experience is the My Shopping API which delivers all the relevant capabilities to her iPhone App. This API is protected with the PingFederate access token enforcement policy. To consume the My Shopping API, the iPhone App must interact with the PingFederate Authorization Server to request an OpenID Connect token on her behalf. PingFederate authenticates her credentials against Active Directory. Upon successful authentication, it generates a token and signs it (see Digital Signatures 2.1.1) before responding to the iPhone App with the token. The App presents this token in a custom HTTP header on every subsequent call to My Shopping API.
3. All calls between experience, process, and system APIs are protected with the client ID enforcement policy. Each API has an ID and secret stored in Mule Credentials Vault.
4. The calls to the Tokenization API are protected with client cert authentication, and the payload passed to the API is encrypted and signed with Mule Encryption Processor and Mule Digital Signature Processor respectively before sending.
5. Publications to Anypoint MQ are protected with OAuth 2.0 and HTTPS.
6. Subscriptions to Anypoint MQ are protected with OAuth 2.0 and HTTPS.
7. There is a federated trust between the Identity Providers in both security contexts for Mythical Retail and its shipping partner. Both the sales associate’s App and Katie’s App can call the Order Tracking API with the access token that they received from PingFederate. The Order Tracking API validates the token with OpenAM, the Identity Provider of the shipping company. This can verify that the token was signed by the Identity Provider of Mythical Retail, which it trusts. The Order Tracking API accepts the invocation by the iPhone App and responds accordingly.
8.Sales associates use multi-factor authentication to sign in to their App. The App calls PingFederate OAuth 2.0 authorization server to get a token which it passes to the Shop Assistant API.
9.Interaction with the systems of record is secured in various forms according to the requirements of each Server. Tokens and username and password credentials are stored in Mule Credentials Vault.
In Conclusion
APIs are a strategic necessity to give your business the agility and speed needed to succeed in today’s business environment. But with the increasing cost of security breaches, senior IT decision makers quite rightly want assurances that exposing their data via APIs will not create undue risk. Anypoint Platform’s features provide the necessary assurances for the confidentiality, reliability, and availability of APIs designed and managed on the platform. Anypoint Platform is trusted by industries needing the highest levels of security, including 5 of the top 12 global banks, 2 of the top 5 global insurance companies and top pharmaceutical and global healthcare companies. MuleSoft has been recognized as a leader in multiple Gartner Magic Quadrants and is trusted by organizations in over 60 countries, from emerging companies to Global 500 corporations.
