Meet up slides_mumbai_21032020_final

[21st March 2020]: [MuleSoft Design Factors With Salesforce
Integration and Securing MuleSoft API’s using AWS Cognito
OAuth and Mule JWT Validation Policy]
[Mumbai - India]

All contents © MuleSoft Inc.
Agenda
2
 Introductions
 MuleSoft Design Factors With Salesforce Integration
 AWS Cognito and Mule JWT Validation Policy
 MuleSoft As OAuth Provider
 MuleSoft Dedicated Load Balancer and Mapping Rules
 Networking time

Introductions
3
• About the organizers:
– Sudeshna Mitra
– Manish Yadav
– Akshata Sawant
• About the sponsors: MuleSoft
A SHOW OF HANDS:
Who is new to this MeetUp?

Speaker
4

[MuleSoft Design Factors With
Salesforce Integration]

Contents
MuleSoft Design factors with Salesforce
Integration
6
• Why it's important to know
• Different ways to integrate with Salesforce
• API Design Strategy
• Event Design Strategy
• Securing Events
• Designing Salesforce System API
• Additional Benefits
• Top 5 Salesforce Integration Patterns

Why it's important to know
Integration
7
• After Salesforce acquired MuleSoft
– The sales focus is now more strategic from enterprise perspective
– More MuleSoft Integrations forecasted with Salesforce
• Salesforce APIs Limits
– Salesforce have daily rate limits according to an SLA assigned. Once you hit the
limit, you cannot call those API for a specific period
– E.g. For an Salesforce Enterprise Edition org with 15 Salesforce licenses, the
request limit is 115,000 requests (100,000 plus 15 licenses x 1,000 calls) in 24
hours.
• For a large integrated ecosystem, knowing these limits helps us thinking through
right design to utilize Salesforce API calls more efficiently

Different ways to integrate with Salesforce
Integration
8
• APIs
– Standard API for sObjects
– Invoke Apex (custom service at Salesforce)
– Query API using SOQL (Salesforce Object Query Language)
– Bulk API- for large set of record
• Inbound Events
– Platform Events
• Out of Box – gives only meta-data i.e. Salesforce Record Id
• Custom – Gives actual Payload
– Change Data Capture Events
• Entire data set for record changes

API Design Strategy with Salesforce
Integration
9
• Use MuleSoft API Caching Policy for search
– If Static data, responses that change infrequently or at predictable intervals, responses used by
multiple clients (frequently-requested data)
– MuleSoft (and many other integration tools) have mechanisms to automatically cache responses to
similar previous requests. Recommendation to either use a Cache Scope (design-time element) or a
Cache Policy (modified at runtime), both backed by MuleSoft’s Object Store
– Reference : https://blogs.mulesoft.com/dev/api-dev/caching-policy-api-performance/
• Fetch related Parent-child records from Salesforce
– When calling Salesforce API to fetch data -Try to get all related data for downstream system so that
design can leverage pub-sub model and we don't end up calling Salesforce API multiple times(unless
specific use-case needs otherwise)
• Use Bulk API for large data sets:
– If you want to upload large sets of data into Salesforce use Bulk API, response comes with ‘id’, which
can be used to get status later
– Reference: https://blogs.mulesoft.com/dev/connectivity-dev/bulk-api-v2-support-salesforce-
connector/

Events Design Strategy with Salesforce
Integration
10

Securing Events
Integration
11
• PE & CDC objects are stored in salesforce channel between 1-3 days
• So its important is that data within Salesforce channel stored securely, to have data
privacy compliance
– CDC provides out of box shield encryption
– Platform event was not supported, there by needed applying custom encryption at Salesforce &
custom decryption at MuleSoft
– Which is error prone, as some of the algorithm has limitations on data size
– Finding right algorithm at both Salesforce & MuleSoft was challenging
• Good news is that, recently Salesforce (2 months) released OOB shield for PE, that
can be enabled at Org level.

