Best Practices for API Security

Nial Darbey, Senior Solutions Consultant, MuleSoft
Aaron Landgraf, Senior Product Marketing Manager, MuleSoft
January, 2016
Best Practices for API Security:
Anypoint Platform Solutions

Why API security is so crucial
“The estimated financial loss from 700 million
compromised records was $400 million, which
shows the real importance of managing data
breach risks .”
• -Verizon 2015 Data Breach Investigations Report

All contents © MuleSoft Inc.
Introduction
3
• In this presentation we will show how MuleSoft’s Anypoint Platform
can ensure that your API is highly available to respond to clients and
can guarantee the integrity and confidentiality of the information it
processes.
• We will explore in depth the main security concerns around APIs and
look at how the IT industry has responded to those concerns.
• We will also present Anypoint Platform as fully capable of managing
and hosting APIs that are secure according to the highest industry
standards.

Table of Contents
4
1. Identity
2. Main Security Concerns
3. Mule Runtime Security Capabilities
4. Anypoint Platform Security Capabilities
5. Summary Scenario

Identity
6
• Identify Users, Apps and Servers
• Record of Identities
• LDAP Active Directory
• Identity Provider
Identity is core to the world of security. You must be able to recognize the Apps that consume your API, the Users
of the same and the Servers that your API calls out to. Likewise, your API should be able to identify itself to both
Apps and Servers.
Likewise, your API should be able to identify itself to both Apps and Servers.
You need an Identity Store to which you can refer to verify your recognition of Apps and Users. The Identity Store
could be a database, but an LDAP server is the most popular solution. Active Directory is a popular LDAP
implementation.
An Identity Provider is software which is dedicated to managing the interaction with the Identity Store(s) for
authentication and authorization purposes. Your API can function in this role though it is much more preferable to
delegate this responsibility to the Identity Provider.

Identity > Authentication
7
• Client and Server
• Username / Password Credentials
• Multi-factor Authentication
• Token Based Credentials
When you are presented with an App ID or a User’s username (claim) in a call to your API, you must be able to verify the
authenticity of the claim. This is done with some form of a shared secret. When your API acts as Identity Provider, it typically
authenticates the claim by passing the same credentials to the LDAP server.
The use of username / password pairs as credentials is a very common practice but it is not recommended from two
perspectives:
Passwords have a level of predictability whereas the ideal is to maximize on randomness or entropy. Also, the maintenance of
passwords is difficult. If you need to change a password then you immediately affect all Apps that make use of that password.
Recognizing the weakness of username and password credentials, an App using Multi-factor Authentication (MFA) demands
from the User a one-time usage token she receives after authenticating with her credentials.
Token based credentials are a better alternative to Username Password Credentials, which provide higher entropy and a more
secure form of authentication and authorization.

Identity > Authorization
8
• Role Based Access Control
• Attribute Based Access Control
• Delegated Access Control with OAuth 2.0
Typically, every business, enterprise or organization is divided into groups of employees
around related business functions. This group information can be used when software
Users interact with an App and you need to restrict their access according to the
authorization or access control rule in place for that software. You can use the group they
belong to in order to identify their role when using the App.
Going beyond the static assignment of roles to Users based on the organizational groups to
which they belong, Attribute based Access Control (ABAC) aims to facilitate the dynamic
determination of access control based on some sort of circumstantial information available
at the time of the API call.
The HTTP based OAuth 2.0 framework allows an App to obtain access to a resource
exposed by your API either on its own behalf or on behalf of the User who owns the
resource. Thus it allows Users to delegate access control to third party Apps.

Identity > Federated Identity
9
• Single Sign-on
• SAML 2.0
• OpenID Connect
The token based approach to authentication
allows for the separation of the issuing of
tokens from their validation and thus facilitates
the centralization of Identity Management.
The Security Assertion Markup Language
(SAML) is an industry standard which has
become a defacto standard for Enterprise level
Identity Federation. It allows Identity
Providers to communicate authentication and
authorization information about Users to
Service Providers in a standard way.
OpenID Connect is built on top of OAuth 2.0 to
provide a Federated Identity mechanism that
allows you to secure your API in a way similar
to what you would get were you to exploit WS-
Security with SAML.

Main Security Concerns
11
• Integrity
• Confidentiality
• Availability
• Users, Apps
• Clients and Servers

