I have to admit that Identity and Access Management Designer exam was the toughest one from the Technical Architect journey. If you do not have any particular experience in Identity/Access management area then I recommend spending some time on deep study of the core concepts like SSO and OAuth.

About the exam:

A Salesforce Certified Identity and Access Management Designer assesses the architecture environment and requirements and designs sound and scalable technical solutions on the Force.com platform that meet Single Sign On (SSO) requirements. The candidate has experience communicating solutions and design trade-offs to business stakeholders.

Let’s start from the beginning and go through some basic concepts. Terms like authorization, identity or authentication will be repeated like mantra in all study materials. Basically:

• Authentication = login + password (who you are)
• Authorization = permissions (what you are allowed to do)

 

Source: https://blogs.vmware.com/vfabric/2013/03/putting-the-single-back-in-single-sign-on-sso.html

• Service Provider (SP) – broadly speaking it is an application that provides some service to the end user. It accepts identity from an identity provider
• Identity Provider (IdP) – is a trusted service that enables users to access other websites and services without logging in again

OAuth

OAuth (Open Authorization) is an open protocol to allow secure API authorization in a simple and standardized way from desktop and web applications. The Force.com platform implements the OAuth 2.0 Authorization Framework, so users can authorize applications to access Force.com resources (via the Force.com REST and SOAP Web Service APIs) or Chatter resources (via the Chatter REST API) on their behalf without revealing their passwords or other credentials to those applications. Alternatively, applications can directly authenticate to access the same resources without the presence of an end user.

Source: https://developer.salesforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com

Going through (not only once I guess) ‘Digging Deeper into OAuth 2.0 on Force.com’ article is a must! You have to be acquainted with different flows and know use cases for each of them.

• Web Server – users can authorize your web application to access their data, as described above. This is the OAuth 2.0 authorization code grant type.
  • Typically used for web applications where server-side code needs to interact with Force.com APIs on the user’s behalf
• User-Agent – users can authorize your desktop or mobile application to access their data, leveraging an external or embedded browser (or user-agent) for authentication – the OAuth 2.0 implicit grant type.
  • Difference with web server flow is that client cannot keep consumer secret confidential
  • Used for desktop & mobile apps
• Refresh Token Flow – Both web server flow and the user agent flow can provide a refresh token to provide user access once the access token has expired
• JWT Bearer Token Flow – your app can re-use an existing authorization by supplying a signed JSON Web Token (JWT) as described in JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants.
• SAML Bearer Assertion Flow – your app can also re-use an existing authorization by supplying a signed SAML 2.0Assertion, as specified in the SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants.
• SAML Assertion Flow – your app can federate with the API using a SAML Assertion, in much the same way as you would configure federation with Salesforce for Web single sign-on.
• Username and Password – your application can authenticate directly to Force.com using an ‘API user’s credentials – the OAuth 2.0 resource owner password credentials grant type.

Things to remember:

• Access Token – used by the client to make authenticated requests on behalf of the end user
• Refresh Token – may have an indefinite lifetime, persisting for an admin-configured interval or until explicitly revoked by the end-user. The client application can store the refresh token, using it to periodically obtain fresh access tokens, but should be careful to protect it against unauthorized access, since, like a password, it can be repeatedly used to gain access to the resource server.
• Oauth URL parameters
  • redirect_uri – The end user’s browser will be redirected to this URI with the authorization code. This must match your application’s configured callback URL
  • state – If a value was provided for the state parameter in the request, then that same value will be returned here

Question:

Universal containers (UC) wants to integrate a Web application with Salesforce. The UC team has implemented the Oauth web-server authentication flow for authentication process. Which two considerations should an architect point out to UC?

Choose two answers.

1. The web application should be hosted on a secure server.
2. The web server must be able to protect consumer privacy.
3. The flow involves passing the user credentials back and forth.
4. The flow will not provide an Oauth refresh token back to the server.

Connected App

Connected apps are designed to be run independently of the user interface. Either the app is hosted on an external website that interfaces with salesforce.com, or is a desktop or mobile app that runs on a client. Authenication for a connected app is client-initiated and must be done per-client. Connected apps are usually accessed outside salesforce.com, although this is not a stringent requirement. The session lifespan may be indefinite until revoked by the user or an administrator. the app has limited access to the user’s data (referred to as the scope), which may be as minimal as identity confirmation only up to full access. The app may be run on a server or client. Access must be manually granted.

