How to Pass the Identity and Access Management Designer Exam

At the beginning of April, when we were in the throes of Covid-19, I set the goal to become both a System and an Application Architect by October. I had been configuring and developing on the Salesforce platform for the better part of a decade so I honestly didn’t think that it would be unrealistic for me to sit for and pass the various exams required to become an Application Architect and a System Architect. Out of everyone that I spoke to regarding the various exams, one theme emerged: “watch out for the Identity one”. I can honestly say that I felt pretty comfortable with the majority of the exams that I took. When it was time to click “Submit Exam” I was pretty confident that the next screen was going to read “Pass”. This was not the case for the Identity and Access Management Designer exam. When I clicked “Submit” I honestly closed my eyes, put my head down, and then mustered the courage to look and I was honestly equal parts surprised and relieved when I saw that I had passed.

When it comes to being a Salesforce Admin, Consultant, Developer, Project Manager, etc, it’s very easy to find yourself operating within the same context for months or years, without really having to challenge yourself to explore other areas of the system. The Identity and Access Management Designer Exam definitely tested me and got me out of my comfort zone in the exact way that I needed in order to be pushed to expand my knowledge and familiarity with the platform as a whole.

Unless you’ve worked on numerous Single Sign-On projects or have developed integrations that require OAuth protocols, this exam is going to be a bit daunting. I genuinely loved diving into the concepts of Identity, Single Sign-On all of the options we have at our disposal to grant access to both internal and external users. The following is an overview of the primary concepts that I focused on when studying for the exam and was able to pass on my first attempt. Now I spent roughly 2-3 weeks preparing, so I highly highly recommend carving out at least 30-45 days (if not longer) to fully immerse yourself in the Trails, Videos and anything else you can get your hands on in order to feel a little more confident than I did when clicking the “Submit Exam” button.

TLDR: here are some resources to utilize when preparing for the Identity and Access Management Designer Exam:

• Trailhead
• Ladies Be Architects Video Series with Natalya Murphy
• Gemma Blezard’s Blog Post
• Calvin Noronha’s Blog
• Sunil Kumar’s Blog Post
• SSO Implementation Guide

Identity Providers and Service Providers

This is really one of the main concepts of the exam, you’ll need to have a very firm grasp on what an Identity Provider is, why it exists and how it is incorporated into the Single Sign-On process flows. In conjunction, you’ll also need to know what a Service Provider is and the role that it plays with Single Sign-On flows. Here’s a brief overview of these concepts:

Identity Provider (IdP)

Back in the early days of the internet, everyone had to log into each website or application separately. This means remembering a lot of passwords and presented challenges to businesses. Namely, if your users have to remember 7 sets of credentials, the odds are pretty high that those credentials are going to end up on a sticky note attached to their monitor. For those of you reading this that have your credentials stuck to the bottom of this screen, stop that, talk to your IT Director about an Identity Provider solution such as Okta, Active Directory, Salesforce, or at the very least, LastPass.

In addition to credential security concerns, this also led to phishing scams, provisioning, and deprovisioning issues and overall enterprise password policy enforcement issues. To the rescue, was the concept of centralized Identity Providers. With a centralized Identity Provider, Users would just have one set of credentials to remember and that system could then open the doors to other “Service Providers” that relied upon that one Identity Server to confirm whether Users should have access.

The primary concept here is that the Identity Provider is the master system that houses Users and their credentials. All of the applications that provide a “Service” that the user needs access to, would send a request to the Identity Provider to see if the user should be allowed access and the Identity Provider would say yes or no. For this to work, there need to be a few criteria that need to be met:

• There needs to be a unique identifier across all systems to identify the User (Email Address, Username or a Federation ID)
• There needs to be a secure, trusted connection between the two systems (Identity Provider and Service Provider)

Service Provider (SP)

The Service Provider is an application that provides some sort of a service that a user needs access to. This system will have an account (typically) for the User and possibly even a set of credentials for that User but for one reason or another, the individuals that maintain that system either want to provide an easier means of accessing their service by allowing a Login through another Identity Provider or they don’t have the security or the infrastructure required to effectively operate as their own Identity Provider.

