Hey,
I have taken this exam in Sep 2019, and in my personal view, its by far - the most interesting certification among all the designer ones. As part of my write-ups series, I have been wanting to write about the learnings for this exam but didn't get a chance to post it for quite some time. Again, you'll find everything in Trailmix but I have consolidated the key topics/points which I've found really useful:
I have taken this exam in Sep 2019, and in my personal view, its by far - the most interesting certification among all the designer ones. As part of my write-ups series, I have been wanting to write about the learnings for this exam but didn't get a chance to post it for quite some time. Again, you'll find everything in Trailmix but I have consolidated the key topics/points which I've found really useful:
Salesforce supports the following identity solutions:
- SAML (Security Assertion Markup Language)
- OAuth (Open Authorization)
- OpenID Connect
Difference between Authentication and Authorization:
- Authentication - Who can access the resource
- Authorization - What can we access from the resource
OAuth 2.0 Components:
1) Roles / Actors
2) Scope / Consent [Parameter use to limit the right of access resource]
3) Flows / Grants /Pattern
4) Tokens
Access token — Short lived. After configuring an OAuth 2.0 connected app, generate an initial access token. Salesforce requires this token to authenticate the dynamic client registration request.
Refresh token — Long lived. A refresh token can have an indefinite lifetime, persisting for an admin-configured interval or until explicitly revoked. The client application can store a refresh token, using it to periodically obtain fresh access tokens.
To protect the token, the only hostname allowed with an HTTP callback URL is localhost. Other hosts must use HTTPS]
OAuth 2.0 Grant:
There are total five OAuth 2.0 grant:
- Authorization Code Grant
- Implicit Grant
- Resource Owner Grant
- Client Credential Grant [Machine to Machine - where client is the Resource Owner]
- Device Flow Grant
Salesforce OAuth 2.0 Flow:
There are total nine Salesforce OAuth 2.0 flows.
1) Web Server Flow (Secure server) | Grant type: Authorization Code
1) Web Server Flow (Secure server) | Grant type: Authorization Code
Apps hosted on a secure server use the web server authentication flow. A critical aspect of the web server flow is that the server must be able to protect the client secret. This flow uses an OAuth 2.0 authorization code grant type.
Some flows have important security considerations. For example, when using the web server flow, you must store the client secret securely.
Newer OAuth 2.0 apps using the Web Server flow are approved for more devices after the user has been granted access once. The User-Agent flow requires user approval every time.
2) User Agent Flow | Grant type: Implicit Grant
We use this type of flow when there is no server, and that's why there's no refresh token - It doesn't share username and password.
3) Device Authentication Flow | Grant Type: Device Flow
4) Username and Password Flow | Grant Type: Resource Owner
Where client is developer by the same authority as Authorization server for implicit trust. Salesforce Communities don’t support the username-password authentication flow.
5) JWT Bearer Token Flow (Digital Encrypted Signed Certificate - sub part of Web Server flow, User Agent, Device Authentication, UserName & Password)
If you’re using the JWT Bearer Token or SAML Bearer Assertion flows, select Use Digital Signatures and upload a signing certificate.
6) SAML Bearer Assertion Flow
Sub part of Web Server, User Agent, Device Authentication, UserName & Password flow - An app can reuse an existing authorization by supplying a signed SAML 2.0 assertion
7) SAML Assertion Flow
Sub part of Web Server, User Agent, Device Authentication, UserName & Password flow - All types of OAuth 2.0 flows, except for the SAML Assertion flow, require that you define a connected app.
This flow is an alternative for orgs that are using SAML to access Salesforce and want to access the web services API in the same way.
8) Asset Token Flow (Sub flow of Device Authentication for Connected Device)
9) Refresh Token Flow (Sub part of Webserver and User Agent flow)
Identity URLs:
When a client app makes an authorization request that’s successful, the HTTP response contains an identity URL along with the access token. The URL is returned in the id scope parameter.
Federation ID isn’t owned by an interstellar shipping organization with nefarious designs. It’s basically a term that the identity industry uses to refer to a unique user ID.
Mobile-First Identity Salesforce Mobile-First Identity simplifies the login experience for your customers. When we say login experience, we're referring to all aspects of identity verification and authentication: from sign-up, to log in, to handling identity verification, to resetting passwords, to logging out.
Login Discovery doesn’t know how to verify the user until it determines—discovers—how the user is identified. Think of Login Discovery as a two-step process. Login Discovery supports both password and passwordless login.
Deep Linking - When we need to navigate directly to the page of external system without going to home page
RelayState - RelayState parameter must be used, if there is a need to redirect the user to a specific page after the SSO is successful for the best possible user experience
Identity Provider: An identity provider (IdP) is a service that stores and verifies user identity.
Service Provider: The service provider initiates login by sending a SAML request to the identity provider, asking it to authenticate the user.
SAML Assertion:
A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider.
In some cases, you want to authenticate servers without interactively logging in each time the servers exchange information. For these cases, you can use the OAuth 2.0 JSON
In some cases, you want to authenticate servers without interactively logging in each time the servers exchange information. For these cases, you can use the OAuth 2.0 JSON
Difference between SP Initiated Vs IdP Initiated SSO
If SSO is initiated from login page of service provider than its service provider initiated SSO. If SSO is initiated via identity provider login page than its IP initiated. Salesforce can act as both service provider and identity provider, in case where we can access apps like Workday from App launcher of Salesforce - than its identity provider initiated SSO and there will be no redirects.
Delegated Authentication SSO
If we can't use Federated Authentication then we use delegated authentication, for e.g. browser redirect is not possible. In delegated authenticated SSO, we need to pass the responsibility to 3rd party system via custom web service, and the service can return true/false. Its additional work and it is not ideal, because the username and password needs to be passed to the API.
Useful Links
