CTA Security SSO & OAuth Flows

1. Customer Registration & Login

1.1. Registration

1.1.1. Social Registration

1.1.1.1. Match email with known emails, then use login flow to onboard

1.1.2. Registration

1.1.2.1. Configurable Self-Reg Page Autogenerate handler, then modify

1.1.2.2. Use a builder or VF page

1.2. Login

1.2.1. Web Server Flow / OIDC SSO

1.2.1.1. /services/oauth2/authorize *** Response Type = *** Code client id, redirect URL [Scope, State]

1.2.1.2. After login and consent, Salesforce redirects users to the callback URL, where they can view the callback with an authorization code.

1.2.1.3. POST /services/oauth2/token grant_type=authorization_code, code=..., client id, *** client secret redirect URL

1.2.1.4. Returns: access token, scopes, signature signed with client secret [id token & Refresh Token if in scope]

1.2.1.5. OIDC

1.2.1.5.1. OIDC=Web Server Flow w/ openid scope Auth Provider + Apex reg. handler AuthProviderPlugin for customization: getC.M.D, Initialize, handleCallback, getUserInfo, refresh POST to UserInfo; but some OIdP only support GET

1.2.1.5.2. Better than SAML? Authorization, Scopes

1.2.1.5.3. SF managed: FB, LI, G+, Twitter, Github, Jainrain Salesforce OIDC (Auth0 is supported)

1.2.2. Community Login Discovery Passwordless login

1.3. Login Flow

1.3.1. Customer onboarding IP based MFA Limit the # of concurrent sessions MFA using Twilio SMS

1.3.2. Create screen flow or VF page Designate as login flow Associate with profiles

1.4. Custom Domain for Sites 1. Create a DNS CNAME for your site. 2. Upload a CA-signed certificate. 3. Create a site domain, choose the certificate.

1.5. 50K portal users per account owner. CC users are not limited

2. Mobile Login

2.1. User Agent Flow

2.1.1. /services/oauth2/authorize *** Response Type = ***token client id, redirect URL [Scope, State]

2.1.2. After login and consent Salesforce redirects the user to the callback URL with an access token.

2.1.3. Refresh token is returned if (1) Connected app allows Refresh Token (2) Redirect URL uses a custom protocol: mymobileapp://callback <org or site>/services/oauth2/success https://mobileauth.salesforce.com/oauth/done

2.1.3.1. Mobile Advanced Authentication

2.2. Refresh Token Flow

2.2.1. POST /services/oauth2/token grant_type=***refresh_token, client id, client secret, refresh token

2.2.1.1. How to authorize conditionally? How to someone conditionally from login with Refresh Token? Custom Connected App Handler ConnectedAppPlugin authorize(), refresh()

2.3. Hybrid App Token Flow

2.3.1. response_type= *** hybrid_token Scopes: refresh_token, web, api, lightning, content, visualforce

2.4. Hybrid App Refresh Token Flow

2.4.1. grsnt_type=***hybrid_refresh

2.5. A mobile app access multiple communities & orgs

2.6. PKCE Flow

2.7. MDM & Certificate based authentication

3. Partner Registration & Login

3.1. Partners in LDAP => API integration for user provisioning. Agree upon Federation ID

3.1.1. Okta: User creation API returns back the activation link

3.2. Can PC user owns account? Yes if there is no need to create users for the account

4. Employee Login

4.1. SAML SSO Request Signing Certificate Identity Provider Certificate Assertion Decryption Certificate

4.1.1. IdP initiated

4.1.2. SP initiated * Relay State

4.1.2.1. When the user click on a deep link or the SSO login button, SF redirect them the IdP to login. After login, IdP redirect them back to SF with a SAML assertion. SP initiated request binding: POST No matter what request binding you select, the SAML response always uses HTTP POST binding.

4.1.3. JIT provisioning

4.1.3.1. Federation ID is required

4.1.3.2. Auth.SamlJitHandler

4.1.4. Okta IWA web agent for DSSO, which works with the browser, Kerberos, and AD. Recommended is an Agentless SSO configuration.

4.1.5. Identity Store: Assume AD