In these scenarios, Users who wish to log into the Service Provider are (typically) required to click “login” and then they’re directed to the Identity Provider’s login page to authenticate and if successful, the Identity Provider will then send a message to the Service Provider stating that the User should be granted access and here’s who they are (by matching the User from the Identity Provider to the User in the Service Provider org via the unique identifier mentioned above).

IdP Initiated Flow vs SP Initiated Flow

‘For the purposes of the Identity and Access Management Designer Exam, you need to be able to identify whether a scenario requires an IdP Initiated Flow or an SP Initiated Flow. This is a pretty simple concept to grasp but an important one. If Salesforce is acting as your IdP and you’re currently logged in but want to gain Access to GSuite via your App Launcher (Connected App with the Start URL defined) then that’s an IdP initiated flow. If you’re wanting to gain access to GSuite from GSuite but you’ve set Salesforce up to be the IdP, if you navigate to GSuite first and then you’re routed to Salesforce to login and redirected to GSuite, then that’s SP initiated flow. Basically, if you’re on the Service Provider website and need to loging to the IdP for authentication before gaining access, that’s always going to be SP initiated flow. Conversely, if you’re currently logged into a System that is is the IdP and it has links to SP’s, that’s always going to be an IdP Initiated Flow.

Single Sign-On

This is really the main functionality that is reliant upon the Identity Provider/Service Provider relationship. If you’ve used the internet in the past two weeks, chances are you’ve leveraged Single Sign-On numerous times. For example, if you use Gearset, you have the ability to login with your Salesforce credentials, your GSuite Credentials, or your LinkedIn Credentials.
This is an example of Single Sign-On (SSO for short). Gearset has an Account for you but it relies on Salesforce, Google, or LinkedIn to confirm your identity and grant you access. When it comes to SSO within Salesforce, there are a few concepts and technologies at play, they’re listed below.

Authentication, Authorization, and Accounting

When it comes to the Identity and Access Management Designer Exam, it’s important to understand what the Triple A’s mean.

Authentication: who are you? who can vouch for you? For those of you that didn’t join the Greek system in college and attempted to enter a frat party, this is a very familiar scenario:
Dude at front door of SAE’s: “Hey what’s up man, who are you?”
Me: “Hey, I’m Cole”
Dude: “Are you a brother?
Me: “Nope”
Dude: “Who do you know here?”
Me: “Shep”
Dude: “Shep! There’s a dude named Cole here who says he knows you, he cool?”
Shep: “Yeah”
Dude: “Alright you can come in”
That, my friends, is Authentication. Myself, the User, would like to enjoy the Services of SAE, the “Service Provider”. The dude doesn’t know me and prompts me to identify myself, I pass along information and the dude then communicates with Shep, the “Identity Provider” to confirm whether I should gain access to the Service. Upon confirmation, I’m allowed to enter. If not, I then have to try and sneak in through an open window.

Authorization: In the above example, just because I’ve been Authenticated doesn’t mean I’m “Authorized” to do anything but enter. For me to partake in the festivities and enjoy the various attractions of the Service Provider, I need to be granted access to various resources.
Me: “Hey man, could I get a cup?”
Dude #2: “looks like you don’t have a wristband”
Me: “Yeah, I’m here with Shep”
Dude #2: “Oh really? I love Shep. A friend of Shep’s is a friend of mine, here you go. Keep in mind, you can only get drinks here, the other rooms are only for brothers”
Me: “Sounds good to me, thank you kind sir”
That is an example of authorization. I’ve already been authenticated as someone who is worthy of gaining entry but I need to be granted specific permission to enjoy certain offerings of the Service Provider. In this case, I was allowed access and could imbibe the libations in the main room but I did not have access to other Services.

Accounting: Accounting is important because organizations need to be able to track what you did while you were granted Access to the systems. In Salesforce, you use the Accounting features every day: Field History Tracking, Setup Audit Trail, Login History etc. With a product like Shield, the Accounting capabilities are significantly expanded.
Dude #3: “Yo, who drew berets and monocles on all of the pledge class pictures?!?! Was it you, new guy?”
Me: “No, I hate monocles and berets, plus I’ve been here the whole time, with Shep”
Shep: “It’s true”
Dude #3: “This is the third time this semester!” [has meltdown]
That is an example of Accounting. Something happened, we need to figure out who did it, so we head to the various tracking mechanisms we have to see who changed what and when.

