Canvas

• Canvas enables you to easily integrate a third-party application in Salesforce. Canvas is a set of tools and JavaScript APIs that you can use to expose an application as a canvas app. This means you can take your new or existing applications and make them available to your users as part of their Salesforce experience.

• The third-party app that you want to expose as a canvas app can be written in any language. The only requirement is that the app has a secure URL (HTTPS).

Note-Before diving into canvas, consider these other options for integrating a third-party application in salesforce:

Web tabs- Canvas apps present third-party applications as part of a page. Web tabs can present a full application in large screen space.

HTML iframes in a custom component-Canvas apps provide greater functionality than developing with iframes. Iframes are sometimes easier to integrate with your application

Where Canvas Apps Appear?

Canvas apps can appear in a few places.

• Chatter Feed—The canvas app appears in the feed. If this option is selected, you must create a CanvasPost feed item and ensure that the current user has access to the canvas app.

• Chatter Tab—The canvas app appears in the app navigation list on the Chatter tab. If this option is selected, the canvas app appears there automatically.

• Console—The canvas app appears in the footer or sidebars of a Salesforce console. If this option is selected, you must choose where the canvas app appears in a console by adding it as a custom console component.

• Layouts and Mobile Cards—The canvas app can appear on a page layout or a mobile card. If this option is selected, you choose where the canvas app appears by adding it to the page layout.

• Mobile Nav—The canvas app is accessible from the mobile app navigation menu.

• Open CTI—The canvas app appears in the call control tool. If this option is selected, you must specify the canvas app in your call center’s definition file for it to appear

• Publisher—The canvas app appears in the Chatter publisher and action bar. If this option is selected, you must also create a canvas custom action and add it to the global publisher layout or to an object’s page layout.

• Visualforce Page—The canvas app can appear on a Visualforce page . If you add an <apex:canvasApp> component to expose a canvas app on a Visualforce page, be sure to select this location for the canvas app; otherwise,you’ll receive an error.

Note- You can see what are the available options for canvas from the connected app under Canvas app setting.

Authentication-

When you create a canvas app, you can use one of the following authentication methods:

• Signed request—The default method of authentication for canvas apps. The signed request authorization flow varies depending on whether the administrator gives users access to the canvas app or if users can self-authorize. The signed request containing the consumer key, access token, and other contextual information is provided to the canvas app in one of these ways:

• The administrator allows access to the canvas app for the user.

• The user approves the canvas app in the OAuth flow.

• OAuth 2.0—Canvas apps can use the OAuth 2.0 protocol to authorize and acquire access tokens.When using OAuth with Canvas, you have two options:

• Web server flow—To integrate a canvas app with the Salesforce API, use the OAuth 2.0 web server flow, which implements the OAuth 2.0 authorization code grant type. With this flow, the server hosting the web app must be able to protect the connected app’s identity, defined by the client ID and client secret.

• User-agent flow—With the OAuth 2.0 user-agent flow, users authorize a canvas app to access data using an external or embedded browser. This flow uses the OAuth 2.0 implicit grant type. 

Demo of Canvas Application

Let’s start with a very basic demo of Canvas. Let’s say we have two Salesforce orgs, Salesforce Service Provider and Salesforce Identity provider. The Canvas app is hosted in Idp salesforce org and uses signed requests to reference a VF page in the second org. 

Step1: Go to Idp org and enable Identity Provider as below:

Step2: Go to Sp org and enable Single Sign-On as below:

Note- You can download a metadata file from Identity Provider Setup of Idp org and upload into SSO settings in SP org. 

Step3: Create Connected App in IDP org as below: 

Step4: Manage Policy by clicking the manage button on the connected App. You can decide how you want to give the access etc.

Step 5: Create the VF page in idp org and using below tag:

<apex:page>

 <apex:canvasApp developerName="CanvasDemoApp" />

</apex:page>

Salesforce Identity Licenses

All identity services that are built into the Salesforce Platform are included with every paid license in the Enterprise, Unlimited, Performance, and Developer Editions.

1. Identity Only License

2. External Identity License

3. Identity Verification Credits Add-On License

4. Identity Connect License

Identity Only License