Source: https://salesforce.stackexchange.com/questions/15494/whats-the-practical-difference-between-canvas-connected-apps

Creating new Connected App screen

Besides basic information like app’s name or contact info user has to provide oauth scopes:

 
Question:
A group of users try to access one of Universal Containers’ Connected Apps and receive the following error message:

“Failed: Not approved for access.”

What is the most likely cause of this issue?

Choose one answer.

1. The Connected App settings “All users may self-authorize” is enabled.
2. High Assurance sessions are required for the Connected App.
3. The Users do not have the correct permission set assigned to them.
4. The Salesforce Administrators have revoked the OAuth authorization.

Explanation: https://help.salesforce.com/articleView?id=000212208&language=en_US&type=1
 

Connected App Policies

The OAuth Policies section gives you control over how a connected app connects and who’s allowed to use it. In the OAuth Policies section, user can:

• Specify which users have access to the app
• Relax or enforce your organization’s IP restrictions for Salesforce1 users
• Determine how long a mobile user’s token is valid before requiring them to reenter their credentials

Source: https://trailhead.salesforce.com/en/modules/salesforce1_security/units/salesforce1_security_connected_app

• Permitted Users determines who can access app.
  • All users may self-authorize: Anyone in your org can install app and log in. Users must approve the app the first time they access it.
  • Admin-approved users are pre-authorized: App access is limited to users with the appropriate profile or permission set. These users don’t have to approve the app before they can access it. You can preauthorize users by editing the Connected App Access list for the appropriate profiles or permission sets.

• IP Relaxation refers to IP restrictions for your users. You can either enforce or bypass these restrictions.
  • Enforce IP restrictions: App users are subject to the org’s IP restrictions, such as IP ranges set in the user’s profile.
  • Relax IP restrictions with second factor: App users bypass the org’s IP restrictions if they successfully complete an identity verification.
  • Relax IP restrictions: App users aren’t subject to any IP restrictions.

• Refresh Token Policy specifies how long the user’s token for app is valid. When the token expires, users have to reenter their credentials to access app.
  • Refresh token is valid until revoked. The token is used indefinitely, unless you revoke it.
  • Immediately expire refresh token. The token is invalid immediately. The user can access the current session, but can’t obtain a new session without reentering credentials.
  • Expire refresh token if not used for. The token expires if it isn’t used in the specified amount of time.
  • Expire refresh token after. This setting expires the token after a fixed amount of time. For example, if the policy states 30 days, the token expires in a month even if the user is active in Salesforce1 on a daily basis.

 
Question:
Universal Containers (UC) has a mobile application that it wants to deploy to all of its Salesforce users, including customer Community users. UC would like to minimize the administration overhead.

Which two items should an architect recommend?

Choose two answers.

1. Enable the “Refresh Tokens is valid until revoked” setting in the Connected App.
2. Enable the “All users may self-authorize” setting in the Connected App.
3. Enable the “Enforce IP restrictions” settings in the Connected App.
4. Enable the “High Assurance session required” setting in the Connected App.

App Launcher

The App Launcher presents tiles for all the standard apps, custom apps, and connected apps in your Salesforce org. Your users can go to one location in Salesforce to access all the apps—without having to log in again. You choose which third-party and other connected apps to add the App Launcher. And you control which apps are available to which users.

Source: https://trailhead.salesforce.com/modules/identity_basics/units/identity_basics_product

Question:

Universal Containers (UC) has decided to use Salesforce as an Identity Provider (IdP) for multiple external applications. UC wants to use the Salesforce App Launcher to control the applications that are available to individual users.

Which three steps are required to make this happen?

Choose three answers.

1. Add each Connected App to the App Launcher with a Start URL.
2. Set up an Auth Provider for each External Application.
3. Set up Salesforce as a SAML Idp with My Domain.
4. Set up Identity Connect to synchronize user data.
5. Create a Connected App for each external application.

User Provisioning for Connected Apps

 

Source: https://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_identity_user_provisioning.htm

User provisioning for connected apps captures user events (such as creating a user, assigning a permission set or profile, or changing user information) in a Salesforce organization and applies updates to the corresponding account on a third-party service.

For example, you can configure user provisioning for a Google Apps connected app in your organization. Then assign the profile “Employees” to that connected app. When a new user is created in your organization and assigned the “Employees” profile, the user is automatically provisioned in Google Apps. Additionally, when the user is deactivated, or the profile assignment changes, the user is automatically de-provisioned from Google Apps. You can also configure an approval process to request a manager’s approval before a provisioning or de-provisioning action.