My Domain

The most important element of the entire Single Sign-On process is My Domain. For anyone that’s migrated from Classic to Lightning, you know that activating My Domain is a very crucial part. For those of you who bought Salesforce fairly recently, you most likely never had to enable My Domain, it was just enabled for you when your account was activated. What is My Domain and why is it important? Well, My Domain makes your instance of Salesforce unique. Without it, you log into the generic “login.salesforce.com” front door and your url is something generic like “na123.salesforce.com”. You’re just taking up space within that namespace but you don’t have a dedicated home, you’re loitering. With My Domain, you have a home with an address that is searchable in the phone book and people know how and where to find you. At a high level, you’re creating a subdomain of the Salesforce.com top-level domain.

The main concepts with My Domain are that it now enables you to have a specific address within the Salesforce ecosystem that is yours and yours alone. Many other orgs could have the same “na123.salesforce.com” url but only you have “awesome-company.salesforce.com”. This enables you to leverage Lightning Components, Social Sign-On and you guessed it…Single Sign-On. From this page, you can determine which authentication providers you want to allow your users to use when accessing your org. It also allows you to prevent users from accessing your org from “login.salesforce.com” if you’re wanting to force them to use your custom front door or another IdP such as Google, Okta, LinkedIn, etc. In this scenario, they would then need to bookmark your “My Domain” url (awesome-company.salesforce.com) to login.

Connected Apps

After My Domain, the second most important concept to wrap your head around is the role that Connected Apps play in the Single Sign-On process flow. If you want to enable Salesforce as an Identity Provider and allow your Users to access Service Providers via SSO, then you need to leverage Connected Apps. Connected Apps allow you to create a “Connection” with an external “App” so that your users can navigate freely between the two by leveraging Salesforce’s authentication and authorization capabilities as an Identity Provider.

Conversely, if a system is wanting to get or manipulate data from your Salesforce instance, Connected Apps provide that framework. The Salesforce mobile app connects to Salesforce via a Connected App, as does DataLoader and Quip.

For this part of the exam, you really need to know all of the different configuration options you have at your disposal when configuring a Connected App. More info from Salesforce on Connected Apps here.

Identity Licenses

If you’re currently an Admin, you’ve probably seen this option before when creating a new User and wondered “huh, I wonder what that does?”.

Well partner, that there is an Identity license that allows you to create Users specifically to provide Identity functionality to external Applications/Service Providers. There are two types of Identity Licenses: Internal Identity and External Identity.
Internal Identity: this license type is primarily used solely for Identity Provider services. If you have a custom application that you’re building and you don’t want to build out an Identity Server, you can leverage Salesforce as the IdP and create Users with the Identity License to allow your application to determine who gets access. The benefits here are that admins can control access to those external applications for the Identity Users like they would any other Salesforce user.
External Identity: this license has similar Identity Provider functionality to the Internal Identity license but in addition to Identity Provider functionality, it also provides access to certain standard objects as well as up to 10 custom objects. These have to be purchased from Salesforce in blocks. The following is an overview of the Standard Objects that you can enable the External Identity Profile to access compared to the options available OOTB with the default External Identity Profile

SAML

SAML is the underlying, standards-based, means of allowing applications to Authenticate users across platforms. There are some (keyword some) Authorization capabilities of SAML but for the purposes of this exam, you should consider SAML and Authentication synonymous. If you’re using Salesforce as an IdP in an SSO scenario, then within your Connected App, you need to check the box for “Enable SAML”. If you’re using Salesforce as a Service Provider, then you need to navigate to “Single Sign-On Settings” and enable SAML there.

One of the main concepts of SAML is the SAML Assertion. When the Authentication request is approved, the Identity Provider returns a SAML Assertion, which is basically a confirmation that the User is who they say they are and should be granted access.

Certificates