• Purchase the Identity Only license when you need extra licenses for employees to access only identity services, such as single sign-on (SSO). For example, some of your employees don’t need access to all the solutions included with a Salesforce license. But you want these employees to be able to sign in to a custom Your Benefits web app directly from your Salesforce org using SSO. You can purchase the Identity Only license for them.

• Each Identity Only licensed user is limited to 10 custom objects. 

External Identity License

• Salesforce Customer Identity is available when you purchase the External Identity license. This license applies to Experience Cloud users who don’t already have a community license. These users are typical consumers of your business, such as customers, prospective customers, patients, partners, and dealers. You can purchase the External Identity license in blocks of active users.

• An External Identity license lets you deliver identity services, including (SSO) to external users.

Identity Verification Credits Add-On License

• Customers of mobile-first identity receive email verification for free. You can also offer mobile verification via text message for an extra cost. SMS messaging requires the Identity Verification Credits add-on license. Purchasing the license gives your org a predetermined number of SMS messages for mobile identity verification.

Identity Connect License

• To use Identity Connect, purchase the Identity Connect license. Identity Connect integrates Microsoft Active Directory (AD) with Salesforce. User information entered in AD is shared with Salesforce seamlessly and instantaneously. Companies that use AD for user management can use Identity Connect to manage Salesforce accounts

Identity Connect

• Identity Connect provides Active Directory (AD) integration, so users can log in with AD credentials and connect to Salesforce using Single Sign-On. Changes made to AD are automatically synchronized with Salesforce, simplifying lifecycle management when AD is the source of identity information.

• Identity Connect is a Salesforce Identity product that helps Salesforce admins apply all the data collected in AD to automate Salesforce user management. It syncs changes in AD within seconds.

Synchronize Salesforce with Active Directory

With Identity Connect, you can manage Salesforce users by relying on the data already entered in AD. Identity Connect constantly monitors AD and updates Salesforce when changes in AD occur. Syncing can occur in near real time, on a regular schedule, or both.

When Identity Connect detects differences between AD and Salesforce, it updates Salesforce with the information in AD. Data transfer is in one direction and AD is the source of truth. Identity Connect never changes information that's stored in AD. Note-If you change the user in Salesforce, the Salesforce changes go away with the next sync. Nothing to worry about, though. You can tell Identity Connect not to update certain fields if you want to manage them in Salesforce.

Identity Connect feature

• Identity Connect is designed to work with multiple Salesforce orgs. You can set up Identity Connect to manage all these orgs simultaneously. Each org has its own Identity Connect mapping so you can control the user’s attributes and entitlements separately for each org.

• Identity Connect is on-premises software that sits behind your firewall and pushes data to Salesforce.Most companies use firewalls to control inbound connections coming from outside their corporate network while allowing outbound traffic. That is, you can access the Internet from the office, but you’re required to be on a VPN to access internal resources from your home or coffee shop. The demilitarized zone (DMZ) is a subnetwork that separates your internal network from other untrusted networks, like the Internet. But it’s still on-premises, within the corporate network. Instead of installing Identity Connect behind the firewall, you can install it in the DMZ.

• You can set up Identity Connect to manage multiple production orgs. And you can set up Identity Connect to manage multiple non-production orgs. But you can’t mix production and sandbox orgs in one Identity Connect environment.

• For user provisioning, Identity Connect connects with Salesforce over REST APIs to validate and update user settings. These read and write operations count against the org’s API limits. 

• Live Updates Identity Connect monitors AD and updates Salesforce as changes occur. It’s not a full comparison of everything in both systems, though. So if either the Identity Connect or the primary AD server goes offline, it’s possible to miss AD changes that occurred during that time. Some changes might not propagate to Salesforce when the system comes back on line. That's where Scheduled Updates comes in. Schedule Updates Identity Connect makes a full comparison between AD and Salesforce. It collects all user and group information from AD and Salesforce and compares all the data. If any differences exist, Identity Connect updates Salesforce with the data from AD.

Salesforce recommends using Schedule Updates at most once per day. Most customers run Schedule Updates every night or every weekend. Even though the mechanism ensures that the data is in sync, Scheduled Updates consume more resources—including API calls. Live Updates has less impact on API limits because Identity Connect connects to Salesforce only when it detects changes to user settings in AD.

