IDENTITY AND ACCESS MANAGEMENT DESIGNER : Exam Preparation Guide and Tips

I am really excited to share that I have cleared "IDENTITY AND ACCESS MANAGEMENT DESIGNER" exam yesterday and going to share my inputs for people who are preparing for it.

I have successfully completed "Application Architect" credentials and if you would like to prepare for that then refer below links:

Data Architecture and Management Designer : Exam preparation guide and tips
Sharing and Visibility Designer : Exam preparation guide and tips

As usual I started with Resource Guide for Identity and Access Management designer exam. This time while preparing I gave more preference to Trailmix-Architect Journey: Identity and Access Management  specially to hand on training section.

This was really a tough exam for me as everything was theoretical as SSO is already configured in all companies. Also we won't get chance to work on identifying the identity provider and service provider configurations as my job roles mainly include to provide solutions to streamline business process. But anyhow is was mandatory exam in order to get "System Architect" credential, I started preparing for it just after clearing my "Salesforce Certified Integration Architecture Designer".

If you are preparing for Salesforce Certified Integration Architecture Designer exam then refer below link:
SALESFORCE INTEGRATION ARCHITECTURE DESIGNER : Things to consider before appearing for this exam

Below are the points which you should cover before appearing for exam:

My Domain

• My domain is required to configure SSO.
• Add a subdomain to your Salesforce org with the My Domain Salesforce Identity feature. If you specify login.salesforce.com as entity id in SSO, then identity provider will redirect to genric salesforce domain and salesforce again will open login page as it will not be able to understand on which subdomain user needs to be redirected. If you enable my domain and specify my domain in entity id, then redirection from identity provider will be easy.
• My domain is required for Single sign-on (SSO) with external identity providers, Social sign-on with authentication providers, such as Google and Facebook and lightning components in Lightning component tabs, Lightning pages, the Lightning App Builder, or standalone apps.
• You can rename your My Domain subdomain in production orgs. But you can't rename a sandbox, developer, or trial org subdomain.
• Authentication Configuration under My domain controls which all authentication services will be presented to user.
• If you want user to get authenticated from external identity provider then deselect login form from authentication services. 
• If login form is enabled as authentication services, then user may complain saying that they get redirected to salesforce login page instead of redirecting to identity provider login screen.

Salesforce 2 factor authentication 

• You can use out of box two factor authentication provided by salesforce. Create a permission set and assign “enable 2 factor authentication” permission in it. Now assign this permission set to user for which you want to enable 2 factor authentication. User needs to download Salesforce authenticator app and link their salesforce account. Now whenever user logged in, will get approve or reject option on salesforce authenticator. Salesforce authenticator will display device and location for log in and you can specify to remember that location so that next time you will not get notification when you log in. 

Custom Login Flow

• Login flows can be used to create custom 2 factor authentication.
• Refer Login Flows - Way to Customize User Authentication Flow for different use cases.

Salesforce OAuth Flows

• Refer Salesforce OAuth Flow - Implementation guidelines and tips  for complete understanding and their use cases.
• Given a scenario, you need to identify which flow to use.

Oauth Scope Parameter Values

• The scope parameter fine-tunes the permissions associated with the tokens that you’re requesting. Scope is a subset of values that you specified when defining the connected app.
• Different scope values are:
• api : Allows access to the current, logged-in user’s account using APIs, such as REST API and Bulk API. This value also includes chatter_api, which allows access to Chatter REST API resources.
• chatter_api : Allows access to Chatter REST API resources only.
• custom_permissions : Allows access to the custom permissions in an organization associated with the connected app, and shows whether the current user has each permission enabled.
• full : Allows access to all data accessible by the logged-in user, and encompasses all other scopes. full does not return a refresh token. You must explicitly request the refresh_token scope to get a refresh token.
• id : Allows access to the identity URL service. You can request profile, email, address, or phone, individually to get the same result as using id; they are all synonymous.
• openid : Allows access to the current, logged in user’s unique identifier for OpenID Connect apps. Use the openid scope in the OAuth 2.0 user-agent flow and the OAuth 2.0 web server authentication flow to receive a signed ID token conforming to the OpenID Connect specifications in addition to the access token.
• refresh_token : Allows a refresh token to be returned when you are eligible to receive one. Then the app can interact with the user’s data while the user is offline, and is synonymous with requesting offline_access.
• visualforce : Allows access to customer-created Visualforce pages. Doesn’t allow access to standard Salesforce UIs.
• web :   Allows the ability to use the access_token on the web, and includes visualforce, allowing access to customer-created Visualforce pages.