Source: https://www.youtube.com/watch?v=xCgy9ywYzuY

Custom Connected App Handler

Contains methods for extending the behavior of a connected app, for example, customizing how a connected app is invoked depending on the protocol used. This class gives you more control over the interaction between Salesforce and your connected app.

More: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Auth_ConnectedAppPlugin.htm

Question:

Universal Containers (UC) has a classified information system that its call center team uses only when they are working on a Case with a record type “Classified”. They are only allowed to access the system when they own an open “Classified” Case, and their access to the system is removed at all other times. They would like to implement SAML SSO eith Salesforce as the Idp, and automatically allow or deny the staff’s access to the classified information system based on whether they currently own an open “Classified” Case record.

What is the recommended solution for automatically allowing or denying the access to the classified information system based on the open “Classified” Case record criteria?

Choose one answer.

1. Use Salesforce reports to identify users that currently owns open “Classified” Cases and should be granted access to the classified information system.
2. Use Apex trigger on Case to dynamically assign Permission Sets that grant access when an user is assigned with an open “Classified” Case, and remove it when the Case is closed.
3. Use Custom Connected App Handler to dynamically allow access to the system based on whether the staff owns any open “Classified” Cases.
4. Use Custom SAML JIT Provisioning to dynamically query the user’s open “Classified” Cases when attempting to access the classified information system.

 

My Domain

 

Source: https://trailhead.salesforce.com/en/modules/identity_login/units/identity_login_my_domain

Instead of accessing your org through instance URL that Salesforce assigns you, like https://na32.salesforce.com you can create more personalized subdomain like https://salesforcememo.my.salesforce.com.

My domain is a key concept in SSO configuration. It also allows you to rebrand main login page:
 

Source: https://trailhead.salesforce.com/en/modules/identity_login/units/identity_login_my_domain

My Domain is required before you can use these Salesforce features:

• Single sign-on (SSO) with external identity providers
• Social sign-on with authentication providers, such as Google and Facebook
• Lightning components in Lightning component tabs, Lightning pages, the Lightning App Builder, or standalone apps

 

SAML

 

SAML defines an XML-based framework for communicating security and identity (e.g., authentication, entitlements, and attribute) information between computing entities. SAML promotes interoperability between disparate security systems, providing the framework for secure e-business transactions across company boundaries. By abstracting away from the particulars of different security infrastructures (e.g., PKI, Kerberos, LDAP, etc), SAML makes possible the dynamic integration necessary in today’s constantly changing business environments.

Source: https://www.slideshare.net/Salesforce/single-signon-and-federation-with-salesforce

SAML uses XML assertions to authenticate and authorize users, and also to communicate predefined attributes about users between IdPs and SPs. The three components of SAML are assertions, protocol and binding. Assertions carry authentication, user attribute and authorization data, as in the following subscription television example:

 

Source: http://www.gigya.com/blog/the-basics-of-saml/
 

Single Sign On (SSO)

 

Single sign-on (SSO) lets users access authorized network resources with one login. You validate usernames and passwords against your corporate user database or other client app rather than Salesforce managing separate passwords for each resource.

Benefits of Implementing SSO:

• Improved productivity – It takes an average of 20 seconds for a user to log into a resource. Not having to enter a password each time a user needs to access a resource saves time and makes users more productive.
• Increased adoption – SSO reduces the barriers of use for resources. Since it is easier to access applications, users will start using them more.
• Centralized user access control – A single registry of user identities with a centralized management interface allows quick and easy provisioning and deactivating of users.
• Improved reporting and monitoring – A single repository for auditing and logging access to resources provides streamlined regulatory compliance.
• Increased security – A secure, enterprise-wide infrastructure with common password and security policies that can be centrally managed and secured. Users are also less likely to write down their passwords when there is only one to remember.
• Uniform security layer – SAML is platform agnostic allowing enterprise architects to implement a uniform security layer with existing assets.
• Reduced helpdesk costs – Fewer helpdesk calls for password resets relates directly to bottom-line savings.

 

Source: https://raya003.wordpress.com/2015/06/20/single-sign-on-approach/

 
Two use cases for SAML:

• Identity Provider Initiated Login – a user starts directly at their identity provider, logs in, and is then redirected to a landing page at the service provider
• Service Provider Initiated Login – a user starts by clicking a link to the the service provider (e.g. a bookmark, mailed link, etc) and temporarily redirected to the identity provider for authentication, then returned to the link they initially requested