• Disable Salesforce passwords to ensure that your users log in to Salesforce with their AD credentials. Without a Salesforce password, users can never bypass Identity Connect when logging in. Disabling Salesforce passwords is also a big win for reducing compliance overhead. Set your password strength requirements in AD and force all users to use that password. Then you can simply test AD password strength to demonstrate compliance. Note-To disable passwords, Salesforce Support must enable Delegated Authentication. Then you can set Is Single Sign-On Enabled on the profile of users who won’t have a Salesforce password.

• Report-From the Identity Connect console, you can generate different types of reports for different stages. Run a reconciliation report before syncing. It reports how many users in Salesforce don’t map to AD.After a sync, run a synchronization report to troubleshoot failed sync operations. It lists all the synchronization operations that occurred, along with the date, number of records synced, and number of records that failed to sync.Run a User Activity report to see which users succeeded and which users failed to log in to Identity Connect.

• Deploy an Identity Connect cluster of multiple servers to ensure Identity Connect works even when one server goes down. This way, you can make sure Identity Connect is always available on your network.If your primary server goes down, the backup servers can still handle requests. This is called a high-availability cluster.

Identity Connect Benefit

Provision Users

• With Identity Connect, you can quickly set up users with Salesforce.

• Provisioning users manually is error-prone and time-consuming. By using Identity Connect to automatically onboard (and offboard) users, you streamline the process of creating users and managing their access to apps and data. Instead of duplicating the effort to create users and set up permissions, use the information that's already stored in AD.

Single Sign-On (SSO)

• You can set up single sign-on (SSO) with Identity Connect so that users can access Salesforce with their AD credentials.

• When users are added to AD, they can access Salesforce with the same username and password they use for AD.

• Users don't need to remember an extra username and password. You don't have to manage separate user credentials in Salesforce. 

Assign Salesforce Permissions

In AD, users are granted permissions using AD Groups. In Salesforce, we use profiles, permission sets, roles, and public groups. With Identity Connect, you can map permissions in AD to permissions in Salesforce.

When users are added to or removed from a group in AD, they’re automatically added or removed from the mapped profiles, permission sets, roles, and public groups in Salesforce.

To assign Salesforce permissions from AD, choose which AD groups correspond to Salesforce permissions. AD Group can control below items through Identity connect.

1. Profile Mapping

2. Role Mapping

3. Permission set Mapping

4. Public group

Delegated Authentication

• As the name suggests, in delegated authentication, authentication is delegated to an external party. With delegated authentication, Salesforce has no control over the passwords used to log in to your org. Instead, the external authentication method controls user passwords and associated policies.

• With Delegated Authentication, the user logs in through the normal Salesforce login page, but Salesforce checks with a third-party server for the password. In this case, the user literally has no Salesforce password and cannot log in without the authentication server's permission.

• Example-For example, your company uses an LDAP server for its employees. You want to use the LDAP server to authenticate users into Salesforce. You also want to use permissions on the user profile to determine whether users authenticate with LDAP or Salesforce. Specifically, you want users with standard profiles to log in with a password managed by the LDAP server, while system administrator profiles use a Salesforce password. So, you integrate your org with your LDAP server by wrapping the LDAP server in a SOAP-based web service. You create permissions so that only users with standard profiles use delegated authentication. Now, users with standard profiles enter a Salesforce username and the LDAP server handles their password. Users with system administrator profiles enter their Salesforce username and password.

Delegated Authentication’s Flow 

1. When a user tries to log in (either online or using the API), Salesforce tries to validate the username and checks the user’s permissions and access settings.

2. If the “Is Single Sign-On Enabled” user permission is enabled, Salesforce calls the SOAP-based SSO web service to validate the username and password.

3. The web service call passes the username, password, and source IP to your SSO web service implementation, which Salesforce servers then access. The source IP is the address where the login request originated.

4. Your SSO web service implementation validates the passed information and returns either true or false.

5. When the response is true, the login process continues and the user is logged in to your org. When false, the user gets an error message that the username and password combination is invalid.

   
   
   

How to configure Delegated Authentication?

To configure Salesforce for delegated authentication: Follow the instructions in the Salesforce documentation to enable delegated authentication single sign-on for your organization.

1. After delegated authentication has been enabled at Salesforce, complete the following configuration steps:

1. Enable delegated authentication for your org-

1. From Setup, in the Quick Find box, enter Single Sign-On Settings, then select Single Sign-On Settings.