Designing Salesforce System API
Integration
12
• Salesforce has all kinds of data e. g. Account related(customer, address etc) ,
Order related (order, invoice and many more)etc.
• In general if we use 1 Salesforce system api, then we may endup using more cores
for scaling (0.1, 0.2 then 1vCore)
• Consider In this case, order related operations are of heavy loads (transactional
through put) than account related
Then it's better to mitigate RISK of failure by multiple Salesforce system APIs and
normalized vCore capacity.

Designing Salesforce System API
Integration
13
Total vCore = 2 vCores Total vCore = 0.8 vCores
System API Sandbox Prod-HA
System API
SFDC
1 vCore 2 vCore
System API Sandbox Prod-HA
System API - 1 0.1 vCore 0.2 vCore
System API – 1 0.1 vCore 0.2 vCore
System API – 1 0.2 vCore 0.4 vCore

Check for Other benefits with Salesforce and MuleSoft
Integration
14
• You may likely to get more daily Salesforce API limits
• Additional daily/monthly transaction limits for Anypoint MQ
Contact your MuleSoft Customer Account Executive to know about these benefits
and make best use of it and make success story

Integration
15
Pattern Name Flow Short Description
Migration Moving Data from one system to another
Broadcast Data from One system to Multiple Destination
Aggregation Multiple Source to One Destination
Bi-directional Sync Uniting two or more data sets from two or
more different systems
Correlation Only Synchronizes data for records available
in both Systems
There are Top 5 Salesforce integration patterns commonly used (MuleSoft whitepaper)
https://www.mulesoft.com/lp/whitepaper/saas/salesforce-integration-patterns

AWS Cognito and Mule JWT
Validation Policy

What is AWS Cognito?
17
Amazon Cognito is a simple user identity and data synchronization service that helps you securely manage
and synchronize app data for your users across their mobile devices. You can create unique identities for
your users through a number of public login providers (Amazon, Facebook, and Google) and also support
unauthenticated guests. You can save app data locally on users’ devices allowing your applications to work
even when the devices are offline. With Amazon Cognito, you can save any kind of data in AWS Cloud, such
as app preferences or game state, without writing any backend code or managing any infrastructure. This
means you can focus on creating great app experiences instead of having to worry about building and
managing a backend solution to handle identity management, network state, storage, and sync.
Amazon Cognito User Pools is a standards-based Identity Provider and supports identity and access
management standards, such as OAuth 2.0, SAML 2.0, and OpenID Connect.
In addition to using the Amazon Cognito-specific user APIs to authenticate users, Amazon Cognito user
pools also support the OAuth 2.0 authorization framework for authenticating users.

AWS Cognito Uses
18

Integrating AWS Cognito Authorization Code With MuleSoft
API Manager
19
Authorization Code Grant
The authorization code grant is the preferred method for authorizing end users. Instead of directly providing
user pool tokens to an end-user upon authentication, an authorization code is provided. This code is then
sent to a custom application that can exchange it for the desired tokens. Because the tokens are never
exposed directly to an end-user, they are less likely to become compromised.

Integrating AWS Cognito Authorization Code With MuleSoft
API Manager
20

Integrating AWS Cognito Client Credentials With MuleSoft
API Manager
21
Client Credentials Grant
The client credentials grant is much more straightforward. While the previous grants are intended to obtain
tokens for end users, the client credentials grant is typically intended to provide credentials to an application
in order to authorize machine-to-machine requests. Note that, to use the client credentials grant, the
corresponding user pool app client must have an associated app client secret.

Integrating AWS Cognito Client Credentials With MuleSoft
API Manager
22

JWT Validation Token
23
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between the
two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web
Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims
to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted.
● JWTs are stateless, making tokens easier to manage.
● JWTs can be used to transfer claims securely between parties.
● JWTs are scalable.
○ The payload of a token can be expanded to increase new claims easily.
● JWTs are decoupled in nature allowing authentication to happen on a different server.
● The tokens are compact. JSON format makes the token less verbose than XML. The smaller size allows
easier transmission over HTTP.
● JWTs are JSON-based and can be easily parsed by multiple receiving systems, especially mobiles. This
enables an industry-wide adoption.

