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!!!

Salesforce OAuth Flow - Implementation guidelines and tips

Whenever an external app request to access salesforce data, authentication needs to be done on salesforce side. Different authentication flows are available as governed by OAuth standards.

Through this blog, i will share commonly used OAuth flows and factors which you need to consider while deciding which one to use.

OAuth 2.0 Web Server Authentication Flow

• This flow is mainly used by applications hosted on web server.
• If external application is trusted one and hosted on secure server and can securely store client_secret, then flow can be used.
• This flow is used mainly to build web application.
• First of all external application will request for access_token and user will be redirected to login page for authentication. After authentication, user will approve salesforce access by external app.
• After successful approval to grant access, authentication code will be returned through callback. External app will utilize this temporary OAuth token( valid for 10 mins) and send POST request to get access_token by sending temporary OAuth code, client_id and client_secret.
• Salesforce will return access_token and refresh_token. Refresh token can be used to regenerate the access token by external app so that user is not required to authenticate every time.
• Instead of sending client credentials as parameters in the body of the access token POST, Salesforce supports the HTTP Basic authentication scheme. This scheme's format requires the client_id and client_secret in the authentication header of the post as follows:         Authorization: Basic64Encode(client_id:secret)
• This flow is not recommended for application (like ETL or middleware's) which will access salesforce using API's and no UI is involved.

OAuth 2.0 User Agent Flow

• This flow is recommended when you build mobile or desktop application and your application can be distributed to anyone. So these kind of application are not considered as safe to store client secret because source code of application will be accessible to everyone and client secret can be exposed easily.
• This flow is used when external system application wants to login into salesforce using salesforce login credentials. Once user logged in, then he/she to approve that external application can fetch salesforce data(scope defined in connected app).
• In this flow, external application will pass only client id and user login page opens and user authenticate themselves to get access token, refresh tokens.
• External application can use use refresh token to get new access token if it get expired and can avoid logging user again in salesforce.
• With the user-agent authentication flow, the client app receives the access token as an HTTP redirection. The client app requests the authorization server to redirect the user-agent to another web server or to an accessible local resource. The server can extract the access token from the response and pass it to the client app. For security, the token response is provided as a hash (#) fragment on the URL. It prevents the token from being passed to the server or to any other servers in referral headers.

OAuth 2.0 JWT Bearer Token Flow

• Ideal for application which access sfdc only through API as there is no UI involved. For example ETL tools or middleware.
• A JSON Web Token (JWT) enables identity and security information to be shared across security domains. 
• JWT is basically a JSON file consisting of a header and claims object, where the header contains the signature algorithm and the claims object contains specific information such as the username and consumer key. At a high level, you will then sign the JSON object with the private key of your certificate and send the JWT to Salesforce to obtain an access token.
• When a client wants to use this flow, posts an access token request that includes a JWT to Salesforce’s OAuth token endpoint. Salesforce authenticates the authorized app through a digital signature that is applied to the JWT. 
• Digital certificates are required in this flow. Upload certificate (X509 ) to connected app which will be used to authenticate JSON web tokens.
• External application send request for access token by passing JWT token in body. SFDC server validate JWT and return access token to external app.
• No refresh token is returned in this flow. So if access token expires then send request to generate access token again.

OAuth 2.0 SAML Bearer Assertion Flow

• A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider.
• The external app or client isn’t required to store client_secret.
• If you use active directory or LDAP as identity provider, then you will use SAML assertion from your SSO flow to obtain an access token to Salesforce.
• This flow used SAML assertion (XML token generated by Identity provide) and applied digital signature to it using certificates.
• In connected app, you upload this certificate (X509 ) containing private key. This key should be used while signing SAML asseration(base 64 encoded).
• The SAML assertion is posted to the OAuth token endpoint, which in turn processes the assertion and issues an access_token based on prior approval of the app(users are pre- authorized in connected app). 
• This flow also return only access token not refresh token

SAML Assertion Flow

• The SAML assertion flow is an alternative for Orgs that are currently using SAML to access Salesforce and want to access the web services API the same way. 
• You can use the SAML assertion flow only inside a single org.  So it means it can be used to connect to single sfdc org
• You don’t have to create a connected app to use this assertion flow. Clients can use this assertion flow to federate with the API using a SAML assertion, the same way they federate with Salesforce for web single sign-on.
• If you have SSO configured specifically for the Salesforce org that your partner application is authenticating to, you can also use the SAML Assertion Flow. 
• Configure SAML for your org. SAML version 2.0 is required. Exchange a SAML assertion for an access token. Use a JSON parser to process the response from salesforce to extract the access_token.
• The benefit of this flow is that you can use a Base-64 encoded, then URL encoded, SAML assertion that is normally used for web single sign-on. This makes it significantly more simple from a development perspective because you don't need to create a connected app but requires you to have SSO enabled for your Salesforce instance.
• No refresh token is issued in this flow.

OAuth 2.0 Username and Password Flow

• Use the username-password authentication flow to authenticate when the consumer already has the user’s credentials.
• Avoid using this flow because you have to send username and password un-encrypted to Salesforce.
• Use this flow only when there is no way to connect by using other available flows.
• Salesforce communities don’t support the OAuth 2.0 username-password authentication flow.
• In this flow, external app or client sends client_id,client_secret, username and password in POST request.
• The security token must be added to the end of the password to log in to Salesforce from an un-trusted network. Concatenate the password and token when passing the request for authentication.
• No refresh token is issued.

OAuth 2.0 Device Authentication Flow

• The OAuth 2.0 device authentication flow is typically used by applications on devices with limited input or display capabilities, such as TVs, appliances, or command-line applications. 
• This flow returns access_token and refresh_token.
• When device requests authorization by specifying client_id, Salesforce verifies the request and returns the following: human-readable user code, verification URL, device code, and minimum polling interval (in seconds).
• User navigate to verification URL and enters user code received.
• User prompted to login and approve access to salesforce data.
• In the meantime, the application running on the device should keep polling Salesforce (polling interval is also returned by Salesforce) and once the user has approved access, the application on the device will get an access token issued.
• After the access token is granted, the device can use it in API requests to access data on the user’s behalf. The device uses a refresh token to get a new access token if the access token becomes invalid.

OAuth 2.0 Asset Token Flow

• Client applications use the OAuth 2.0 asset token flow to request an asset token from Salesforce for connected devices. 
• In this flow, the device obtain an access token (in any of the above ways) and use this token alongside additional information to create an actor token. This token contains valuable information about the asset which is then send to Salesforce where it is exchanged for an asset token. Subsequent requests to protected resources at Salesforce can then be made with the asset token.
• In this flow, an OAuth access token and an actor token are exchanged for an asset token. This flow combines asset token issuance and asset registration for efficient token exchange and automatic linking of devices to Service Cloud Asset data.

OAuth 2.0 Refresh Token Flow

• The OAuth 2.0 refresh token flow renews tokens issued by the web server or user-agent flows.

Revoking Tokens

• Revoke an OAuth token if you don’t want the client app to access Salesforce data or if you don’t trust the client app to discontinue access on its own.
• When users request their data from within an external app (the consumer’s page), they’re authenticated. You can revoke their access tokens, or the refresh token and all related access tokens, using revocation. Developers can revoke the token when configuring a log-out button in their app.
• You can use POST method to revoke token as mentioned below

To revoke OAuth 2.0 tokens, use the revocation endpoint.
https://login.salesforce.com/services/oauth2/revoke 
Construct a POST request that includes the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body. For example:
    POST /revoke HTTP/1.1
    Host: https://login.salesforce.com/services/oauth2/revoke 
    Content-Type: application/x-www-form-urlencoded
    token=currenttoken

• Salesforce also supports GET requests with the query string parameter token and the current token. If an access token is included, Salesforce invalidates it and revokes the token. If a refresh token is included, Salesforce revokes it and any associated access tokens. For example: 

https://login.salesforce.com/services/oauth2/revoke?token=currenttokenID

The authorization server indicates successful processing of the request by returning an HTTP status code 200. For all error conditions, status code 400 is used.

• If an access token is included, Salesforce invalidates it and revokes the token. If a refresh token is included, Salesforce revokes it and any associated access tokens.

You can also navigate to "Connected Apps OAuth Usage" under set up and block external app to create new sessions with connected app.

Hope this will help!!!