How to Build Secure Financial APIs with MuleSoft Revealing OData Capabilities

1. MAY 13 2021
Moscow MuleSoft Meetup Group

2. 4
● Introductions
● MuleSoft updates
● Building secure financial APIs
○ Demo “Building Secure financial API”
○ Quiz & Q&A
● 5 minutes break
● Revealing OData Capabilities
○ Demo “How to compile OData on Mulesoft & connect it to Salesforce and mobile apps”
○ Quiz and Q&A session
● Networking time
Agenda

3. 5
Introductions
A SHOW OF HANDS:
Who is new to this Meetup?
Dmitry Fundak
Leadex Systems
MuleSoft Architect
Georgy Khomchenko
Customertimes
Senior MuleSoft Developer

4. Updates from MuleSoft

5. MuleSoft Certification Maintenance
https://training.mulesoft.com/certification-maintenance
Prerequisite: Current certification:
MULESOFT CERTIFIED
Developer
Format: Proctored, 45 minutes, 25 questions
Attempts: 2 attempts, then must take full exam
Cost: $62.50 USD or ¼ FTC
Validity: 2 years
7
LEVEL
1
MULESOFT CERTIFIED
Developer
MULESOFT CERTIFIED
Platform Architect
LEVEL
1
MULESOFT CERTIFIED
Integration Architect
LEVEL
1
Free
till May 31st
2021

6. Dmitry Fundak
HOW TO BUILD SECURE
FINANCIAL APIs with MULESOFT

7. 9
● Business case - secure financial API
● Anypoint Platform - security features overview
● Demo
● Quiz
Agenda

8. Business case —
Securely expose financial* API

9. Business case
11
A financial institution already has an internal Cards API and decided to
issue whitelabel / co-branding cards with business partners.
Goal - expose existing Cards API for partners (fintech, retail, airlines, …):
1. Securely
2. Fast
3. With minimum development efforts

10. API-led architecture of business case
12
System
APIs
Cards API
Card
Process API
Core
System API
Core
Banking
CC
System API
Card
System
Partner
Process
APIs
Experience
APIs
Scope of Demo Use Case
Out of scope

11. Anypoint Platform
security features overview

12. 14
Policies enable you to enforce regulations to
help manage security, control traffic, and
improve adaptability of your APIs.
You can implement all these regulations with
no modification to the code
implementation.
Security Policies available in API Manager:
● Client ID enforcement
● Cross-Origin resource sharing
● OAuth 2.0 access token enforcement
using Mule OAuth provider
● JWT Validation
● IP blacklist
● IP whitelist
● XML threat protection
● JSON threat protection
● Tokenization
● Detokenization
Policies

13. DLB enable you to:
* Handle load balancing among the different
CloudHub workers that run your application.
* Define SSL configurations to provide custom
certificates and optionally enforce two-way SSL
client authentication.
* Configure proxy rules that map your applications
to custom domains.
* This enables you to host your applications under a
single domain.
15
Dedicated Load Balancer

14. 16
* SSL Endpoint Configuration
Define SSL configurations to provide custom
certificates
* Two-way SSL client authentication
Optionally enforce two-way SSL client
authentication
Dedicated Load Balancer - SSL / TLS

15. 17
Anypoint Security (add-on)
* Edge Policies
Anypoint Security policies then act as a
default firewall/router capability through
which all traffic traverses.
* Secrets Manager
Anypoint Security provides a secure vault
for you to store the TLS certificates and
keystores used by your deployments.
* Tokenization Service
Anypoint Security’s tokenization service
protects sensitive data from unwanted
exposure by replacing key values, such as
a credit card number, with a token.

16. 18
Anypoint Security - Edge Policies
● DoS Policy
DoS policies are designed to protect your network nodes against malicious clients trying to flood your
network to prevent legitimate traffic to your APIs.
● IP Whitelist Policy
Create an IP address whitelist policy to configure an explicit list of IP addresses that can access your
deployed endpoints.
● HTTP Limits Policy
HTTP limits policies prevent attacks from clients that send large messages that can consume all of your
processing bandwidth.
● WAF Policy
WAF policies provide the Open Web Application Security Project (OWASP) Core Rule Set (CRS) for
checking requests and responses to detect common web application attacks.

17. 19
Anypoint Security - Web Application Firewall

18. 20
Anypoint Security - Tokenization
* Format-Preserving Tokens
The output tokens have the same format as
the sensitive data input. Generated tokens
conform to the existing data structure and
validations.
* Masking
Configurable mask character is returned
which hides the identity of the sensitive
data