If you want to use Salesforce as a Service Provider you have to provide details about Identity Provider:
 

Source: https://trailhead.salesforce.com/modules/identity_login/units/identity_login_sso

• Issuer – information is provided by your IdP. The documentation mentions its an URL as in the Entity Id in <saml:Issuer> tag of the assertion
• Entity Id – basically that is base URL of my domain. It helps IdP to differentiate different Salesforce orgs
• Identity Provider Certificate – certificate provided by the IdP

If you want to make SSO work in SF1 you have to use my domain in custom domain section:
 

Source: https://jdspaceit.wordpress.com/tag/federated-idp-down-idp-initiated-login-salesforce-com-salesforce1-saml-saml-assertion-validator-single-sign-on-sp-initiated-login-spengo/

Things to remember:

• Federation ID – field on User’s record. The Federation ID is a unique username for each user that can be shared
  across multiple applications. Sometimes this is the employee ID for that user. The important part of the Federation ID is that it is not
  duplicated for more than one user within a single Salesforce organization (you can have the same Federation ID for the same user
  in more than one Salesforce organization)
  • Federation ID is case sensitive
• To troubleshoot SAML assertions:
  • paste your SAML assertion into the SAML Assertion Validator on the Single Sign-On Settings page
  • download SAML browser plugin to inspect requests & responses

 
Question:

Which three attributes can be used to represent the identity of the user when Salesforce is acting as a Service Provider in a SAML configuration?

Choose three answers.

 

 

1. Salesforce User ID.
2. Salesforce Username.
3. Federation ID.
4. User Email Address.
5. User Full Name.

 
Question:

Universal Containers (UC) has multiple Salesforce orgs and would like to use a single Identity Provider to access all of their orgs.

How should UC’s Architect enable this behaviour?

Choose one answer.

 

1. Ensure that users have the same Alias value in their user records in all of UC’s Salesforce orgs.
2. Ensure the same username is allowed in multiple orgs by contacting Salesforce Support.
3. Ensure that users have the same Email Address in their user records in all of UC’s Salesforce orgs.
4. Ensure that users have the same Federation ID value in their User records in all of UC’s Salesforce orgs.

 

Just-in-Time Provisioning

 
With Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance.

Source: https://www.slideshare.net/RoyGilad/salesforce-spring-15-release-overview-deck

The following are methods for SamlJitHandler.

• createUser(samlSsoProviderId, communityId, portalId, federationId, attributes, assertion)
  Returns a User object using the specified Federation ID. The User object corresponds to the user information and may be a new user that hasn’t t been inserted in the database or may represent an existing user record in the database.
• updateUser(userId, samlSsoProviderId, communityId, portalId, federationId, attributes, assertion)
  Updates the specified user’s information. This method is called if the user has logged in before with SAML single sign-on and then logs in again, or if your application is using the Existing User Linking URL.

 

Delegated Authentication

 
Delegated authentication SSO integrates Salesforce with an authentication method that you choose. You can integrate authentication with your LDAP (Lightweight Directory Access Protocol) server or use a token instead of a password for authentication. You manage delegated authentication at the permission level, not at the org level, giving you more flexibility. With permissions, you can require some to use delegated authentication while others use their Salesforce-managed password.

Benefits of Delegated Authentication:

• Uses a stronger form of user authentication, such as integration with a secure identity provider
• Makes your login page private and accessible only behind a corporate firewall
• Differentiates your org from all other companies that use Salesforce to reduce phishing attacks

You must contact Salesforce to enable delegated authentication before you can configure it on your org.

Source: https://chendamok.wordpress.com/how-to-enable-multiple-delegated-authentication-service-in-one-organisation/

1. In Salesforce, download the Web Services Description Language (WSDL) file AuthenticationService.wsdl from:
   • Setup by clicking Develop | API | Download Delegated Authentication WSDL
2. Add a link to your corporate intranet or other internally-accessible site that takes the authenticated user’s credentials and passes them through an HTTP POST to the Salesforce login page. Because Salesforce does not use the password field other than to pass it back to you, you do not need to send a password in this field.
3. In Salesforce, specify your organization’s single sign-on gateway URL from Setup by clicking:
   • Security Controls | Single Sign-On Settings | Edit. Enter the URL in the Delegated Gateway URL text box.