Certificates are a way in which two systems can establish trust with one another. When creating your Connected App, you need to upload a Certificate for that external application. That certificate is used to allow Salesforce to confirm that the external system is legitimate and can be trusted. There are two primary types of Certificates to be concered with:

• CA Signed Certificate – This is a certificate that is provided by a Certification Authority (CA), which is basically an independent group that issues digital certificates. From Wikipedia: “A digital certificate certifies the ownership of a public key by the named subject of the certificate”
• Self-Signed Certificate – Since Salesforce is kind of a big deal, they can create Self-Signed Certificates that verify the ownership of a public key for an application. If Salesforce is acting as an Identity Provider, you can utilize the Salesforce Self-Signed Certificate. If Salesforce is the Service Provider, then it typically requires a CA Signed Certificate (unless the IdP is Salesforce in a multi-org SSO configuration).

Just In Time Provisioning (JIT)

Think of JIT Provisioning like an Upsert. I’m sure if you’re reading this, you’ve ran Data Loader in an Upsert capacity in the past. Upsert basically says, if a record currently exists, reference that. If a record doesn’t exist, then create a new one. In the context of SSO and SAML, JIT says “try and log this user in by checking the unique identifier, if they exist then try and authenticate, if they don’t exist, then create a new one”. The primary context that you need to be familiar with for the exam is how and when JIT can be leveraged and with what technologies.

Servers

When it comes to OAuth, you need to have an understanding of the different servers at play:

• Authorization Server
  • This is the system that grants or denies access through the issue or revocation of Access Tokens (more on this below)
  • Clients request permission from the Authorization Server and if the User successfully logs in and Accepts the conditions (via OAuth flow) OR if the systems are using pre-authorized signed certificates, then the Authorization Server provides an Access Token
• Resource Server
  • This is the Server that has the resources that Users are trying to access
  • Access is determined by the presentation of an Access token if an Access token is presented to the Resource Server, it checks to make sure the token is valid and if so, grants access

Tokens

In the world of OAuth, tokens make the world go-round. There are 3 primary Token types you need to be concerned with:

• Access Tokens
  • Access Tokens are basically the key to the door. When Authorization is requested and granted, the Client (browser/application that is requesting access) is provided with an Asset token.
  • Asset Tokens live a very short life, by design. If someone has an Access Token, they have access to the system
  • You can set the expiration duration for an Access token from the Connected App
• Refresh Tokens
  • If you’re a gamer, think of Refresh Tokens as health packs. If you’re running low on health, you’re probably not going to make it unless you find a health pack. If you find a health pack, your health is recharged and you can keep on playing
  • Refresh Tokens are the same, if the Client is granted a Refresh Token, it can then present that Refresh Token back to the Authorization Server which will result in a new Access Token being provided to extend the length of the Session
  • Refresh Tokens can be revoked to prevent that App from having Access
• Asset Tokens
  • This is primarily applicable in the “Asset Token Flow” presented below and mainly used in “Internet of Things” configurations

OAuth

The same way that SAML is associated with Authentication, OAuth is synonymous with Authorization. When you see OAuth, think OAuth(orization). In the context of the example above, OAuth is used to tell a requesting application the types of permissions that the requesting User should have access to. You’ve definitely seen OAuth in action hundreds of times already, you just may not have known it. The following is an example of the Salesforce mobile application requesting access (remember, the mobile application gains access to your Salesforce instance via Connected App).

For the purposes of the Identity and Access Management Designer Exam, the main concepts to understand are the different OAuth Flows. There are a number of them (you can review the full list here) but these are the ones that I focused on (high level notes here, definitely dive into the docs):

• Web Server Flow
  • Gold Standard, most secure
  • Utilizes Tokens instead of passwords between the application and the Client
  • User is directed to a login screen and then prompted to accept the “scopes”
  • Does not pass Client Secret
  • Client pings Authorization Server for Access → Authorization Server provides Authorization Code → Client sends a request back to Authorization Server with the Authorization Code → Authorization Server exchanges the Authorization Code for an Access Token → Client then submits request to Resource Server with Access Token → Resource Server provides access to requested assets/resources/data etc
  • Refresh Token is provided