Main Security Concerns > Integrity
12
• Digital Signatures
• Message Safety
Message Integrity goes beyond the authentication of the App and the User and includes the
verification that the Message was not compromised mid-flight by a malicious third party. In
other words, the Message received by your API is verified as being exactly the one sent by
the App. The same goes for when your API acts as Client to a Server.

Main Security Concerns > Confidentiality
13
• Public Key Cryptography
• Digital Certificates
• Mutual Authentication
• HTTPS
It is all very well to rest assured with the Integrity of a message sent by a known App, but the
journey from App to API may have been witnessed by some unwelcome spies who got to see all of
those potentially very private details inside the message! Thus, it is necessary to hide those details
from the point of delivery by the App to the reception by the Server. An agreement is needed
between the App and API in order to be able to hide the details of the message in a way that allows
only the API to uncover them and vice versa.

Main Security Concerns > Availability
14
• Load balancing
• Clustering
• Reliability
Your API must guarantee that it is always available to respond to calls and that once it begins
execution on the call, that it can finish handling the received message right the way through to
completion without losing data.
This can be achieved by horizontally scaling the API across multiple servers and by handing off
the processing of the message to a message broker which will hold the message till the API has
completed its processing. The understanding in this latter scenario is that another process is
subscribed to this message publication and thus continues the processing asynchronously.

Mule Runtime Security Capabilities

Mule Runtime > Confidentiality
16
• Mule HTTPS Connector
• Mule Encryption Processor
• Dynamic Data Filtering with DataWeave
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.
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.
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.

Mule Runtime > Integrity
17
• Mule Security Manager
• Mule Secure Token Service OAuth 2.0 Provider
• Mule Digital Signature Processor
• Mule Credentials Vault
Exposing your API over HTTPS guarantees that it has not been modified in transit. However, authentication and
authorization of the request still need to take place.
Central to authentication in Mule is Mule Security Manager. This is the bridge between a standard mule configuration
and Spring Security beans.
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.
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 Credentials Vault is for the encryption of properties that are referred to and decrypted by the Mule application at
deployment time.

Mule Runtime > Availability
18
• Mule HA Clusters
• Anypoint MQ
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.
For reliable processing of Messages between multiple APIs you can use
Anypoint MQ.

Anypoint Platform Security
Capabilities

Anypoint Platform > API solution
20
• API Adapability with Policies
• Anypoint Gateway communication
• Security Policies
• Custom Policies
Anypoint Platform API Solution is a fully multi-tenant application
running on top of Amazon Web Services (AWS) and inside a VPC
(cloud VPN). Although Anypoint Platform can manage and
enforce the runtime security of your API, the API itself remains
wherever you have it deployed.
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.
Anypoint Platform returns to issues of Identity when addressing
its specific 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.

Anypoint Platform > MQ
21
• Cloud Messaging
• Multi-tenant
• Multi Datacenter persistent Storage
• Encrypted Exchanges and Queues
Anypoint MQ 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.

Anypoint Platform > Virtual Private Cloud
22
• Your DataCenter + Anypoint iPaas
• Single Private Secured Network
• IPSec
• OpenVPN
• Amazon VPC peering
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.
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.

Anypoint Platform > User Roles and Permissions
23
• Organizations and Business Groups
• Separate API Management
• Separate Runtime Management
• Roles and Permissions per Organization / BG
• Federated with External Identity Providers
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. To access them you need to have an account that 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.
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.

Anypoint Platform > Security Compliance
24
• FIPS 140-2
• SSAE 16 SOC 2
• PCI DSS Level-1
• HiTrust
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 platform is compliant with external audits is detailed in the whitepaper
“Anypoint Platform Cloud Security and Compliance”.

Scenario problem
26
Mythical Retail has a chain of stores and deliver an e-commerce solution to their
customers. One of their business objectives is to increase ecommerce revenue by 20% in
the next 18 months.
Mythical wants… Mythical has…
An omnichannel digital strategy Anypoint Platform for integration and API
management
A single view of the customer Clienteling software to help sales
associates
A loyalty program to understand their
customers spending habits
Uniformity across all customer
touchpoints
How can this be secured?

Scenario solution
29
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. In order 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 is able to 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
30
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.
For more resources on API security, please take a look at our whitepaper and webinar on API
security best practices.

Best Practices for API Security

In this document

More Related Content

What's hot

Similar to Best Practices for API Security

More from MuleSoft

Recently uploaded

Best Practices for API Security