4. For security reasons, Salesforce restricts the outbound ports you may specify to one of the following:
   • 80: This port only accepts HTTP connections.
   • 443: This port only accepts HTTPS connections.
   • 1024–66535 (inclusive): These ports accept HTTP or HTTPS connections.

Things to remember:

• The web services call passes the username, password, and sourceIp to your web service. Source Ip is the IP address where the login request originated. You must create and deploy an implementation of the web service that Salesforce servers can access.
• Your web service implementation validates the passed information and returns either true or false.
• It is not advised to enable SSO for Salesforce admins. If your Salesforce admins are SSO users and your SSO server has an outage, they have no way to log in to Salesforce

Continue reading:

1. https://help.salesforce.com/articleView?id=sso_delauthentication.htm&type=0
2. http://developer.force.com/cookbook/recipe/enabling-single-sign-on-with-the-force-com-platform

Question:

Universal Containers (UC) wants to implement Delegated Authentication for a certain subset of Salesforce users.

Which three items should UC take into consideration while building the Web service to handle the Delegated Authentication request?

Choose three answers.

 

1. The web service needs to include Source IP as a method parameter.
2. UC should whitelist all Salesforce IP ranges on their corporate firewall.
3. The return type of the Web service method should be a boolean value.
4. Delegated Authentication is enabled for the System Administrator profile.
5. The web service can be done in either SOAP or REST protocol

 

Salesforce Identity Connect

 
Identity Connect integrates Microsoft Active Directory (AD) with Salesforce. User information entered in AD is shared with Salesforce seamlessly and instantaneously.
 

Source: https://www.youtube.com/watch?v=kNRHsHcphg0

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.
 

Source: https://trailhead.salesforce.com/modules/identity_connect/units/identity_connect_other

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.

 

 

Source: https://www.slideshare.net/perficientinc/tips-webinar-salesforce-identity-final-distro

Things to remember:

• On-premise identity service with a browser-based admin UI
• Supports Windows, OSX and Linux hosts
• Integration includes syncing Active Directory users with one or more Salesforce orgs
• Possible mappings:
  • AD Group membership to User Profile
  • AD Group membership to Permission Set
  • AD Group membership to Role
  • AD Group membership to Salesforce Group
• You have to buy special Salesforce Identity Connect (separate from Salesforce Identity) license for each user
• Identity Connect acts as the Identity Service Provider (IDP) for Single Sign On (SSO)

Continue reading:

1. https://trailhead.salesforce.com/modules/identity_connect
2. https://audit9.blog/2014/02/22/salesforce-identity-connect/
3. https://resources.docs.salesforce.com/rel1/doc/en-us/static/pdf/identity_connect_impl_guide.pdf

 

Login Flows

 

When a user’s profile is associated with a login flow, the user is directed to the flow as part of the authentication process. The login flow screens are embedded in the standard Salesforce login page.

Source: https://help.salesforce.com/articleView?id=security_login_flow_create.htm&type=0

•  Make use of all basic aspects of Visual Flows
  • UI Elements
  • Logic Elements
  • Data Elements Bound to a Profile
• Initiated by user’s login event
• Can be assigned to certain Salesforce profile

Login Flow Use Cases

•  First time User Acceptance of Terms and Services
•  Gather More Information On First Time User of Communities
  • “Login Wizards”
  • Gather interests about community user to automatically subscribe to various data categories
  •  Gather information about user’s job role
• Custom two-factor authentication for certain scenarios (for example if user is outside Trusted IP Range)
  • SMS-based two-factor authentication (2FA) 

Continue reading:

1. https://www.slideshare.net/developerforce/advanced-uses-of-salesforces-login-flows
2. https://jenwlee.wordpress.com/2015/11/03/temporarily-remove-a-permission-set-w-process-builder-flow/
3. https://www.youtube.com/watch?v=gYes8OLAc-k

Two-Factor Authentication and Salesforce Authenticator

 
Two-factor authentication (2FA) is a security feature Admins can enable that adds a second layer of security to the user authentication process. Two-factor authentication requires users to provide two forms of validation to access their online account.

What are the two factors?

• Something users know, like their password
• Something users have, such as a mobile device with an authenticator app installed

 

Source: https://trailhead.salesforce.com/trails/identity/modules/identity_login/units/identity_login_2fa
 
How to Setup 2FA?

1. Create permission set with enabled Manage Two-Factor Authentication in User Interface permission (under System Permissions).



