I would say this was the toughest certification among all other designer certifications that I have given. I did not have much experience with SSO and OAuth flows before hence I had to study harder and give extra time to this certification. This was also my last certification before I wrap up both my domain architect certification journey.
Why was this exam tough for me?
I did not have much experience with Single Sign-On implementation before and this certification is all about SSO, OAuth flows and other access management features and settings. Even after implementing everything in my developer org, I kept on getting confused between different configurations. This exam is all filled with technical terms and there is a lot to learn. I personally feel, even though the topics mentioned in Study Guide are less than other designer certifications, but this exam covers more content.
Where to start?
For this certification, I followed different strategy than my previous certification. Instead of following the Resource Guide, I followed the Trailmix in beginning. While going through different topics, I made sure I am implementing everything in my Developer org and making my notes. Once I completed the Trailmix, next stop was to check out the Resource Guide which basically has the same resource links but it gives you an idea about the most important topic. I again made sure that I am implementing everything in my developer org.
What implementations must you do?
Below are the scenarios that you must implement:
SSO using Salesforce as Identity Provider
SSO using Salesforce as Service Provide
Social Sign on in communities
OpenId Connect flow with either Facebook Or Google
Just In Time Provisioning with OAuth
One Salesforce Org as Identity Provider and Multiple Salesforce Org as Service Provider
OAuth Webserver Flow and User Agent Flow (Test this with Heroku Axiom App)
- Idp Initiated Flow vs Service Provider Initiated Flow
- Connected App
- OAuth Flow (Web-server flow, User-agent flow, JWT Bearer, SAML Assertion, SAML Assertion Bearer etc)
- My Domain
- Social Sign On
- OpenId Connect
- User Provisioning
- Login Flows
- OAuth with Saml
- Delegated Authentication vs Federated Authentication
- Identity Connect
- Identity Provider
- Auth Provider
Here are the three protocols that Salesforce and other identity vendors follow to implement identity solutions.
- OAuth 2.0
- OpenID Connect
My Domain gives your org unique identity and creates a subdomain for your org in Salesforce. 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
When you want users to move seamlessly between Salesforce orgs and applications without logging in repeatedly, you set up single sign-on (SSO). Security Assertion Markup Language (SAML) is the protocol that makes it happen.
Here are a couple of examples of SAML in action.
- When you’re logged in to Salesforce and then click the App Launcher to get directly to your Gmail inbox, that’s SAML in action.
- When users who are already logged in to another app can access their Salesforce org without logging in again, that’s also SAML in action.
This is how SAML works. A user tries to access a service. The service provider sends out a request to the identity provider basically asking, “Hey, is it okay if this user accesses my service?” The identity provider makes sure that users are who they say they are by checking its database and then returning a response—an assertion—saying, “Yes, this user is authorized, and here’s some information about the user.”
Wait a minute. What’s the difference between an identity provider and a service provider? Basically, the identity provider is the one authenticating the user. The service provider is asking for the authenticated identity.
OAuth 2.0 Protocol
OAuth 2.0 is an open protocol 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 gets contacts from another service also uses OAuth.
OpenID Connect Protocol
Like SAML, OpenID Connect is a protocol based on OAuth 2.0 that sends identity information from one service to another. Unlike SAML, OpenID Connect is built for today’s world of social networks.
The app developer used the OpenID Connect protocol to enable social sign-on.
For instance, when Google verifies a user’s identity on behalf of another service, it’s authenticating the user. In this way, Google is an identity provider.
SAML Flow for SSO
For the curious, the following diagram shows how SAML communication flows during the SSO process. This is what’s happening under the covers.
The SSO process all happens with lightning speed, but a few steps are involved.
- The user tries to access Salesforce.
- Salesforce recognizes the SSO request and generates a SAML request.
- Salesforce redirects the SAML request back to the browser.
- The browser redirects the SAML request to the external identity provider.
- The identity provider verifies the user’s identity and packages the SAML assertion containing the user authentication.
- The identity provider sends the SAML assertion to the browser.
- The browser redirects the assertion to Salesforce.
- Salesforce verifies the assertion.
- The user is now signed in and can access Salesforce.
Key Terms In SSO:
- Identity Provider
- Service Provider
- Federation id
- Needs my domain enabled
- Set up details about identity provider on the service provider side including certificate and issuer details
- Set up service provider details on the identity provider side including entity id, login page URL and federation id.
What Happens When a Customer Self-Registers to Join Your Community?
When a customer self-registers to join a community, Salesforce does a couple of things 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, that you cloned from the External Identity User profile earlier in this module.
- If you haven’t already done so, create a subdomain with the Salesforce domain with My Domain, like https://awesomedomain.mysalesforce.com.
- Decide how Identity Connect fits in with your network infrastructure.
- Install Identity Connect on one or more computers.
- Configure the connection between AD and Identity Connect.
- In Salesforce, create a connected app to connect Identity Connect to Salesforce.
- Determine the best way to map your data between AD and Salesforce.
- Configure a synchronization schedule.
- Run pre-sync reconciliation report. Analyze, link, and clean up user data.
- Run sync then post-sync reports.
- Configure SSO (optional).
Sequence of actions for Just In Time provisioning
As documented in this knowledge article, when provisioning over SAML, Salesforce first attempts to match the Federated ID to the Federation ID field of a User record.
- If a User record with a matching Federation ID is found, the user is authenticated, and all of the editable User fields specified in the assertion are updated with the values assigned. In addition, some of the Contact and Account fields can be updated (e.g., the Account.TickerSymbol field can be updated; Contact.LastName and Contact.FirstName can be updated).
- If no matching User record is found, Salesforce searches all Contacts for a match based on Email. If a matching Contact is found, Salesforce creates the User record and updates the Contact fields specified.
- If no matching Contact record is found, Salesforce searches for a matching Account by Account.Name or Account.AccountNumber.
- If a matching Account record is found, Salesforce creates a new Contact on that Account with the last name and email address specified and then creates a User record with the specified fields (1).
- If no matching Account is found, then Salesforce creates the Account with the specified Name, AccountNumber, and Owner; creates the Contact with the information specified (again, the Contact.Email attribute must be unique across all Contacts on all Accounts); and creates the User record (2).
(1) The Contact.Email attribute value must be unique across all Contact records on all Account records, or provisioning will fail.
(2) The specified Account Owner must have a Role or provisioning will fail.
Why Not Just Use OAuth 2.0 for Authentication and why to use OpenId Connect for it?
OAuth 2.0 allows the user to authorize the client app to access resources such as APIs on the user’s behalf; the access token is a ‘bearer’ token allowing the app to make API calls. What happens if we do use the access token to represent the user’s identity?
Let’s say your account is at ProviderCo, and you are using GoodApp, a mobile app that gives access to some cool functionality on the GoodApp servers. GoodApp uses OAuth 2.0 to obtain an access token from ProviderCo to retrieve your user profile, including attributes such as your name and email address, and (crucially) gives you access to resources based on the fact that it receives that access token.
Now let’s imagine that an attacker wants to access your resources at GoodApp. The attacker can make his own app, BadApp. The app itself is completely innocuous – a game, perhaps. The attacker registers BadApp with ProviderCo so that BadApp also receives access tokens to retrieve user profiles.
Here is the problem with using those access tokens to represent authentication: OAuth 2.0 is designed to give apps access to resources; nothing more. Once BadApp has an access token, properly issued to it for the purpose of obtaining the user profile, it can engineer an interaction with GoodApp where it appears to be both the user and ProviderCo, presenting its access token and gaining access to the user’s resources at GoodApp. GoodApp has no way of knowing that the token was issued to BadApp – all it sees is a token that gives access to a user profile.