4.2. Frontdoor.jsp No login flow!!! Need full token

4.2.1. NOTE You can’t apply login flows to API logins or when sessions are passed to the UI through frontdoor.jsp from a non-UI login process.

4.2.1.1. Frontdoor.jsp respects MFA profile session level requiremen :-)

4.2.1.2. Frontdoor.jsp works for community user also. Make sure to use community URL,

4.3. Legacy app to Salesforce Navigation

4.3.1. SAML: Oracle supports SAML

4.3.2. Delegated Authentication

4.3.2.1. (1) Enable delegated authentication (2) Build SOAP web service. (3) Open firewall, protect API with M-TLS (4) Specify delegated gateway URL. (5) Enable permissions: Is Single Sign-On Enabled

4.3.2.2. To make it more secure, use a webpage to authenticate the user and get an auth token (kerberos ticket) to be used for the SF login password field. POST to the Salesforce login page.

4.3.2.3. M-TLS certificate: API Client Certificate (Share with Outbound Message)

4.3.2.4. No need for Remote Site listing! Can't use Named Credential!

4.3.3. Frontdoor.jsp No login flow!

4.4. My Domain Login Discovery

4.5. Lightning Login

4.5.1. SF Authenticator login is MFA

5. Security & Session Settings

5.1. Session Related Settings

5.1.1. MFA

5.1.1.1. Permission: MFA for UI login

5.1.1.2. MFA by IdP

5.1.1.3. Add MFA to High Assurance column on Session Setting page

5.1.2. High Assurance Session

5.1.2.1. Profile: Session Security Level Required at Login = High Assurance

5.1.2.2. Applies to SF login, delegated authentication, SAML SSO, OIDC SSO

5.1.2.3. Can declare any authentication method as High Assurance or Standard on Setup: Session Settings page

5.1.3. Session-based Permission Set

5.1.3.1. Use Flow to Activate Session-based Permission Set 1. Create a permission set, select [*] Session Activation Required 2. Assign it to users. 3. Flow activate or deactivate Core Actions: Activate ... Enjoy the permissions Deactivate ...

5.1.4. Identity Verification

5.1.4.1. Controls how & why users are prompted to verify their identity

5.1.4.2. Session Security Level Policy Block or Require High Assurance for sensitive operations * Report and Dashboard, * Data Export * Manage Auth. Provider, * Connected App, * Certificates, * IP addresses, * Login Access Policies, * Password Policies, * MFA, * Profiles and Permission Sets, * Roles, * Sharing, * Users, * View Health Check

5.1.5. Session settings The Session Settings page allows us to configure many security mechanisms

5.1.5.1. XSS protection

5.1.5.2. HttpOnly Cookie A flag on a cookie to prevent client side script access => prevent Cross Site Scripting XSS attack

5.1.5.3. Clickjack Protection

5.1.5.4. Cross-Site Request Forgery (CSRF) Protection

5.1.5.5. [*] Allow Lightning Login [*] Allow only for user with Lightning Login User permission

5.1.5.6. CSP: a web standard Content Security Policy protection

5.1.5.6.1. CSP is a web standard Specifies the domains as valid sources of executable scripts. Enforced by compatible browser. Mitigate cross site scripting attack

5.2. Security Settings

5.2.1. CSP Trusted Sites for Chat

5.2.1.1. Chat on community page 1. Need CSP relaxation 2. Need to add chat endpoint as a CSP trusted site

5.2.2. CORS: Web Standard Cross Origin Resource Sharing used for Embedded Login

5.2.2.1. CORS is set on the server side to relax the same origin policy for AJAX calls. Allow webpages from listed origins/domains to request resource (JavaScript, CSS, ...) from Salesforce. Implemented with HTTP headers to be returned by the server to tell the browser: Yes, I allow this access.

5.2.3. Network Access

5.2.3.1. Trusted IP Ranges Computers no need to activate

5.2.4. Private Connect

5.2.5. Remote Site Settings

5.2.5.1. List web addresses that your organization can invoke from salesforce.com.

5.2.6. File Upload & Download Policy