24

25

26

JWT Token Algorithm
27
● Symmetric algorithms – HMAC using SHA-256, SHA-384, and SHA-512.
● Asymmetric algorithms – RSA using SHA-256, SHA-384, and SHA-512.
● None – no signature validation.

Live Demonstration - AWS
Cognito & Mule JWT
Validation Policy

MuleSoft as OAuth Provider
30
The OAuth2 Provider module allows a Mule runtime engine (Mule) app to be configured as an Authentication
Manager in an OAuth2 dance. With this role, the application will be able to authenticate previously registered
clients, grant tokens, validate tokens, or register and delete clients, all during the execution of a flow.
MuleSoft supports various third party OAuth 2.0 providers as listed below
● Okta
● OpenID Connect
● Open AM
● PingFederate
MuleSoft can be also used as an OAuth provider for securing the applications.

31

32

Live Demonstration -
MuleSoft As OAuth Provider

MuleSoft Dedicated Load
Balancer and Mapping Rules

MuleSoft Dedicated Load Balancer
35
The OAuth2 Provider module allows a Mule runtime engine (Mule) app to be configured as an Authentication
Manager in an OAuth2 dance. With this role, the application will be able to authenticate previously registered
clients, grant tokens, validate tokens, or register and delete clients, all during the execution of a flow.
MuleSoft supports various third party OAuth 2.0 providers as listed below
● Okta
● OpenID Connect
● Open AM
● PingFederate
MuleSoft can be also used as an OAuth provider for securing the applications.

MuleSoft Dedicated Load Balancer
36
Mapping rules are used on dedicated load balancers to translate input URI to call applications deployed on
CloudHub. A pattern is a string that defines a template for matching an input text. Whatever value is placed
within curly brackets ({ }) is treated as a variable. Variable names can contain only lowercase letters (a-z) and
no other characters, including slashes.
Let's consider that we have 2 DNS (i.e. api-dev.example.com and api-test.example.com) setup on a
dedicated load balancer.
api-dev.example.com is for the Dev environment whereas api-test.example.com is for the Test
environment.

MuleSoft Dedicated Load Balancer - Use Case 1
37
Use Case 1
We are receiving requests on the DLB https://api-dev.example.com/ecommerce/v1.0/invoice and need to
redirect them to http://org-ecommerce-api.cloudhub.io/v1.0/invoice (the CloudHub application name will
be org-ecommerce-api)
We can use this mapping rule to achieve this.
This above rule will be applied when requests come on DLB and route to the CloudHub application in the
VPC.

38
https://api-dev.example.com/ecommerce/v1.0/invoice ==> http://org-ecommerce-
api.cloudhub.io/v1.0/invoice

39
But here we have some problems that on our DLB, we have set up 2 DNSs, one for Dev and another for Test.
Now, how will the DLB know this is a request that needs to route to either the Dev or Test application because
the same rule will be applied for both?
To avoid this, we will be using a subdomain in the next use case.

40
In this case, we will be using a subdomain for routing the request to the correct environment from DLB.
Our application name format must be org-app-subdomain (e.g. org-ecommerce-api-dev for dev
environment and org-ecommerce-api-test for test environment) when deploying to CloudHub workers in
VPC .
So, our mapping rule will look like this.

41
subdomain is variable to map any subdomain.
● https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-dev.cloudhub.io/v1.0/invoice (CloudHub
Dev Environment)
● https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-test.cloudhub.io/v1.0/invoice (CloudHub Test
Environment)
● https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-
dev.cloudhub.io/v1.0/invoice (CloudHub Dev Environment)
● https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-
test.cloudhub.io/v1.0/invoice (CloudHub Test Environment)

