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:
- API security: Ways to authenticate and authorize
- API security: Keeping data private but accessible
This post will be part 1 of 3 for my ultimate guide to API security best practices series. In this post, I will be discussing the current concerns IT decision makers have in regards to their current digital assets.
Part 2 – API security: Keeping data private but accessible will address the need for keeping data private and protecting it from being compromised while making it accessible at all times.
Learn how to align security and agility
In some organizations, the Chief Information Security Officer (CISO) has earned a reputation inside of IT as a blocker or a hindrance to innovation. Some CISOs have even be referred to as the ‘Queen (or King) of No.’ Why? Because despite the massive amounts of attention being paid to security in the media, with Target, Apple, Nissan, and Twitter all making the news recently for their security failures, security is still considered an afterthought in most IT projects. As a result, by the time security professionals get involved in project delivery, they have no choice but to flag security gaps that often require impractical redesign — resulting in project delays at best and cancellation at worst.
In a previous post, I explained the reasons why pure SOA, despite being a powerful architectural paradigm with many benefits, could fall short. Building on that narrative, I will provide in this post guiding principles to help you create a modern integration strategy – one that enables digital transformation, supports the API economy and is suitable for the pace of change required to build an application network.
Anypoint Platform TLS 1.0 Deprecation
In an effort to ensure the highest levels of security for our customers, and in response to the PCI-DSS 3.1 standard, MuleSoft has begun the process of removing TLS v1.0, and replacing with TLS v1.2 as the default encryption protocol for inbound and outbound connections to Anypoint Platform.
Why are you doing this?
As you might have read, Mule 3.8 includes a number of improvements regarding TLS. In this post, we will analyze the TLS environment prior to this release and explore all of the new enhancements in detail so that you can start taking advantage of them.
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Mulesoft’s Anypoint platform. In this blog post, we show how an organization can use Anypoint Platform to communicate with their partners using a secure file-based solution.
The January 2015 release of CloudHub features several key upgrades to our infrastructure. With this release, customers will be able to run more applications per vCore (10 per vCore – up from the current limit of 4), and will also be able to run more compute and memory intensive applications – which consume up to 4 vCores in one instance. We are also releasing a new security feature – data encryption for persistent queues, which will help customers with their security and compliance needs.
More Applications per vCore, and Support for Bigger Applications
Starting with the January 2015 release, customer applications running on CloudHub will have a bigger palette of worker sizes to choose from. Currently, a customer application has a choice of 3 worker sizes – Shared, Regular, or Double, representing 1/4th of a vCore, 1 vCore, and 2 vCore capacities respectively. Starting February 7, applications running on CloudHub will have 5 different worker sizes to choose from, with the compute and memory capacities described in the following table:
|New Worker Sizes
||500 MB Mem
||1 GB Mem
||1.5 GB Mem
||3.5 GB Mem
||7.5 GB Mem
Securing an API in Anypoint Platform is easy. In a previous post we showed how Anypoint Platform for APIs allows you to fully protect your API. We concluded then that the combination of HTTPS and OAuth 2.0 are a rule-of-thumb best practice for Web API security. In this post, we’ll take a deeper dive into the makeup of a security configuration in Anypoint Platform and explore in more detail the areas of Basic Authentication and OAuth2 Authorization in the context of Identity Management. We’ll also give you some pointers about when and how to use these two standards.
Central to authentication in Mule is the Security Manager. This is the bridge between standard mule configuration and Spring Security beans. In the example we build in this blog, we will use Spring Security to authenticate credentials against an LDAP server. We suggest you read the Spring Documentation on this topic if you want to delve further.
Trust no one! Most security issues comes from assuming that no bad person is going to tamper with your input data. We usually pay more attention to it when processing the most common inputs, such as an HTTP request or some argument that’s going into an SQL query. But we usually don’t pay much attention to other types of resources that are also vulnerable to malicious thinking – such as an XML file.
External Entities are an XML feature which allow you to embedded an external source into your document. For example, let’s suppose that your application responds to queries using an XML schema, which contains a disclaimer footer. Your legal department is prone to changing the wording on it so it probably makes sense to take it from an external file, so that your templates (which are part of your deployed source code) are not modified. Such templates could look like this: