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:
This post is part 2 of 3 for my ultimate guide to API security best practices series. In this post, I will be discussing confidentiality, integrity, and availability of data. In essence, methods of how we can keep data private, protect it from being compromised while making it accessible anytime.
Part 1 – API security: Ways to authenticate and authorize discussed authentication and authorization of identity security.
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.
In this final part of our introduction to DataWeave, we now present you with some example transformations. Just in case you missed the previous posts I included parts 1 to 3 below:
We will use everything we have learned till now to realize the transformations. Wherever we introduce new concepts we will highlight them in a subsequent set of notes. So, without further delay, let’s jump in!
In the previous post, Getting Started with DataWeave: Part 2, in this four-part series:
and a webinar about our powerful yet simple new transformation engine, DataWeave, we introduced you to Selector expressions so that you can navigate to and retrieve particular parts of the incoming message. We also showed you how to apply iterative and conditional logic as is required in almost all transformation scenarios.
In the Getting Started with DataWeave: Part 1, we introduced you to DataWeave and its canonical format, the result of every expression you execute in the language. We now continue to explore our new transformation engine, aiming to give you enough grounding to tackle real-world use-cases.
As we did in Part 1, we will continue to show the results of each expression in the DataWeave canonical format.
This series is now complete here:
Data transformation is an inevitable component of connectivity, as most systems don’t speak the same language. Even when the format is similar, as when two RESTful Web APIs exchange JSON payloads, their message structure typically differs, making translation a necessity.
In this the first of a four-part series:
Multi-channel retailing has multiplied the opportunities for Retailers to do more business with their customers by going beyond their bricks and mortar in order to sell over the web, through smart phones and tablets, perhaps soon on smart TVs and through Partners and Resellers.
I wish to help you see how you can achieve a significant increase in revenue by adopting an IT architecture that will bring you a rapid return on investment and help put your retail business right at the helm of a fundamental change in the industry.
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.
Security Manager
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.
The benefits of applying the principles of SOA when catering to the IT needs of your organization are clear in a business-driven, vendor-neutral architecture. It considers all requirements from the perspective of the business process and delivers implementations in order to automate the same. The implementations themselves, driven by the same SOA principles and goals, are not bound to any one particular vendor because they are intrinsically interoperable, that is, they expose and consume Services or APIs (we use the terms interchangeably here).
Sign up for our newsletter
