Search
Create
Log in
Sign up
Log in
Sign up
Salesforce Certified Identity and Access Management
STUDY
Flashcards
Learn
Write
Spell
Test
PLAY
Match
Gravity
Terms in this set (84)
Types of Authentication Flow
- Web Server
- User Agent
- JWT Bearer Token
- Device Authentication Flow
- Asset Token Flow
- SAML Bearer Assertion Flow
- SAML Assertion Flow
- Username and Password
Web Server Flows
- are for apps hosted on a secure server
- must be used when the server must protect the secret
- uses the "Authorisation Code" grant type, which is optimised for confidential clients and may request both access and refresh tokens
User Agent Flows
- users can authorise desktop or mobile apps to access data using an external or embedded browser
- uses a scripting language, such as Javascript
- uses the "Implicit" grant type, which gets only access tokens and is optimised for public clients
JWT Bearer Token Flows
- selected for server-server API integration
- uses a certificate to sign the JWT request
- doesn't require any specific user interaction
- JWT = the format of the request
Device Authentication Flows
- Can be used for command-line applications
- Can be used for applications with limited input and display capabilities, such as appliances, TVs and IoT
- Users connect these to Salesforce using a browser on desktop or smartphone
(THINK Philips Hue, Sonos, app-controlled washing machines, Amazon Echo Dot)
What are the benefits of combining the issuing and registration of asset tokens within an Asset Token Flow?
- Efficient token exchange
- Enables the automatic linking of devices to Salesforce Service Cloud asset data
Asset Token Flows
are used to request an asset token from Salesforce for connected devices
What happens in an asset token flow?
An OAuth access token and an actor token are exchanged for an asset token
What is the difference between a SAML Bearer & Assertion Flow and a SAML Assertion Flow?
While both flows make use of SAML assertions that contain signed certificates, SAML Assertion Flows are used when organisations ALREADY use SAML to access Salesforce and they want to use the Web Services API in the same way.
SAML Bearer and Assertion Flow
- Enables applications to reuse an existing authorisation by supplying a signed SAML assertion
- The app is authorised by assigning a digital signature to the SAML assertion
SAML Assertion Flow
- An alternative flow for orgs who are already accessing Salesforce via SAML
- used when the customer wants to access the web services API in the same way, i.e. using signed assertions
Access Tokens
- Are a type of OAuth token, known as the Session ID
- Are used to make authenticated requests FOR the user
- Have a longer lifetime than authorisation codes
- Must be protected from interception (via Transport Layer Security: TLS)
Authorisation Codes
- Are a type of OAuth token that authorise access for a very short amount of time
- Are generated by Salesforce and passed to the client app via the browser
- Are passed from the client App to the Authorisation Server in exchange for an access / refresh token
Refresh Tokens
- Can have an indefinite lifetime
- Can be stored within a client app
- Can be used repeatedly to gain access, like a password
- Can expire or be revoked, so the client app has to be able to handle failures
ID Tokens
- Are encoded as a JSON web token
- Are signed data structures
- Contain user ID, time issued and client ID
SAML is
Security Assertion Markup Language
OAuth is
An open authorisation protocol that provides a framework for connecting applications to user accounts
The benefits of OAuth are
- it is simple for developers
- it improves security, because it doesn't expose users' login credentials
- it has an improved user experience, as password resets do not disrupt use of applications
Why would Salesforce combine OAuth and SAML for single sign-on?
- OAuth means users can connect to apps
- SAML authenticates users
- Apps now use web browsers to authenticate instead of code
- Authentication and Authorisation are separated, so SAML can be run instead of asking for a username and password
What happens with Integrated Windows Authentication (IWA)?
- User logs into a Windows laptop
- User opens Salesforce in a browser
- Salesforce knows they are already authenticated, so it logs the user in automatically
What are the benefits of Active Directory Single Sign-On?
- It saves time provisioning and deactivating users
- Reduces helpdesk queries
- Protects from data leakage
- Reduces the number of passwords that users have to remember
What does Identity Connect do?
- Connects ID providers to Salesforce
- Automatically creates, edits and updates Salesforce users (including deactivating them)
- Automatically assigns / un-assigns users to roles, profiles, permission sets, queues and public groups
OpenID Connect is
- An Identity protocol using OAuth 2.0
- a standard for sharing user information via another server
- A way of giving users the ability to login to Salesforce without a username and password, via a variety of providers e.g. Facebook, Google, Twitter etc
The benefits of OpenID Connect are
For Users:
- fewer passwords to remember
- quicker login
- reduced effort in registering to use the service
For Businesses:
- it automates or simplifies user creation
- it provides a reliable user data source
- it reduces helpdesk interactions
To set up OpenID Connect:
- Register as an OAuth client with the Identity Provider (IdP) e.g. Google
- Configure the Auth Provider in Salesforce with the key & secret provided by the IdP
- Define the logic for user management e.g. new user vs returning user
- Use OAuth provider in My Domain / Community
- Implement a Registration Handler (Apex Class)
How does a Registration Handler manage identities between the two systems?
- It uses information about the user to identify new and returning to users, implementing different rules for each
- It processes data from the Identity Provider, mapping it to the appropriate fields and objects in Salesforce
Username and Password Flows
- should only be used for testing
- pass hard-coded username and password details back and forth
- are ineligible to receive a refresh token
What are the steps involved in setting up the OAuth 2.0 SAML bearer assertion flow?
1) The developer creates a connected app and registers an X509 Certificate. This certificate corresponds to the private key of the app.
2) When the connected app is saved, a consumer key (OAuth client_id) is generated and assigned to the app.
3) The developer writes an app that generates a SAML assertion and signs it with the private key.
4) The assertion is posted to the token endpoint
5) The token endpoint validates the signature using the certificate registered by the developer.
6) The token endpoint validates the audience, issuer, subject, and validity of the assertion.
7) Assuming that the assertion is valid and that the user or admin authorized the app previously, Salesforce issues an access token.
What are the steps involved in establishing the OAuth 2.0 JWT bearer token flow?
1) The developer creates a connected app or uses an existing one and can optionally register an X509 Certificate.
2) When the connected app is saved, the Consumer Key (OAuth client_id) and Consumer Secret are generated and assigned to the app.
3) The developer writes an app that generates a JWT and signs it with the certificate.
4) The JWT is posted to the token endpoint https://login.salesforce.com/services/oauth2/token or, if implementing for a community, https://acme.force.com/customers/services/oauth2/token (where acme.force.com/customers is your community URL).
5) The token endpoint validates the signature using the certificate registered by the developer.
6) The token endpoint validates the audience (aud), issuer (iss), validity (exp), and subject (sub) of the JWT.
7) Assuming that the JWT is valid and that the user or admin authorized the app previously, Salesforce issues an access_token.
What are the steps in using the OAuth 2.0 refresh token flow?
1) The consumer uses the existing refresh token to request a new access token.
2) After the request is verified, Salesforce sends a response to the client.
What are the steps in using the OAuth 2.0 Web Server flow?
1) The web server redirects the user to Salesforce to authenticate and authorize the server to access the data on the user's behalf.
2) After the user approves access, the web server receives a callback with an authorization code.
3) After obtaining the authorization code, the web server passes back the authorization code to get a token response.
4) After validating the authorization code, Salesforce passes back a token response. If there's no error, the token response includes an access code and additional information.
5) After the token is granted, the web server accesses the user's data.
What are the steps for using the OAuth 2.0 Username and Password flow?
1) The consumer uses the user's username and password to request an access token (session ID.)
2) After the request is verified, Salesforce sends a response to the client.
3) After a consumer has an access token, it can use the access token to access Salesforce data on the user's behalf.
What are the steps in using the OAuth 2.0 Device Authentication flow?
1) The device requests authorization from Salesforce.
2) Salesforce verifies the request and returns the following: human-readable user code, verification URL, device code, and minimum polling interval (in seconds).
3) The device displays the user code and instructs the user to enter it at the specified verification URL.
4) On a separate device that has more developed input capabilities, such as a desktop computer or smartphone, the user opens a browser.
5) The user navigates to the verification URL and is prompted to enter the user code. If the code is valid, the user is prompted to log in if not already logged in.
6) After successful login, the user is prompted to allow the device to access Salesforce data.
7) After displaying the user code and verification URL, the device starts polling the token endpoint for authorization.
Polling frequency can't exceed the minimum polling interval. The device continues polling until the user has allowed (or denied) access, or the user code has expired.
8) If allowed, the authorization server returns to the device an access token, a refresh token if requested, and other information.
9) After the access token is granted, the device can use it in API requests to access data on the user's behalf and use a refresh token to get a new access token if it becomes invalid.
What are the steps for using OAuth 2.0 JWT Asset Token flows?
1) Create a new connected app or use an existing one that has asset tokens enabled and required settings configured.
2) Get an access token so that you can request an asset token.
3) Create your asset token JWT.
4) Create your actor token payload JWT.
5) Understand how Salesforce attempts to register a new or existing Asset using information from the actor token.
6) Create your actor token JWT.
7) Post your asset token request to the token endpoint.
8) If the asset token JWT is valid, Salesforce issues your asset token in an access token response.
What are the steps for using the SAML Assertion flow?
1) Configure SAML for your org. SAML version 2.0 is required.
2) Exchange a SAML assertion for an access token.
3) Salesforce sends the response.
4) Use a JSON parser to process the response and extract the access_token.
What are the capabilities of My Domain?
- Highlight your business identity with your unique domain URL
- Brand your login screen and customize right-frame content
- Block or redirect page requests that don't use the new domain name
- Work in multiple Salesforce orgs at the same time
- Set a custom login policy to determine how users are authenticated
- Let users log in using a social account, like Google and Facebook, from the login page
- Allow users to log in once to access external services
What Salesforce features MUST you have My Domain enabled for?
- 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
What are the capabilities of a Connected App?
- It can connect to salesforce.com over Identity and Data APIs.
- Connected Apps use the standard OAuth 2.0 protocol to authenticate, provide Single Sign-On, and acquire access tokens for use with Salesforce APIs.
- Connected Apps add additional levels of control, giving administrators explicit control over who can use the application and various security policies to be enforced by the application
What are the different ways you can use SSO (single sign-on) in Salesforce?
- Federated authentication using SAML
- Delegated authentication
- Authentication providers
- SSO for Portals
- SSO for Sites
Federated authentication using SAML
- Allows you to send authorisation and authentication data between unrelated web services
- Enables login to Salesforce from a client application
- is enabled for your org automatically
Delegated authentication SSO
- integrates Salesforce with an authentication method selected by you
- allows you to integrate with your LDAP (Lightweight Director Access Protocol) server
- allows you to use a token for authentication, instead of a password
- has to be enabled by Salesforce support
- is managed at permissions level (not org level), so you can require some people to use this and others to login with a username and password
The benefits of delegated authentication SSO are
- It uses a stronger form of authentication e.g. integration with a secure IdP (Identity Provider)
- It makes your login page only accessible from behind a corporate firewall
- Differentiates your org from all other companies that use Salesforce to reduce phishing attacks
Authentication providers (for single sign-on)
- allow users to login to Salesforce using login credentials from an external service provider
- allow users to to login from any OpenID Connect provider such as Facebook
- do not validate passwords; they use the login credentials from the external service provider to authenticate
Best practices and considerations for implementing Delegated Authentication SSO
- deploy the web service on a server in your DMZ (de-militarised zone)
- If Salesforce and your system can't connect, or if the request takes longer than 10 seconds to process, the login attempt fails. Users get an error.
- Namespaces, element names and capitalisations must be exact for SOAP requests
- Wherever possible, generate your server stub from the WSDL file to ensure accuracy.
- Make your web service available through TLS. It's more secure as a certificate is required
- Implement trusted IP ranges to restrict access to Salesforce via the user's location
- You might need to map your org's internal usernames to your Salesforce usernames. If your org doesn't follow a standard mapping, try extending your user database schema (for example, Active Directory) to include the Salesforce username as an attribute of a user account.
- Don't enable SSO for Salesforce administrators - if your SSO server goes down, admins can't get back in - they need to, in order to disable SSO in the event of a problem
- Build in a developer edition or sandbox first, and test with Salesforce clients, such as Salesforce for Outlook, Connect for Office, and Connect Offline
Best practices and considerations for implementing Federated Authentication SSO
- Enter the Salesforce login URL from the Single Sign On Settings configuration page into the corresponding configuration parameter of your identity provider. Sometimes, the setting is called the recipient URL.
- Salesforce allows a maximum of 3 minutes for clock skew with your IDP server. Make sure that your server's clock is up to date.
- If you can't log in with SAML assertion, check the login history and note the error message. Use the SAML Assertion Validator on the Single Sign On Settings configuration page to troubleshoot.
- Map your orgs internal usernames and Salesforce usernames using the FederationIdentifier field of each Salesforce user.
- you can extend your user database schema (for example, Active Directory) to include the Salesforce username as an attribute of a user account.
- Before allowing users to log in with SAML assertions, enable the SAML org preference and provide the necessary configurations.
- Use the My Domain feature to prevent users from logging in to Salesforce directly, and give admins more control over login policies.
- Test in a developer edition or sandbox first
- Sandbox copies are made with federated authentication with SAML disabled. Any configuration information is preserved, except the value for Salesforce Login URL.
Best practices and considerations for implementing SSO for Portals
- Only SAML version 2.0 can be used
- Only Customer Portals and partner portals are supported.
- Service provider-initiated login is not supported.
- Both the portal_id and organization_id attributes are required. If only one is specified, the user receives an error.
- If both the portal_id and organization_id attributes are populated in the SAML assertion, the user is directed to that portal login. If neither is populated, the user is directed to the regular SAML Salesforce login.
- More than one portal can be used with a single org.
Best practices and considerations for implementing SSO for Sites
- Only SAML version 2.0 can be used
- Only Customer and partner communities are supported.
- Service provider-initiated login is not supported.
The portal_id, organization_id, and siteUrl attributes are required. If only one is specified, the user receives an error.
- If all the portal_id, organization_id and siteUrl attributes are populated in the SAML assertion, the user is directed to that Sites login. If the siteUrl isn't populated and the other two are, the user is directed to the portal login.
- More than one Site can be used with a single org.
What does an Identity licence do?
Grants users access to Salesforce Identity features.
Salesforce Identity
- connects Salesforce users with external applications and services
- while it gives administrators control over authentication and authorisation for these users.
What does an External Identity licence do?
Provides Identity features for users outside of your organisation'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.
Benefits of SSO
- Reduced admin costs
- Leverage existing investments by delegating authentication to LDAP and others
- Time savings - Saves users time that would otherwise be spent logging in
- Increased user adoption - users are more likely to use a system that is easy to access
- Increased security - Corporate network policies are applied to Salesforce, and sending a temporary credential is more secure for users who access sensitive data
What is Just-in-Time Provisioning?
Using a SAML assertion to create regular and community users on the fly the first time they try to log in.
What are the benefits of Just-in-Time Provisioning?
• Reduced Administrative Costs: Provisioning over SAML allows customers to create accounts on-demand, as part of the single
sign-on process. This greatly simplifies the integration work required in scenarios where users need to be dynamically provisioned,
by combining the provisioning and single sign-on processes into a single message.
• Increased User Adoption: Users only need to memorize a single password to access both their main site and Salesforce. Users are
more likely to use your Salesforce application on a regular basis.
• Increased Security: Any password policies that you have established for your corporate network are also in effect for Salesforce.
What is the significance of a scope parameter?
It allows you to fine-tune the permissions associated with the tokens you're requesting.
The api scope parameter...
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.
The chatter_api scope parameter...
Allows access to Chatter REST API resources only.
The custom_permissions scope parameter...
Allows access to the custom permissions in an organization associated with the connected app, and shows whether the current user has each permission enabled.
The full scope parameter...
Allows access to all data accessible by the logged-in user, and encompasses all other scopes. It does not return a refresh token. You must explicitly request the refresh_token scope to get a refresh token.
The id scope parameter...
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.
The openid scope parameter...
Allows access to the current, logged in user's unique identifier for OpenID Connect apps.
It can be used in the OAuth 2.0 user-agent flow and the OAuth 2.0 Web server authentication flow to get back a signed ID token conforming to the OpenID Connect specifications in addition to the access token.
The refresh_token scope parameter...
Allows a refresh token to be returned if you are eligible to receive one. This lets the app interact with the user's data while the user is offline, and is synonymous with requesting offline_access.
The visualforce scope parameter...
Allows access to Visualforce pages.
The web scope parameter...
Allows the ability to use the access_token on the Web. This also includes visualforce, allowing access to Visualforce pages.
How single sign-on works:
1. When a user tries to log in—either online or using the API—Salesforce validates the username and checks the user's profile settings.
2. If the user's profile has the "Uses Single Sign-on" user permission, then Salesforce does not authenticate the username with the password. Instead, a Web Services call is made to the user's single sign-on service, asking it to validate the username and password.
3. The Web Services call passes the username, password, and sourceIp to a Web Service defined for your organization. (sourceIp is the IP address that originated the login request). You must create and deploy an implementation of the Web Service that can be accessed by Salesforce.com servers.
4. Your implementation of the Web Service validates the passed information and returns either "true" or "false."
5. 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 was invalid.
How to enable SSO:
Contact Salesforce.com to turn on Single Sign-On for your organization.
2. Build your SSO Web Service:
Download the Web Services Description Language (WSDL) file, AuthenticationService.wsdl, that describes the Single Sign-On service. It can be used to automatically generate a server-side stub to which you can add your specific implementation. For example, in the WSDL2Java tool from Apache Axis, you can use the --server-side switch. In the wsdl.exe tool from .NET, you can use the /server switch. The WSDL is available within Salesforce by clicking Setup | Integrate | API | Delegated Authentication WSDL.
3. In Salesforce, specify your organization's Single Sign-On Gateway URL by clicking Setup | Security Controls | Single Sign-On settings.
4. Modify your user profiles to contain the "Uses Single Sign-On" user permission. In Salesforce, click Setup | Manage Users | Profiles to add or edit profiles. It is recommended you create a new user with a new profile to test single sign on. Do not test with the administrator account.
What are the pre-requisites for enabling SSO across multiple orgs?
- All Orgs must be enabled with a custom hostname using 'My Domain'
- One Org must be selected to act as the Identity Provider
- A master list of all users
- A "Federated ID" for each user, unique for each person across users of all Orgs.
- The Dataloader, to bulk upload updates to usernames in the SP Orgs
What are the configuration steps for SSO in multiple orgs?
1) Enable My Domain for each org
2) Deploy each 'My Domain' to your users
3) Enable the Identity Provider in your Identity Provider Org
4) Download the Self-Signed Certificate from the IDP Org
5) Configure SAML in your first Service Provider Org
6) Tell your Identity Provider about this Service Provider Org
7) Test your configuration
8) Repeat steps 5 and 6 for each additional Service Provider Org
Which two parameters are needed in order to authenticate the external application?
- API session ID
- API Partner Server URL (endpoint for Salesforce)
How are the API session ID and endpoint URLs used together?
Applications use the SID to represent that user in future API requests and the SOAP Endpoint to communicate with the appropriate API server.
What must be taken into account to ensure that single sign-on transactions that use SID and the endpoint URL stay secure?
- Because the SID is equivalent to a password, steps should be taken to protect it from interception in transit, e.g. enforcing SSL and validating certificates.
- The API Session ID should never be transmitted to 3rd party sites such as Google Analytics.
- In order to prevent authentication and data transmission through a rogue endpoint, the API Partner Server URL should be validated to be a legitimate Salesforce.com SOAP Server (use a REGEX function to enforce the URL format)
What are some advantages of limiting session length?
- limits exposure to your network when a user leaves the computer unattended while still logged in
- limits the risk of internal attacks, such as when one employee tries to use another employee's session
What is the purpose of a self-signed certificate?
Generate a certificate signed by Salesforce to show that communications purporting to come from your organization are really coming from there.
What are the features of Salesforce Identity?
- Cloud-based user directories, so user accounts and information are stored and maintained in one place, while available to other services or apps.
- Authentication services to verify users and keep granular control over user access. You can require two-factor authentication, select which apps users can use, and set how often individual users log in to maintain their session.
- Access management and authorization for third-party apps, including UI integration, so a user's apps and services are readily available.
- App user provisioning, which streamlines the process for providing and removing access to apps to multiple users simultaneously.
- An API for viewing and managing Identity features.
- Identity event logs for creating reports and dashboards on single sign-on and connected app usage.
- Identity Connect allows you to manage AD users and Salesforce users simultaneously. You can configure Identity Connect to give AD users access to their Salesforce orgs without logging in again.
What is Two-Factor Authentication?
users are required to log in with two pieces of information, such as a username and a one-time password (OTP). Salesforce supports user-defined OTPs and OTPs generated from software or hardware devices.
Which two OAuth 2.0 flows can be used with Force.com Canvas?
- Web Server OAuth Authentication Flow
- User-Agent OAuth Authentication Flow
What are the capabilities of an external identity licence?
- You can store and manage customers and partners, authenticate them through username and password, SSO, and authentication providers.
- You can set up authentication providers to allow users to log in with their credentials from their social accounts, such as Facebook, Twitter, and LinkedIn.
- External Identity supports self-registration to easily provision new users.
- You can upgrade this licence to a Customer Community or Partner Community license to benefit from Community features.
What objects can an External Identity user access?
- Accounts
- Assets
- Chatter
- Contacts
- Identity
- Files
- up to 10 custom objects
How would you set up a login flow?
- Build a flow from scratch or use a pre-created flow (like the one provided by Yubico). Or, modify an existing flow to add functionality or enforce more policies.
- Connect a login flow to a profile:
Navigate to the login flow page, select the flow, and associate it with a user profile.
What happens when a login flow executes?
- At runtime, Salesforce authentication redirects every user with that profile through the login flow.
Two things to understand about login flow execution:
- To invoke a login flow, the user must first be authenticated. Login flows don't replace the existing Salesforce authentication process. Login flows integrate new steps or ask the user for information.
- During login flow execution, users have restricted access. Users in a login flow can access only the flow—they can't bypass it to get to the application. They can log in to the org only when they successfully authenticate and complete the flow.
What can you do with a login flow?
- Enhance or customize the login experience (for example, add a logo or login message).
- Collect and update user data (for example, request an email address, phone number, or mailing address).
- Interact with users, and ask them to perform an action (for example, complete a survey or accept terms of service).
- Connect to an external identity service or geo-fencing service, and collect or verify user information.
- Enforce strong authentication (for example, implement a two-factor authentication method using hardware, SMS, biometric, or another authentication technique).
- Run a confirmation process (for example, have a user define a secret question, and validate the answer during login).
- Create more granular policies (for example, set up a policy that sends a notification every time a user logs in during non-standard working hours).
When a user logs in from outside a trusted IP range and uses a browser or app Salesforce doesn't recognise, the user is challenged to verify identity.
The highest-priority verification methods available are used for each user. In order of priority, the methods are:
1) Verification via push notification or location-based automated verification with the Salesforce Authenticator mobile app (version 2 or later) connected to the user's account.
2) Verification via a U2F security key registered with the user's account.
3) Verification code generated by a mobile authenticator app connected to the user's account.
4) Verification code sent via SMS to the user's verified mobile phone.
5) Verification code sent via email to the user's email address.
After identity verification is successful, the user doesn't have to verify identity again from that browser or app, unless the user:
- Manually clears browser cookies, sets the browser to delete cookies, or browses in private or incognito mode
- Deselects "Don't ask again" on the identity verification page
What happens when an OAuth 2.0 user-agent flow is used?
users authorise your desktop or mobile app to access their data
What client types can use the user agent flow?
client apps (consumers) that reside on the user's device or computer.
How does the user-agent flow work?
- 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.
;