5.2.6.1. Download, Execute in Browser Hybird: Attachment and document records execute in the browser. Salesforce Files are downloaded.

6. Username-Password Flow

6.1. grant_type=password Access token can't be introspected. No refresh token Experience Cloud sites don’t support the OAuth 2.0 username-password flow.

7. Integration via ESB

7.1. ESB->SF JWT Bearer Flow

7.1.1. Uses a certificate to sign the JWT request and doesn’t require explicit user interaction This flow never issues a refresh token.

7.1.2. Admin approved users are pre-authorized. => Standard and custom scopes assigned to the connected app are returned with the access token.

7.1.3. Salesforce requires that a JWT is signed using RSA SHA256 Header: "alg":"RS256" ISS=client_id AUD=Login | Salesforce test site-url SUB=username or $User.FederationIdentifier EXP Signature with private key

7.2. SF -> ESB JWT Bearer Flow

7.2.1. Named Credential Auth. Provider

7.2.1.1. JWT can support Per User Identity Type

7.3. M_TSL

7.3.1. 1. Client sends requests 2 Server returns its public certificate + server hello. 3. Client validates/verifies the received certificate. 4. Client provides its public certificate to the server. 5. Server validates/verifies the received certificate. 6. Transfer data with each other encrypted with the secret keys shared. 7. Use port 8443

8. IoT Integration

8.1. Device Flow Limited Input

8.1.1. To integrate apps that run on devices with limited input or display capabilities, such as Smart TVs, appliances. Users can connect these apps to Salesforce by accessing a browser POST /services/oauth2/token *** response_type=*** device_code Refresh token can be returned!

8.2. Asset Token Flow

8.2.1. Allow registration of device data with the Salesforce platform and linking the device to Salesforce CRM data about the customer, account, or contact. Salesforce attempts to link the asset token to an existing asset: ID (asset id), serial number. Or create an asset with asset name, AccountId, ContactId.

8.2.2. POST /services/oauth2/token grant_type=...:token-exchange *** Actor Token, Asset Token: JWT

8.2.3. Set valid for on connected app

8.2.4. Select signing cert on connected app Validate with public cert

9. SAML for API

9.1. OAuth 2 SAML Bearer Assertion Flow - Need a connected app Like JWT, need prior approval. Use admin approve by profile

9.1.1. Create a connected app and register an X509 Certificate. Generates a SAML assertion and signs it with the private key. Use a signed SAML 2.0 assertion to request an OAuth access token. Issuer Audience=login.salesforce.com Recipient: .../services/oauth2/token Subject NameID = username POST /services/oauth2/token grant_type: .../saml2-bearer

9.2. SAML Assertion Flow Need a SSO setting

9.2.1. Clients can federate with the API using a SAML assertion, the same way they federate with Salesforce for Web SSO. Configure SSO setting and load certificate. Find the OAuth 2.0 Token Endpoint POST /services/oauth2/token grant_type=assertion Use this URL when exchanging a SAML assertion for an access token to access the API. Since this for API integration, no login flow will be invoked. No refresh token.

9.2.1.1. The SAML assertion is Base-64 encoded, then URL encoded

10. Shield Classic Encryption Data Mask

10.1. Classic Encryption

10.1.1. Permission: View Encrypted Data

10.2. Shield

10.2.1. Encryption

10.2.1.1. Tenant Secrets Copy to Sandbox, so rotate

10.2.1.2. Chatter posts, Q&A, ... Files and attachments, Search Indexes Platform Events Analytics

10.2.1.3. Probabilistic vs Deterministic

10.2.1.4. Encrypted field can't be used in CBS, flow query, external lookup, as filters, aggregates

10.2.1.5. AppExchange app may not work with encrypted standard fields

10.2.2. Event Monitoring

10.2.2.1. Event Manager

10.2.2.1.1. Among >50 event types 16 are managed by Event Manager

10.2.2.2. Transaction Security Policies (Enhanced Transaction Security)

10.2.2.2.1. Condition Builder

10.2.2.2.2. Apex implement TxnSecuity.EventCondition Not trigger!

10.2.2.3. Permission: Real-Time Event Monitoring Data