19. 21
Anypoint Security - Tokenization
* Format-Preserving Tokens
The output tokens have the same format as
the sensitive data input. Generated tokens
conform to the existing data structure and
validations.
* Masking
Configurable mask character is returned
which hides the identity of the sensitive
data

20. 22
Anypoint Security - Secret Manager
* Use secrets manager to write and
manage your secrets, keys, and
Transport Layer Security (TLS) artifacts
Secrets manager is designed to store and
manage secrets for supported Anypoint
Platform services. It is not a
general-purpose storage for secrets. Only
trusted services within Anypoint Platform
have access to the contents of the secret.
* Supported Secret Types
TLS Context
Keystore
Truststore
Certificates
Certificate Pin Set
CRL Distributor

21. Demo

22. Component Architecture
24
This case only about client credentials flow -
machine-to-machine (M2M)
* If interested, we can demonstrate (on another
meetup) a B2C case, where an end-customer gives
his/her consent to Application based on PSD2 /
OBIE v3

23. Demo
25
Enough slides, and let the demo begin!

24. API secured with...
26
OAuth client credentials flow — Okta* & MuleSoft OAuth Policy
IP Whitelist policy — in case we need to restrict access by IP
SSL company certificate & Mutual TLS — trusted client certificate
0 lines of code written

25. 28
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/moscow/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?

26. Thank you

27. OData API with MuleSoft

28. What is OData?
OData stands for Open Data Protocol and
was designed to fill the “web” gap between
Databases and Database consumers
• Provides access to database through HTTP
• Unified request and response structures allow
seamless integrations
• DB Query are passed as a query parameter
• HTTP Verbs mimic DB operations:
• GET ➔ SELECT
• PUT ➔ UPDATE
• POST ➔ INSERT
• DELETE ➔ DELETE
https://services.odata.org/OData/OData.svc/Category(1)/Products?$top=2&$orderby=name
Service Root URI Resource Path Query Options

29. OData and MuleSoft
MuleSoft provides OData plug-in for Odata
API development
1. Go to “Help -> Install new software” and
install most recent version of “APIkit for
ODATA Update Site”
2. Create Odata.raml file in
src/main/resources/api with datatypes
available in source database
3. Right click on Odata.raml and select “Mule ->
Generate Odata API from RAML types”
src/main/resources/api/Odata.raml
Similar to generating flows from RAML,
after these steps APIkit will generate stubs
for each Odata endpoint in api.xml

30. Implementing OData endpoints
Unlike plain REST endpoints there are few
rules that we must follow:
1. All endpoints should return data in one
specific way:
{ “entries” : payload }
2. Except “format” query parameter all other
parameters should be manually processed
and transformed to SQL query (DW script is
available with OData MuleSoft example)
3. OData information like keys (fields of entity)
or entity name itself is available at startup in
vars.odata object
4. POST response requires created entity to be
returned, unlike REST where either ID is
returned or empty payload with 201 code

31. Demo Scenario

32. OData as an External Data Source
By following these steps, you can bind your
Mule OData service to SF’s external data
source. It will immediately display all data
in custom tab
1. Navigate to Setup -> External Data Sources ->
New External Data Source
2. Enter name of the Data Source and select type
“Salesforce OData Connect: OData 2.0”
3. In URL provide URL of your OData.svc file like
following:
https://services.odata.org/OData/OData.svc
4. Click “New” under external object and select
Object that was detected from .svc file
5. Navigate to “Tabs” in Setup, click “New” next to
“Custom Object Tabs”
6. Select corresponding Object from step #4, select
any Theme and click save
7. Now you can view your data in newly created tab

33. Connecting to OData with OData4j library
By following these steps, you can establish
connection with OData service through
OData4j client.
1. ODataConsumer consumer = ODataConsumers.create(serviceUrl);
2. Enumerable<OEntity> = consumer.getEntities("customers").execute()
3. OEntity customer = consumer.getEntity("customers", customerId).execute();
4. OEntity customer = consumer.createEntity("customers")
.properties(OProperties.string("email",
"example@example.com"))
.execute();
5. consumer.updateEntity(customer)
.properties(OProperties.string("email", "new@example.com"))
.execute();
6. consumer.deleteEntity("customers", customerId).execute();

34. Working with REST vs OData in Java

35. OData vs REST
PROS CONS
Inability to modify RAML and publish
to exchange
Some 400 “Bad request” errors will
just say “invalid format”
SF currently sends POST for entity
update and therefore full integration
with OData is not possible
Fast and easy connectivity from
external systems
Ability to seamlessly switch between
JSON and xml
Ability to modify response data
without any code changes in the API
Exposes metadata containing info
about all data models and operations

36. Thank you!