42
● https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-dev.cloudhub.io/v1.0/invoice (CloudHub
Dev Environment)
● https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-test.cloudhub.io/v1.0/invoice (CloudHub Test
Environment)
● https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-
dev.cloudhub.io/v1.0/invoice (CloudHub Dev Environment)
● https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-
test.cloudhub.io/v1.0/invoice (CloudHub Test Environment)

43

44
In this use case, we solve the issue of routing the request from DLB to the correct environment.
Let's consider another scenario where you want to route the request to CloudHub on the basis of the application
version. We will see this in the next use case.

45
In this case, when we will deploy an application to CloudHub, and it will be in format org-app-subdomain-version
(e.g. org-ecommerce-api-dev-v1-0 for Dev environment and org-ecommerce-api-test-v1-0 for Test
environment).
Whenever we will get request on DLB, then the version in the URL will be v1.0 and v2.0 but when you deploy
application on CloudHub it doesn't allow to use "." in the application name. That is the reason we are using "-" in
the version of the application deploying to CloudHub.
So, our mapping rule will look like this.

46
● https://api-dev.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-dev-v1-
0.cloudhub.io/v1.0/invoice (CloudHub Dev Environment)
● https://api-test.example.com/ecommerce/v1.0/invoice (DLB) ==> http://org-ecommerce-api-test-v1-
0.cloudhub.io/v1.0/invoice (CloudHub Test Environment)

47

MuleSoft Dedicated Load Balancer Rule Priority
48
DLB will apply the first matching rule regardless of more exact matching rules available. A rule defined first, at
index 0 has higher priority against other rules defined after it. The higher the index assigned, the less priority
the mapping rule has.

References - Articles
49
Implementing Mapping Rules With MuleSoft Dedicated Load Balancer
https://dzone.com/articles/implementing-mapping-rules-with-mulesoft-dedicated
Authorizing the MuleSoft API Using AWS Cognito User Pool and Mule JWT
Validation Policy
https://dzone.com/articles/authorizing-the-mulesoft-api-using-aws-cognito-use
Implementing MuleSoft AnyPoint Platform Identity Management Using AWS
Cognito Authorization Code
https://dzone.com/articles/implementing-mulesoft-anypoint-platform-identity-m

References - Articles
50
Implementing MuleSoft as OAuth Provider for securing Mule Application
https://dzone.com/articles/implementing-mulesoft-as-oauth-provider-for-securi

References - Videos
51
Implementing MuleSoft as OAuth Provider For Securing the MuleSoft
Application
https://youtu.be/IYKaps1ndxI
Implementing MuleSoft AnyPoint Platform Identity Management Using AWS
Cognito Authorization Code
https://youtu.be/PGkORD1CPh8
Authorizing the MuleSoft API Using AWS Cognito User Pool and Mule JWT
Validation Policy
https://youtu.be/X4KXwzi5yoU

Take a stand !
52
• Nominate yourself for
the next meetup speaker
and suggest a topic as
well.

What’s next
53
• Share:
– Tweet your pictures with the hashtag #MuleMeetup #MuleSoftMeetup
– Invite your network to join: https://meetups.mulesoft.com/mumbai/
• Feedback:
– Contact your organizers Manish Yadav, Sudeshna Mitra, Akshata Sawant and Ranveer Meel to
suggest topics
– Tweet your organizers at @SudeshnaMitra14, @Manish_Kyadav, @sawantakshata02
– Contact MuleSoft at meetup@mulesoft.com for ways to improve the program
– Follow us on Instagram (mumbai_mulesoftofficialpage)
– Your Feedback is Food for us
• Our next meetup:
– Date: TBD
– Location: Mumbai
– Topic: TBD

Networking time
Introduce yourself to your neighbors!

See you next time
Please send topic suggestions to the organizer

Meet up slides_mumbai_21032020_final

Meet up slides_mumbai_21032020_final

Recommended

More Related Content

What's hot (20)

Similar to Meet up slides_mumbai_21032020_final (20)

More from Akshata Sawant (17)

Recently uploaded (20)

Meet up slides_mumbai_21032020_final