We've lined up Alex Fernandez (from Capgemini) to speak about 'Google Assistant Integration with MuleSoft' and Poulami Maity (from Woodside) to speak about 'API Security using Azure AD'.
2. Welcome
2
Ryan Grondal
Lead Solution Engineer
MuleSoft
Gurunadha Reddy
IT Analyst
Tata
Michael Price
Senior Solutions Architect
MuleSoft
A SHOW OF HANDS:
Who is new to this Meetup?
3. 3
● Introductions and Networking
● Google Assistant Integration with MuleSoft
● API Security using Azure AD
● Wrap-up and Networking
Agenda
4. Presented by Alex Fernandez
Google Assistant Integration with
MuleSoft
5. 5
● Voice Assistant
o War on Voice Assistants
o What is Google Assistant?
o Building a custom assistant
● API Led and Voice Strategy
o Development and Implementation strategy
o Demo – Google Assistant in Action
o Demo – API Implementation
Overview
6. War on Voice Assistants
● In 2019, smart speaker ownership in the U.S. surpassed 76 million, according
to CIRP (Consumer Intelligence Research Partners), up from 66 million at the end
of 2018
Source:
https://connectedworld.com/war-of-the-voice-assistants/
7. Voice Assistant Leader
Smart Speaker
● Amazon Echo - 70%
● Google Home – 25%
● Apple Home Pods – 5%
Smartphone Assistant
● Google Assistant and Apple Siri – 36%
● Amazon Alexa - 25%
● Microsoft Cortana – 19%
● Other – 1%
Source:
https://connectedworld.com/war-of-the-voice-assistants/
8. What is Google Assistant?
● Google Assistant is an artificial intelligence–powered virtual assistant developed by Google that is
primarily available on mobile and smart home devices. - Wikipedia
9. How to build a custom assistant, Mr. Buzz?
Mr. Buzz is an assistant which can pay your bills
and pull your energy consumption. This enables
an energy company to serve customers via a Voice
enabled strategy.
Actions by Google
GUI and SDK to train and interprets voice intentions
23. 23
o Client ID/Secret
o OAuth 2.0
o Policies used
■ Rate Limiting based – SLA Based
■ JWT Validation
■ IP Whitelist in some cases
■ IP Blacklist (proposed)
Authentication on APIs
25. Revised Guidelines on API Security
○ Applications should only accept tokens related to their own identity.
○ APIs or applications should have their own identity. To achieve the APIs should be registered in the Authorization
server or Azure AD.
○ Tokens intended for one service should not be passed on to another service - unless this is used in the On-
Behalf-Of flow in order to vend a token that is still constrained to the identity of the first token.
○ Validation of the token is done on the resource server , in this case Mulesoft. The following claims are validated:
○ Token expiry
○ Scopes/Roles
○ Audience
○ Additional claims may be checked in a token e.g. UPN in additional to the mandatory claims.
25
26. OAuth 2.0 Flows
● The On-Behalf-Of grant is typically used in scenarios involving machine-to-machine communication,
but user context needs to be maintained within the call to the next system.
● The client-credentials grant is typically used in scenarios involving two trusted parties; usually in
machine-to-machine, or service-to-service communication without the involvement of a user. r that is
tied to the identity of the initial token.
26
27. Ownership in Azure AD for APIs
● The owner is ultimately responsible and accountable for granting access to user or machine identities.
The owner must consider;
○ Owners are responsible for assigning permissions to application and user identities.
○ Owners are responsible for revoking permissions to application and user identities.
○ Owners are responsible for defining rules for accessing their resource
○ Define the terms of service for the relation between the client and the API
○ Understand the requirements of access to the data.
○ Consult with the data owner or custodian of the data to understand the sensitivity of the data , they are
granting a client access to .
27
30. Resource Level Authorization
● Authorization strategy depends upon the resource being accessed in an API.
● Defining permissions one every resource on the API.
● Used scopes for resource level authorization.
● Consumers requesting for a particular resource has to get the scope pre-approved in Azure AD by the
owner of the API and get it approved by Platform team.
● JWT Validation Policy checks for the scopes in the token is the intended scope for the endpoint or
resource.
30
32. Role-Based-Authorization-Control
● Role-Based-Authorization-Control is highly recommended.
● Application Registrations must be having at least one corresponding Azure AD Group to represent
users (also referred to as a ‘boundary group’). All users and services that access the application should
be members of this group.
● The Azure AD groups should be bound or mapped to an appropriate ‘AppRole’ as part of the
Application Registration.
● Permissions should be granted to users based on membership of various ‘AppRoles’.
● Applications/APIs must check that tokens include the appropriate ‘AppRoles’ claims before
authorizing access.
32
35. 35
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/
○ Check out the Ideas Portal: https://help.mulesoft.com/s/ideas
○ Come join the Developer Community: https://developer.mulesoft.com/
● 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?