• User Agent Flow
  • This is typically used in stateless applications or apps that are primarily running on Javascript and don’t make calls from a backend server
  • Users are directed to a login page to authenticate and then presented with the OAuth screen to accept the “scopes”
  • The sending and receiving of the requests are all done in the browser, so there are some security concerns with this approach
  • For security SFDC uses the same-origin policy, meaning that if a request is made from “test.com” and the Access Token is provided, that Access token cannot be used for that User from “test123.com”. The Access Token can only be used by the originating domain that requested the access
  • With this Flow, there is no Authorization Code, the request is validated and the Authorization Server sends the Access Code back to the Client
    • The Access Code is added as a hash to the redirect URL for additional security
    • This is a security concern, developers need to try and remove that hash from the string upon receipt
• JWT Bearer Flow
  • This is a cool twist on the OAuth flows. Instead of requiring the user to login and accept the scopes, the system uses a signed digital certificate to present to the Authorization Server, the Authorization Server validates the legitimacy of the signed certificate and then grants the user access
  • User never sees the authentication happen, it is processed behind the scenes
  • JWT (pronounced “jot”) stands for Javascript Web Token
    • Is in JSON format
  • Requires prior approval of the Client by the Application Server
  • Certificate type is X509
• SAML Bearer Assertion Flow
  • This is used in scenarios where the user has authenticated via SSO, utilizing SAML
  • It uses the SAML Assertion to pass along the XML Security Token for authorization
  • Also leverages signed digital certificates to validate the request and establish trust
  • Refresh Tokens are not issued
• SAML Assertion Flow
  • Essentially, this is SSO for API’s – no human interaction required – it’s all automated systems communicating with each other
  • Can be used without a Connected App
  • Communities do not support this flow
  • JSON based
• Asset Token Flow
  • High level, just know that this flow is used in IoT scenario
  • A generator needs to communicate with Salesforce Service Cloud to let it know that it needs servicing
  • An application in the middle allows for the authorization of a connection between Service Cloud and that generator
  • Asset Tokens are issued in this flow
• Device Flow
  • If you’ve ever needed to broadcast to a TV and been prompted to enter a 4 digit code on your phone/laptop or if you’ve tried to set up an HBO Now account and been prompted to head to “blahblah.hbo.com/activate”, you’ve seen the Device Flow in action
  • This is reserved for systems that have a limited user interface and it just provides a code, a URL and some help text then you have to go to another device to follow the directions to authorize access
  • Just know that the limited input device (tv, roku, etc) is continuously polling the Authorization Server, listening to see if you were able to enter the verification code into the other device interface
• User/Password Flow
  • Only to be used if absolutely necessary, this requires sending credentials over the wire between systems
  • Only used if the Client/Application was developed and maintained by the same entity/organization that built/maintains/utilizes the Authorization and the Resource Servers
  • Use only as a measure of last resort

OAuth Errors

Familiarize yourself with OAuth Error scenarios

Scopes

Scopes are what control the level of access you have after you’ve successfully navigated an OAuth flow. When creating your Connected Apps, you indicate the scopes that are allowed, aka the permissions that the requesting users will have. You should familiarize yourself with all of them but the main ones to grasp (according to me) are the following:

• API – Allows access to the current, logged-in user’s account using APIs, such as REST API and Bulk API. This scope also includes chatter_api, which allows access to Connect REST API resources
• full – Allows access to all data accessible by the logged-in user, and encompasses all other scopes. Does not include refresh_token
• web – Allows use of the access_token on the web. This scope also includes visualforce, allowing access to customer-created Visualforce pages.
• 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.

Social Sign-On

You’ve seen this before. If you navigate to a website and they allow you to “Sign up with Facebook” or “Login with Twitter”, you’ve witnessed Social Sign-On in action. With regards to Salesforce,. Social Sign-On is used for Communities primarily but you can also leverage some of them OOTB (out of the box) as an IdP for your internal users as well.

The main concepts to grasp are that you can enable the “Allow Users to Self-Register” option within Communities which will then create a User for the individual if they login via Facebook but do not have a matching User in the system.

A key concept here is that when allowing Users to self-register, you need to indicate the Account that the resulting Contact should be associated with. If you’re unfamiliar with Communities, Community Users start as Contacts and are then linked to the corresponding Community User.