2. Select Disable login with Salesforce credentials

2. Build your web service.

3. Specify your delegated authentication gateway URL:

Click Your Name > Setup > Security Controls > Single Sign-On Settings > Edit.

Enter the URL for the Delegated Gateway URL

4. Enable permissions-Enable the Is Single Sign-On Enabled permission for all the users you want to use delegated authentication

Some Use Case

Restricting certain users to log in only using federated SSO and not by regular salesforce users and passwords using login.salesforce.com or my domain url. This can be achieved by using delegated authentication. You can refer to below article  https://www.youtube.com/watch?v=ivYsRZUYlXw 

Consideration 

• Orgs implementation of Web service must be accessible from Salesforce servers. Deploy the web service on a server in DMZ.

• If Salesforce and your system can’t connect, or if the request takes longer than 10 seconds to process, the login attempt fails. The user gets an error message indicating that the corporate authentication service is down.

• Namespaces, element names, and capitalization must be exact in SOAP requests.

• Wherever possible, generate your server stub from the WSDL file to ensure accuracy.

• Make web service available by TLS. A certificate from a trusted provider, such as Verisign or Thawte, is required

• The IP address that originated the login request is sourceIp. Use this information to restrict access based on the user’s location.

• Ensure that Salesforce IP Addresses are whitelisted on the corporate firewall.

• Map org’s internal usernames to your Salesforce usernames.

• Do not enable SSO for admins to ensure that they are not locked out when the web service is down.

• Delegated authentication is managed at the permission level and not at the org level

• Password reset is disabled for delegated authentication because Salesforce no longer manages user passwords. Users who try to reset their passwords in Salesforce are directed to their Salesforce admin

Troubleshoot Delegated Authentication Login Errors

• Admins with the Modify All Data permission can view the 21 most recent login errors for your Salesforce org. From Setup, in the Quick Find box, enter Delegated Authentication Error History, then select Delegated Authentication Error History. For each failed login, you can view the user's username, login time, and the error. 

oAuth 2.0

OAuth 2.0 is a framework used to allow secure data sharing between applications. The user works in one app but sees the data from another.  For example, you’re logged in to your Salesforce mobile app and see your data from your Salesforce org. Behind the scenes, the apps perform a kind of handshake and then ask the user to authorize this data sharing. When developers want to integrate their app with Salesforce, they use OAuth APIs. Here are a couple of examples.

• A mobile app that pulls contacts from a Salesforce org uses OAuth.

• A Salesforce org that gets contacts from another service also uses OAuth.

• Workbench uses oAuth 2.0 protocol for connecting with salesforce.

Connected App

• Connected app framework controls external applications to salesforce

• Connected app uses standard protocols such as SAML,oAuth, OpenConnect

• There are four main use cases for which your org can implement connected apps. 

• Access Data with API Integration- You can use a connected app to integrate external applications with the Salesforce API, such as a web-based app that pulls in order status data from your Salesforce org. 

• Integrate Service Providers with Your Salesforce Org- You can also use connected apps to integrate service providers with your Salesforce org, 

• Manage Access to Third-Party Apps- To set security policies to control what data a third-party app can access from your org. 

• Provide Authorization for External API Gateways- You can configure a connected app to provide authorization for external API gateways, such as API gateways hosted on MuleSoft’s Anypoint Platform.

Connected app owner vs connected app consumer

As a connected app owner, your org built the app. You can edit the app’s characteristics and manage its access policies. For example, you decide the type of information (such as a client secret) that the connected app must provide to gain access to data in your org. So how can you easily tell whether your org owns a connected app? The best way is to locate the connected app in the App Manager, click the dropdown arrow next to it, and see which options are provided.

As a connected app consumer, your org installed the app from the AppExchange, as a managed package from another org or a third-party vendor’s website, or as metadata without packaging. You can edit only the app’s access policies, such as who can use the app and whether the app can access data from a remote location.

Tokens

Salesforce uses OAuth protocol to allow users of applications to securely access data without having to reveal the username and password credentials. Now the question is how it works without a password? The answer is Token. With the help of Token, it connects to other applications. There are the following types of tokens:

1. Authorization code- 

1. The authorization server creates an authorization code, which is a short-lived token and passes it to the client after successful authentication. Only used in OAuth 2.0 with the web-server flow, the authorization code is a token that represents the access granted by the end-user. The authorization code is used to obtain an access token and a refresh token. It expires after 15 minutes.

