Integration Recipe- lets cook it together!

 Integration Recipe- lets cook it together!

‍

 Lately, I was working on some biz. use cases and thought to document all the elements and share ahead with friends & colleagues who are newbie on the technology side just to give them flavor. Idea is to make you guys aware on these Integration concepts and then gradually as we move we will open up all in detail.

My intent is to combine 3 main concepts/ areas around - Connected apps, Authentication processes (OAuth protocol and diff. flows) and Identity process (SP, IDP, SSO)

Let's follow the Story line - You are the administrator of your business's Sf Org. and working with the one of the ISV(Independent software vendors) and have been asked to collaborate closely on one of the asks to connect their external app with Sf environment and also propose ways to exchange data to/ fro from Sf <--> app.

Typical common scenarios that we will talk about are -

1. 1st Business use-case is their users to be able login to their external app (www.xyz.com/ billing , order management etc.) with same Sf credentials (SSO- Service provider, SP initiated?, don't worry we cover all the acronyms later:).
2. Login to their external App directly from Sf App launcher without giving username / password (1-click) and boom! you land into external app (SSO- IDP identity provider initiated).
3. Login to SF with Single central credentials maintained in some other external system (Microsoft ADFS, ping fed etc) and also in to the external app using the same cred's which is generally the enterprise scenario (Again SSO, but SF as Service provider and ADFS as IDP).
4. Login to Sf using the Facebook, Google etc. social creds. (case of Social Sign On)
5. Post login/ authentication, How external App can authenticate and access Sf data (via. rest service Apis) using OAuth flows for authentication as below.
6. Lastly reversing the sides, making callouts from Sf to external Apps to get some status info.(using named credentials, auth provider if SF2SF integration is involved)

Now there are various elementary bits one would need to think from integration perspective viz. - who's on the connecting (web /mobile app, server) side, what language does it speaks (language of identity- protocol), Creating access door to get into Sf (Connected App), Setting access policies in Sf to define what they can access and finally your Service APIs' to surface data to external app. Stay with me its going to be fun !!

Ingredients -

Glossary items:

OAuth: is an open protocol to allow secure authorization, authentication and secure data sharing between applications through the exchange of tokens in a simple and standardized way, In essence its just a language both the parties (A&B) choose to communicate, SF supports it.

Connected App: Secure door to your SF org to allow 3rd party app access your SF system resources / data. In nutshell connected App lets you Create an identity for the 3rd party app (just like ID card) which makes them eligible to access Sf data on behalf of external app. You need to create this in your Sf org if you want external apps to access Sf data. Consumer key and secret is what you get which then you need to provide to your 3rd party App whenever they like to join the show!

Language of Identity: Protocols SF supports are SAML, OAuth, and OpenID Connect.

We can use either of these protocols while defining connected app which tells Salesforce which authentication protocol external app uses (on behalf of connected App).

Named Credentials: In simple terms, this is basically a container which allows you to store callout endpoint and its required authentication parameters in one packet. one of the nice way to make callouts to external systems using apex, avoiding unnecessary code duplicates.

Authentication provider: This is what allows you to login to SF using social credentials provided from an external Identity provider ( Microsoft, Facebook, Salesforce(SF 2 SF) etc), To setup this up you need to define client id , secret and auth. server endpoint of external sys in SF.

Service Provider, Identity Provider & Service Consumer: [SP]: Hosts your Services, Connected App - it's the service that accepts identity on behalf of external application from the identity provider, Remember: the system who is asking for the authenticated identity.

[IP]: Identity provider is a service which enables users to access other external applications with out logging in, In short its system which is authenticating the user.

[SC] is where you define Named creds (url, authentication params) for external System, Auth provider and where you make callouts- e.g. Sf

Single Sign-On - Single sign-on (SSO) lets users access all authorized resources without logging in separately to each one—and without having to create (and remember) different user credentials for each app.

Well for now that's all you need to know, moving ahead next to understand use-cases where you need these connected apps. see the illustration below-

Reasons why you need Connected apps, Why ?-

1. External ISV(Independent Software vendors) to access SF Data via. API integration: Imagine an use case where an external vendor asks to provide a way to surface SF data on their App. You need to create connected app with OAuth 2.0 in SF (as gateway), give the secure app credentials to web App and it lets you access Salesforce data on behalf of an external application.
2. Integrate Other Service Providers with Your Salesforce Org: Imagine an use case where business asks a way for their internal to be able to access their 3rd party app directly from SF (just by 1 click) or Other way to be able to login into external apps with their Sf credentials. This is where when Sf can acts as Identity provider and combining it with Connected App, your users would be able to log into the external app using single credentials maintained in SF. Notice there are 2 ways to do that either using SAML 2.0 OR with OpenID Connect depending on what protocol the external app supports.
3. Sf acting as authorization server for external API gateways: Interesting right?, Sf can acts as an authorization server for the external API gateway (e.g dell boomi or MuleSoft) and external apps can dynamically create connected apps in SF which then sends a request to Salesforce asking for access to data hosted/ protected on API gateway.
4. Manage access to 3rd party apps - Access to any 3rd party app installed from app exchange can be controlled via. Connected apps where admin can define security policies to define what 3rd party can access.

Depending on the type of External app you are integrating with Salesforce APIs', there are several types of OAuth 2-0 authentication flows that you can choose from depending on underneath arch of connecting apps.

1. Web App Integration (Web-Server authentication flow)- App(server) that can protect the consumer Secret.
2. Mobile App Integration (user- Agent flow) where the App cannot protect the consumer secret.
3. Server to Server Integration (using JWT Bearer flow)
4. Username-Password flow- where application has direct access to user credentials.
5. SAML bearer assertion flow (Security markup assertion lang)- Its another alternative for Apps which uses SAML way to get access token and access Sf resources. Clients connect and exchange using SAML assertions (XML-based) just like (SSO).

Note: from technical standpoint the difference in above flows, is the series of steps used to coordinate authentication process between application and Sf. As an outcome after authentication you will receive an access token (basically a permission) which a client App would then use for making subsequent calls to SF APIs' for data access.

That's all for now, In the next article we will talk about -Single Sign On using Salesforce as Identity provider (hub of user credentials) and also making SF as Service provider with Identity provider being Ping federate (both ways) using SAML and OpenId connect. And next would be hands-on with OAuth flows. Stay tuned! Together we do , better we gain !:)

Thanks!