Identity License and External Identity License

• Identity license connects Salesforce users with external applications and services, while giving administrators control over authentication and authorization for these users.
• External Identity license is used for users outside of your organization’s user base (such as non-employees). Store and manage these users, choose how they authenticate (username/password, or Single Sign-On social sign-on through Facebook, Google+, LinkedIn, and others), and allow self-registration.

IDP-initiated or SP-initiated

• When salesforce act as service provider and identity provider is external app. If now user login by using my domain of salesforce, then it is called as SP initiated single sign on flow. In this case, salesforce will first redirect user to identity provider to get authorized and based on response from identity provider, will allow user to go to salesforce.
• If user login in identity provider and then redirect to service provide using some link, then it is called as IP initiated Single sign on flow.
• If you are using third party app as IP and salesforce and some external app are using third party as IDP. So if user click a link for salesforce resource on external app, then you need to configure SP initiated SSO that passes the SAML token to authentication provider when salesforce resource is requested.
• With an IdP-initiated login process, you typically set up a link on the company intranet that users click to get access to Salesforce. 

Identity Connect

• Identity Connect is a Salesforce Identity product that helps Salesforce admins apply all the data collected in AD to automate Salesforce user management. It syncs changes in AD within seconds.
• Identity Connect is on-premises software that sits behind your firewall and pushes data to Salesforce. Identity Connect’s server runs within the corporate network and communicates with the AD server over LDAP(S). It communicates with in-the-cloud Salesforce over HTTPS. Work with your networking engineer to ensure that these paths are open so that Identity Connect can connect to both AD and Salesforce.

• When Identity Connect detects differences between AD and Salesforce, it updates Salesforce with the information in AD. Data transfer is in one direction and AD is the source of truth. Identity Connect never changes information that's stored in AD.
• You can set up Identity Connect to manage multiple production orgs. And you can set up Identity Connect to manage multiple nonproduction orgs. But you can’t mix production and sandbox orgs in one Identity Connect environment.
• Different ways through which identity connect map AD Group user to Salesforce user are:
• Profile mapping with AD groups
• Permission set mapping with AD groups
• User role mapping with AD groups
• Salesforce groups to AD groups 

Self Registration - Communities

• Enable self-registration to allow unlicensed guest users to join your community. When your users self-register, you can choose to save them as contacts under a business account or create a person account for each self-registering user.
• If your business deals mostly with individuals, instead of creating them as contacts under a single business account, you can assign each self-registering user to a person account.
• If you want to create person account from self register page, then don’t specify account Id while creating account. You can also manually create person accounts and assign them to community users with Customer Community and Customer Community Plus licenses.

Canvas App

• Canvas enables you to easily integrate a third-party application in Salesforce. Canvas is a set of tools and JavaScript APIs that you can use to expose an application as a canvas app. This means you can take your new or existing applications and make them available to your users as part of their salesforce experience.
• The third-party app that you want to expose as a canvas app can be written in any language. The only requirement is that the app has a secure URL (HTTPS).
• Canvas app appearance in salesforce depends on the values you select in the locations field when creating the connected app in salesforce. 
• Canvas app can appear in chatter feed, Chatter tab, Console, navigation menu in salesforce app, VF page, Page layouts and mobile cards, Open CTI (in the call control tool), Chatter publisher and action bar.
• Force.com Canvas can use web Server OAuth Authentication Flow and User-Agent OAuth Authentication Flow.

Single Sign On Settings

• Configure single sign-on in order to authenticate users in salesforce.com from external environments
• 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. 
• Just-in-Time provisioning works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion attribute statement. You can both create and modify users, contacts, and accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization must have SAML-based single sign-on enabled.
• To enable Just-in-Time provisioning, you must explicitly enable the checkbox in Single Sign-On Settings.

• Entity Id controls the redirection of user once it gets authorized by identity provider.
• If user is getting redirected always to home page after getting authenticated successfully, then it means identity provider is not able to preserve the relay state which specify where to redirect user after authentication.