2. The client sends the authorization code to the authorization server to obtain an access token and, optionally, a refresh token

2. Access Token - 

1. Instead of using the user’s Salesforce credentials, a consumer (connected app) can use an access token to gain access to protected resources on behalf of the user.

2. After a client is authorized, Salesforce sends the client an access token. The client passes the access token to the resource server to request access to protected resources. The resource server validates the access token and additional permissions in the form of scopes before granting access to the client.

3. The access token has a longer lifetime than the authorization code, usually minutes or hours. When an access token expires, attempts to use it fail, and the client must obtain a new access token by using a refresh token or reinitiating the authorization flow.

3. Refresh Token- 

1. Like a password, a client can repeatedly use a refresh token to gain access to the resource server. When a refresh token expires or a user revokes it outside of the client, the client requests a new access token, typically by implementing the authorization flow from the start.

2. A refresh token can have an indefinite lifetime, persisting for an admin-configured interval or until explicitly revoked. The client can store a refresh token and use it to obtain new access tokens. For security, the client must protect a refresh token against unauthorized access.

3. The OAuth 2.0 user-agent and the OAuth 2.0 web server flows can request refresh tokens if the refresh_token or offline_access scope is included in the request.

4. Id Token - Users for OpenId connect.

oAuth Scope

• Scope provides selective enabling of access to a user’s account based on required functionality

• In Salesforce, scopes control the types of resources available to an application. Some of the scopes are:

• Api - Allows access to the current, logged-in user’s account using APIs, such as REST API and Bulk API 2.0. This scope also includes chatter_api, which allows access to Connect REST API resources.

• Chatter_api

• Full - Allows access to all data accessible by the logged-in user, and encompasses all other scopes. NOTE full doesn’t return a refresh token. You must explicitly request the refresh_token scope to get a refresh token.

• Id- Allows access to the identity URL service. You can request a profile, email, address, or phone individually to get the same result as using id because they’re synonymous.

• Refresh_token-Allows a refresh token to be returned when the requesting client is eligible to receive one. With a refresh token, the app can interact with the user’s data while the user is offline. This token is synonymous with requesting offline_access.

• web- This scope allows the app to use the access token on the web, and allows access to customer-created Visualforce pages.

Manage Access to a Connected App

With the help if OAuth Policies, you can manage below two items:

1. Which Users Can Access the Connected App - Configure the Permitted Users policy. The Permitted Users policy defines whether users are pre-authorized to run the connected app. The Admin approved users pre-authorized option allows only users with the associated profile to access the app without first authorizing it. The All Users may self-authorize option enables anyone in the org to authorize the app after successfully signing in

2. Where Users Can Access the Connected App From-Under OAuth policies, click the IP Relaxation dropdown. These are the options you can choose from:

1. Enforce IP restrictions—This option enforces the IP restrictions configured for the org, such as the IP ranges assigned to a user profile.

2. Enforce IP restrictions, but relax for refresh tokens—Like the Enforce IP restrictions option, this option enforces the IP restrictions configured for the org, such as the IP ranges assigned to a user profile. However, this option bypasses these restrictions when the connected app uses refresh tokens to get access tokens. 

3. Relax IP restrictions for activated devices—This option allows a user running the app to bypass the org’s IP restrictions when either of these conditions is true.

1. The app has a list of allowed IP ranges and is using the web server OAuth authorization flow. Only requests coming from these IPs are allowed.

2. The app doesn’t have a list of allowed IP ranges. But it uses the web server authentication flow, and the user successfully completes identity verification if accessing Salesforce from a new browser or device.

4. Relax IP restrictions—This option allows a user to run this app without org IP restrictions.Although this option would allow Help Desk users to run the Customer Order Status App from a customer’s site, the user wouldn’t have to verify their identity to Salesforce. You want to maintain the security that authentication provides, so you don’t want to use this option for the connected app.

oAuth Flow

An oAuth authentication flow defines a series of steps used to coordinate the authentication process between your application and salesforce.

Salesforce provides you with a wealth of different flows - each serving a different purpose. For almost all flows, a connected app must be created in Salesforce first before a connection can be established.

1. User-Agent Flow (Mobile/Desktop App Integration)