10.2.3. Field Audit Trail

10.2.3.1. History Retention Policy: Define with metadata API

10.2.3.2. Big Object: FieldHistoryArchive Permission: Retain Field History

10.2.3.3. Can't track Formula field

10.3. Data Mask

11. Salesforce as IdP

11.1. SAML 2.0

11.1.1. Org | Community as IdP; Org | Community as SP

11.1.1.1. Single Sign Out: SP side config: IdP Single Logout URL IdP side connected app specify SP Single Logout URL

11.2. Community specific OIDC endpoints

11.3. ODIC

11.3.1. Allow any API user integrate with Salesforce or navigate to SF using frontdoor.jsp

11.4. Identity Connect

11.4.1. SAML SSO

11.4.2. AD -> SF one way sync

11.4.3. API integration for user provisioning & deprovisioning using Web Server Flow with a Connected App

11.5. External Identity

11.5.1. External Identity Add the profile to a community for users to login to the community, which serves as as IdP or OIdP hub

12. Connected App

12.1. Enables an external application to integrate with Salesforce. (1) API integration (2) SAML or OIDC (3) Manage access with "Admin approved users are pre-authorized" (4) Auth for external API (Dynamic Client ...)

12.1.1. OIDC Dynamic Client Registration for MuleSoft

12.1.1.1. Use OpenID Connect dynamic client registration to enable your Salesforce instance as an independent OAuth authorization server to protect resources hosted on an external API gateway.

12.1.2. OIDC Connect Token Introspection

12.1.2.1. /services/oauth2/introspect An OAuth client that directly registers OAuth 2.0 connected apps through the dynamic client registration endpoint can check the state of access and refresh tokens for itself and its registered connected apps.

13. Named Credential

13.1. Named credentials are supported in these types of callout definitions: Apex callouts External Services External data sources of these types: Salesforce Connect: OData 2.0 Salesforce Connect: OData 4.0 Salesforce Connect: Custom Not for Salesforce Connect: Cross Org

14. Special Integration

14.1. Connectors

14.1.1. Marketing Cloud & MC Connector

14.1.1.1. MC supports SSO

14.1.1.2. MC -> SF: OAuth Web Server Flow A Salesforce system user is used Configure connected app in Salesforce

14.1.1.3. SF -> MC: Use MC API user credentials Supports JWT now

14.1.1.4. MC API: OAuth Client Credential

14.1.2. Pardot

14.1.2.1. SSO lets users log in to Pardot with their Salesforce credentials.

14.1.2.2. User Sync transfers user management to Salesforce and Pardot user records become read-only. User Sync is the recommended method for managing Salesforce and Pardot users.

14.1.2.3. SF -> Pardot: ?

14.1.2.4. Pardot -> SF: JWT flow with Pardot Authentication User

14.1.2.5. Pardot API accepts SF Access Token Pardot Business Unit iIs is needed API call

14.1.3. Heroku Connect

14.1.3.1. HC -> SF: Use an system user Heroku Connect stores an OAuth token => Web Server Flow

14.1.3.2. External Objects service endpoints are protected by basic authentication.

14.2. Service Cloud Voice

14.2.1. Amazon Connect supports SSO

14.2.2. AWS->SF JWT

14.2.2.1. Connected App with certificate but also has refresh_token scope

14.2.2.2. AWS Lambda setup loads private key

14.3. Payment Integration

14.3.1. Tokenization

14.3.2. Paypal integration

14.3.3. Chargent

14.4. UI layer integration

14.4.1. Canvas App

14.4.1.1. POST signed request

14.4.1.2. GET + OAuth Flow

14.4.1.3. CanvasLifecycleHandler excludeContextTypes() onRender() Assign it on the connected app

14.4.2. Web tab

14.5. Connect All use Auth. Provider

14.5.1. SF Connect

14.5.1.1. Custom Http Header Formula using User, profile, role fields, not context page fields

14.5.2. Files Connect

14.5.3. CMS Connect

14.6. DevOps Login

14.6.1. JWT

14.6.2. Web Server Flow

14.6.2.1. One connected app is good for all orgs