Connected App

• A connected app integrates an application with Salesforce using APIs. Connected apps use standard SAML and OAuth protocols to authenticate, provide single sign-on, and provide tokens for use with Salesforce APIs. In addition to standard OAuth capabilities, connected apps allow Salesforce admins to set various security policies and have explicit control over who can use the corresponding apps.
• If you want your user to access salesforce using mobile devices and IP restriction is applied on user profiles, then if you relaxed IP restrictions for your OAuth-enabled connected app then user can access salesforce using mobile devices.
• IP relaxation does not apply to SAML-enabled connected apps unless they are also OAuth-enabled for single sign-on.
• Refresh Token Policy can also be set in connected app. If users are complaining that they need to login after some time on their mobile device, then check refresh token policy on connected app.
• Create connected app for external application to configure SSO for external application from salesforce. You can add profile and permission set to connected app to pre-authorize the user. Connected app is mainly used for inbound request to salesforce.

Federated Authentication

• Federated Authentication using SAML Federated authentication uses SAML, an industry standard for secure integrations. Investing in SAML with Salesforce.com can be leveraged with other products or services. If you use SAML, you don't have to expose an internal server to the Internet: the secure integration is done using the browser. In addition, Salesforce.com never handles any passwords used by your organization.
• When SAML is configured, the user (via their browser) hits either a URL at the enterprise Identity Provider (IdP) or, if My Domain is configured, any My Domain URL at Salesforce - e.g. https://mycompany.my.salesforce.com/SOMERECORDID. The SAML protocol redirects them for authentication in the enterprise, and sends them to Salesforce with a signed XML message representing that authentication.
• Signed XML request message contains federation Id to uniquely identify the user in salesforce.
• Salesforce user record Id, federation Id and username can be used to represent the identity of the user when Salesforce is acting as a Service Provider in a SAML configuration.
• User will face issues with SSO if federation Id is not specified in salesforce correctly which is being returned by identity provider.

Delegated Authentication

• Another option for authenticating users on Mobile and Desktop devices is Delegated Authentication. If enabled for an organization and user's profile, when a user attempts to authenticate directly to Salesforce, the credential is sent back to a customer configured endpoint over a HTTPS secured web-service.
• You need to request to salesforce in order to enable this feature.
• Salesforce uses the following process for authenticating users using delegated authentication:
• When a user tries to log in, Salesforce validates the username and checks the user’s profile settings.
• If the user’s profile has the Is Single Sign-On Enabled user permission, then Salesforce does not validate the username and password. Instead, a Web services call is made to the user’s organization, asking it to validate the username and password. Note Salesforce doesn't store, log, or view the password in any way. It is disposed of immediately once the process is complete.
• The Web services call passes the username, password, and IP address of the user to the customer's Web service. Your implementation of the Web service validates the passed information and returns either true or false.
• If the response is true, then the login process continues, a new session is generated, and the user proceeds to the application. If false is returned, then the user is informed that his or her username and password combination is invalid.
• Using this process, customers can easily use their existing authentication systems to validate credentials. This approach works will all mobile and desktop clients. Once a delegated authentication service is built and enabled for a user, there is no additional configuration required. Users will login using the regular Salesforce login screens, but their credential will simply be validated remotely.
• Salesforce sends the user request over SAML, but the request is sent back using delegated authentication. The RelayState parameter is transformed into the startURL parameter to redirect the user to the correct page. Using this technique, mobile and desktop clients that use SAML with Salesforce can also take advantage of SSO over delegated authentication.
• For security reasons, make your web service available by TLS. Webservice can be REST or SOAP.
• Delegated authentication offers the following benefits.
• 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.

Federated Authentication vs Delegated Authentication

• Delegated authentication is inherently less secure than federated authentication. Even if encrypted, delegated authentication still sends the username and password (possibly even your network password) over the internet to Force.com. Some companies have policies that preclude a third party for handling their network passwords. 
• Delegated authentication requires much more work for the company implementing it. The Web services endpoint configured for the org must be developed, hosted, exposed on the Internet, and integrated with the company's identity store.
• Federated authentication happens through web browser and can not be used for mobile and desktop applications. Use federated authentication for mobile and desktop app.

Looking forward for everyone's comments and suggestion and best of luck for exam...

Hope this will help!!!