2. Assign the permission set to the users that you want to use 2FA. Now every user with that permission will have to use Salesforce Authenticator app to log into Salesforce.

Salesforce Authenticator

 
Salesforce Authenticator is a smart and simple app that can be used with two-factor authentication on your Salesforce org.

Salesforce Authenticator tells the user:

• What action needs to be approved
• What user is requesting the action
• From which service is the requested action coming
• What device the user is using
• From what location would the user approve or deny this request

Source: https://www.salesforce.com/assets/pdf/app-cloud/2fa-admin-rollout-guide.pdf

What if I lose my device or don’t have my phone available?

With Salesforce 2FA, admins can generate temporary tokens to enable users specific and one-time access to their accounts. Also, with Salesforce Authenticator v2.6 or greater, users may enable the Backup and Restore feature to recover their connections on a new device from a previously enrolled device.

Is 2FA available for my edition of Salesforce? Is it a paid feature?

Two-factor authentication is a free resource available on all editions of Salesforce.

Communities

When you setup Community you can choose to allow users to self register:
 

Source: https://trailhead.salesforce.com/modules/identity_external/units/identity_external_registration

What happens behind the scenes?

• Salesforce creates a User record and Contact with the information that the registrant provides on the self-registration page.
• Salesforce associates the Contact with an Account, in our case, Customers. You created the account earlier as part of setting up your org.
• The User record is assigned the Customers profile

If you want to customize self registration behaviour you can either:

• update default CommunitiesSelfRegController class
• create custom Visualforce or Community Builder self-registration page

External Identity License

 
An External Identity license grants Identity features such as the App Launcher and single sign-on to external users. With External Identity, you can give your customers and partners access to your org through an external identity community.

Source: http://releasenotes.docs.salesforce.com/en-us/winter15/release-notes/rn_forcecom_security_external_identity.htm

Things to remember:

• The External Identity license gives you the flexibility to add users to your community site without using Customer Community license.
• Allow user self-registration for efficient provisioning of new users
• Typically consumers for your business, partners, dealers, patients, and other customers

Social Sign-On

Salesforce has several auth providers to choose from—more, if you count those auth providers that your developers can configure using the OpenID Connect protocol. And even more—if your developers want to create their own authentication provider, they can use Salesforce APIs to do so.

Source: http://docs.releasenotes.salesforce.com/en-us/winter15/release-notes/rn_forcecom_security_authprovider_icon.htm

Source: https://www.slideshare.net/yujiyasuno/social-login-with-salesforce-communities

Registration Handler – (sometimes called reghandler) creates and updates a user on the fly with identity information pulled from the auth provider, in this case, Facebook. A registration handler allows you to get additional information from Facebook, like a profile picture, to use when creating the Salesforce user.

Canvas Apps

Canvas apps are designed to the part of the user interface. Either the app is designed to appear to be native to salesforce.com, like a Visualforce page, or is intended to be accessed through salesforce.com, such as legacy cloud apps.

Authentication for a canvas app is server-initiated and controlled by profiles and permission settings. The app cannot be accessed outside salesforce.com unless it provides an alternative login mechanism. The session lifespan is only as long as the user is logged in to the user interface. The app has full access to the user’s data, just as any normal API-style application. The app must be cloud-based. Access is automatically granted.

More: https://salesforce.stackexchange.com/questions/15494/whats-the-practical-difference-between-canvas-connected-apps

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 you configure the canvas app so that 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 if the administrator has allowed access to the canvas app for the user or if the user has approved the canvas app via the approve/deny OAuth flow.

Source: https://www.slideshare.net/suyatitech/integration-dotnet-with-forcedotcom-canvas-webinar-31293499

• OAuth 2.0—Canvas apps can use the OAuth 2.0 protocol to authenticate and acquire access tokens.

Source: https://www.slideshare.net/suyatitech/integration-dotnet-with-forcedotcom-canvas-webinar-31293499

Certificates

When sending outbound messages, delegated authentication requests or Apex callouts to secure/SSL endpoints (e.g. https://myintegration.acme.com), a Salesforce.com organization (acting as the client) will only trust the target host (that will act as the server) if this presents a certificate signed by a root Certification Authority (CA). In other words, in this scenario self-signed certificates are not allowed to be used by the target host.

When using mutual authentication/2-way SSL, Salesforce.com can present a self-signed certificate to the target host (that must present a CA signed certificate to Salesforce), provided that this certificate has been configured in the target host (installed in the target server’s keystore).