2. Web Server Authentication Flow (Web Application Integration)

3. JWT Bearer Token Flow (Server to Server Integration)

4. SAML Bearer Assertion Flow

5. Refresh Token Flow

6. Username and Password Flow 

7. Device Authentication Flow (IoT Integration)

8. Asset Token Flow

User-Agent Flow (Mobile App Integration)

• It is used for mobile or desktop applications, for example, Dataloader, Salesforce1, or Mobile SDK.

• It allows a user to authenticate to a partner application using their Salesforce login credentials. Once logged, a user must approve that the partner application can access certain elements in Salesforce (you define those in your connected app). 

• This flow assumes by default that partner applications cannot be trusted, hence you should use this flow when your partner application cannot protect the client secret issued by Salesforce's connected app. 

• This, for example, is the case in mobile or desktop applications that you would like to connect to Salesforce where the source code of the application is accessible by the user and the client secret could be exposed easily. The benefit of this flow is that Salesforce issues a refresh token, meaning that even when your access token expires, you are able to obtain a new one by executing the refresh token flow. This will save the user from having to log in to Salesforce again.
  
  
  
  

Web Server Authentication Flow (Authorization code grant type)

• This is used for Web App Integration. If you are integrating an external web service (the Customer Order Status website) with the Salesforce API, you can use Web Server authentication flow if:

• Used for apps that are hosted on a secure server.

• If your application is capable of protecting the client's secret

• For example, you’ve recently developed a website that allows secure access to customer order status. The order status data is securely stored in your Salesforce CRM platform. To authorize Help Desk users to view a customer’s order status, you develop an Order Status app and configure it as a connected app with the web server flow.

• This flow still requires the user to actively log in to Salesforce and to approve access hence I would not use this flow when connecting API-only applications (such as an ESB or ETL tool that connects to Salesforce). 

• This flow also issues you refresh token and the user does not need to approve the access again.

JWT Bearer Token Flow (Server-to-Server Integration)

• In some cases, you need to authorize servers without interactively logging in each time the servers need to exchange information.If you want to connect an API-only application that essentially does not provide a UI that would allow a user to approve the external application, it would be strongly recommended the OAuth 2.0 JWT Bearer Token Flow.

• To provide authorization for server-to-server integration, you can use the OAuth 2.0 JSON Web Token (JWT) bearer flow. This flow requires prior approval of the client app.

• The OAuth 2.0 JWT Bearer Token Flow requires you to upload a certificate to your connected app that will be used to validate the JWT token. As the name of the flow already states, you will need to create a JWT token. This is basically a JSON file consisting of a header and claims object, where the header contains the signature algorithm and the object of the claim contains specific information such as the username and consumer key. At a high level, you will then sign the JSON object with the private key of your certificate and send the JWT to Salesforce to obtain an access token. This flow does not issue a refresh token and the server must create a new JWT token once the access token expires.

SAML Bearer Assertion Flow

• If your organization uses a central access control such as an active directory or LDAP store, it is likely that you would SSO to authenticate to your application. In this scenario, you may also want to use the SAML assertion from your SSO flow to obtain an access token to Salesforce. 

• This flow basically takes the SAML assertion (an XML token issued by your IdP) and applies a digital signature to it using a certificate. The connected app configuration in Salesforce is similar to the one done in the JWT Bearer Token Flow wherein a certificate is uploaded which is used to sign the SAML assertion.

Refresh Token Flow

As part of the web server and user-agent flows, a connected app can use a refresh token to request a new access token after the current access token expires. This flow is particularly helpful when you don’t want user intervention after an app is authorized.

Username-Password Flow-

• The OAuth 2.0 Username and Password Flow quite simply issues an access token in exchange for a username and password. This is not recommended using this flow unless there is absolutely no other way because you are sending the password unencrypted to Salesforce.

IoT Integration (OAuth 2.0 Device Flow)

• To integrate devices with limited input or display capabilities, such as Smart TVs, you can configure connected apps with the OAuth 2.0 device flow.

• With the device flow, end users can authorize connected apps to access Salesforce data using a web-based browser.

• For example, a customer uses your bluetooth device to control their house lights while they are away for the evening. You can create a connected app for the bluetooth device to enable this flow.

Reference

1. Web Server flow

2. Connected App