If you’ve enabled Person Accounts for your org, leaving the Account field blank within the Community Administration page will result in the self-registered Users being created as Person Accounts (typically reserved for B2C scenarios).

Login Flows

To be honest, I wasn’t that familiar with Login Flows before I started studying for this exam and they’re pretty sweet. Login Flows are basically Flows that you create that present the User with a series of screens/prompts to gather additional information or provide guidance on how to use the system. Essentially, when the user logs in successfully, the Flow launches and they are guided through one or more screens (based on the Flow you created) and if they’re prompted to fill out a form and do not complete all of the steps, they’re not allowed access to the system.

These can be used with custom 2FA that rely upon hardware tokens. If you have a USB dongle that generates a random number every 60 seconds and you need to use that number to verify access, a Login Flow can be leveraged with an Apex Class that confirms the validity of your login request.

Session Security

Brush up on the various options you have when enforcing Sessions for users, examples below:

• High Assurance Sessions
  • Assigned via Permission Sets
  • Requires 2FA when trying to access sensitive resources including but not limited to
    • Reports and Dashboards
    • Manage Users
    • Manage Connected Apps
    • etc
• Login IP Ranges
• Login Time Windows
• Session Timeout Settings

Federated vs Delegated Authentication

For the exam, just know that Federated Authentication is where you’re relying upon Salesforce or another application via SAML, to provide authentication services for the purposes of accessing a protected resource.

When it comes to Delegated Authentication, just know that it’s not ideal and can be a security risk while also providing some additional benefits if the company utilizing this approach has a strong IT security model. Key concepts

• SFDC doesn’t validate username/passwords at all, you’re literally just entering data into a form and then SFDC sends the information (username, password, source IP, time) to a web application that you’ve built and listens for the response
• The response from the system is literally just True or False
  • If True, the User is granted access. If False, they are denied
• This can be helpful because the authentication is behind the company’s firewall
• Must be enabled by creating a Case with Salesforce Support
• Used with LDAP systems, typically
• Does allow for this authentication type to be assigned to specific Users whereas federated showcases the “Sign On Using SSO” to everyone
• Salesforce doesn’t store, log, or view the password. It’s disposed of immediately after the process completes.

Identity Connect

This is a product that Salesforce sells that allows you to use Microsoft’s Active Directory as an IdP. Some of the main concepts are:

• It’s a one-way sync from Active Directory to Salesforce
• It allows for mapping a User in Salesforce to Groups, assigns Profiles, assigns Permission Sets and sets user details based on equivalent metadata in Active Directory
• From Salesforce: “Changes in AD are reflected in Salesforce in near real-time. For example, when a user is created in AD, the Salesforce user account is created as part of the provisioning process. When deprovisioned, the user’s Salesforce session is revoked immediately.”
• Implementation Guide

2 Factor Authentication

When it comes to 2FA within Salesforce, you have a few options:

• Device Authentication using Salesforce Authenticator mobile app
  • This allows you to enter a code from your device when prompted by SFDC when attempting to log in
  • If you have location settings enabled on your phone, you can tell SFDC to remember that location so you won’t be prompted to verify again if your device is in the same location over and over
    • You can remove these trusted locations if needed
  • Within the confirmation screen, it shows you your username, the service you’re trying to access (Salesforce), location, the device you’re using, the time
• Login Flows
  • As previously mentioned, you can use Login Flows to prompt for a code from a hardware token generator, an SMS or a phone prompt or a custom email flow
• Temporary Code
  • An admin can generate a Temporary Code from your user record that can be used when logging in
  • Code can be used multiple times before it expires
  • Admin controls how long the code will last

 For more resources to help you tackle your certification goals, check out our Ultimate Guide to Salesforce Certification Resources. 

About Roycon
We’re an Austin-based Salesforce Consulting Partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Whether you are just getting started with Salesforce or looking to realize its full potential, Roycon specializes in Salesforce Implementations, Salesforce Ongoing Support, and Salesforce Integrations, and Development. We’re the certified partner to guide the way to increase Salesforce Adoption, make strategic decisions, and build your Salesforce Roadmap for success.