While studying for the Identity & Access Manangement Designer exam I kept note of all the terms I came accross - here is the "dictionary". This really helped me understand the core principals and vocabulary. If you understand all these dictionary-items you are more than half way prepared for the exam!
A Access Token - Access tokens have a limited lifetime specified by the session timeout in Salesforce. If an application uses an expired access token, a “Session expired or invalid” error is returned.
Active Directory Single Sign-On - 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
C Canvas - Signed Request Authentication -->This is the default authorization method for canvas apps. The signed request authorization flow varies depending on whether the canvas app’s Permitted Users field is set to "Admin approved users are pre-authorized" or "All users may self-authorize." Signed request considerations:
Salesforce performs an HTTP POST or GET when invoking the canvas app URL, depending on the Permitted Users value and whether the refresh token is returned.
Server-side code is needed to verify and decode the request.
You can request a signed request on demand, after the app is invoked, by using the SDK.
Certificates - Salesforce certificates and key pairs are used for signatures that verify a request is coming from your organization. They are used for authenticated SSL communications with an external web site, or when using your organization as an Identity Provider. You only need to generate a Salesforce certificate and key pair if you're working with an external website that wants verification that a request is coming from a Salesforce organization. You can have up to 50 certificates. Self-signed: Generate a certificate signed by Salesforce to show that communications purporting to come from your organization are really coming from there. Note that you can set longer lifetimes for self-signed certificates, decreasing your maintenance. CA-signed: A certificate authority-signed (CA-signed) certificate can be a more authoritative way to prove that your org’s data communications are genuine. You can generate this type of certificate and upload it to Salesforce. API Client Certificate: Under Certificate and Key Management. The API client certificate is used by workflow outbound messages, the AJAX proxy, and delegated authentication HTTPS callouts It can be a Self-signed, CA-signed certificate. For increased security, don’t use the default certificate for your API client certificate. The default certificate is shared across all organizations. Instead, select a certificate that is known only to your org to use as the API client certificate.
Community
Community registration and experience: All your org’s communities share the default self-registration pages and controllers. If you enable self-registration for multiple communities, you must further customize the self-registration experience, for example, to direct users to different pages or assign different profiles or permission sets for different communities. What’s a registration handler? A registration handler (sometimes called reghandler) creates and updates a user on the fly with identity information pulled from the authentication provider, in this case, Facebook. A registration handler allows you to get additional information from Facebook, like a profile picture, to use when creating the Salesforce user.
Use Custom Change Password and Forgot Password Pages in Your Community
You can customize Forgot Password and Change Password pages from the Password section of the Administration Login & Registration page. Or you can create custom password pages in Visualforce. You can also customize the default password templates in Visualforce. or a Custom Community Builder Forgot Password page, Communities support all available authentication flows, except for the username-password OAuth authentication flow and the SAML assertion flow
Self-Registration for Your Community
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. Keep in mind that each time a user self-registers, the user consumes one of your Communities licenses. When setting up your self-registration page, add some criteria to ensure that the right people are signing up. To prevent unauthorized form submissions, we recommend that you use a security mechanism, such as CAPTCHA or a hidden field, on your self-registration page. If you don't specify the account for Self-regstration,
If person accounts are enabled, when a customer self registers, it will create a persona account -
if not it will produce an error
COnnected APp - User Provisioning for Connected Apps As an administrator, use connected apps with user provisioning to create, update, and delete user accounts in third-party applications based on users in your Salesforce organization. For your Salesforce users, you can set up automatic account creation, updates, and deactivation for services such as Google Apps and Box. You can also discover existing user accounts in the third-party system and whether they are already linked to a Salesforce user account.
Use Cases for Login Flows
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).
D
What is Deep Link? - Deep Link is a popular technique that lets mobile apps interact with each other using hyperlinks. Developers can pre-define behaviors with the URI scheme (i.e. Display/edit information, enable device feature, or simply switch between apps). For example, suppose you are searching for the nearest fast food restaurant with your phone’s web browser. You find the address of your favorite place and click on it. You’re then taken directly to the Maps app with the destination already configured. This is a great example of providing additional services with a seamless experience to an end user.
Salesforce.com: When My Domain is activated, how to setup deep linking
A customer is trying add the SP-initiated SSO profile, including deep linking, to Salesforce.com. "My Domain", a Salesforce.com feature, is activated; however, deep linking does not work. SSO requests always go back to home.jsp. Solution: When the My Domain feature is activated in Salesforce.com, to support SP-initiated SSO profile with deep linking:
On PingFederate, in the SP connection to Salesforce.com, enable the SP-initiated SSO profile.
On Salesforce.com, go to Setup > Security Controls > Single Sign-On Settings page. Make sure the Identity Provider Login URL is pointing to the /idp/SSO.saml2 endpoint.
Good example: Identity Provider Login URL: https://sso.company.tld/idp/SSO.saml2
Bad example: Identity Provider Login URL: https://sso.company.tld/idp/startSSO.ping
On Salesforce.com, go to Setup > Domain Management > My Domain. Scroll down to the Login Page Branding section. Click Edit, and change Authentication Service from Login Page to your SAML authentication service name. This service name is found in Setup > Security Controls > Single Sign-On Settings page.
E
External Identity: Identity for Customers and Partners
When used for external identities, Salesforce Identity transforms CRM contacts into real digital identities that can
self-register,
log in,
update their profile,
and securely access web and mobile applications with a single identity.
Plus, it’s customized to your specific business process and brand using the power of the Salesforce Platform
External Identity Licenses
External Identity is a type of Salesforce license that enables you to deliver identity services, such as single sign-on (SSO) and social sign-on
External Identity is a standalone license and purchased in blocks of active users.
you can access several standard objects and 10 custom objects
The license includes extra data storage and API requests.
External Identity works with Community licenses.
It’s also included for free with all paid community user licenses
These licenses are also available for managing user identities.
F
Federation ID - The Federation ID is a unique username for each user that can be shared across multiple applications. Sometimes this is the employee ID for that user. The important part of the Federation ID is that it is not duplicated for more than one user within a single Salesforce organization (you can have the same Federation ID for the same user in more than one Salesforce organization). The Federation ID must is case sensitive The Federation ID must be populated on the user record.
I Identity Provider → An identity provider is a trusted provider that lets you use single sign-on (SSO) to access other websites.
Identity Connect → Identity Connect integrates Microsoft Active Directory (AD) with Salesforce. What does Identity Connect do?
User management
- Use Identity Connect to upload and synchronize user data from Active Directory 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
SSO - You can set up single sign-on using Identity Connect so users who sign into their desktop environment can use Salesforce without logging in separately.
On-premise identity service with a browser-based admin UI.
Supports Windows, OSX and Linux hosts.
Can be installed on Windows as a service.
Install, configure, run service. Quick to get up and running.
No ADFS proxy equivalent.
An org must be activated for Salesforce identity, this adds a download link to the setup menu and feature licenses. One SIC instance can support multiple orgs (with different configurations). Sandboxes are supported.
Setup steps: create connections (SF and AD, define mappings, set schedule, configure SSO)
No local storage of users and passwords, user associations are held in a local MySQL db.
Connects to a SF org via OAuth 2.0 Multiple direct AD Domain Controller connections are not supported, instead a connection should be made to the Global Catalogue where multiple domains must be spanned. Note this approach requires manual modification of the AD schema. User licenses are managed via Permission Set Licensing, not feature licensing. Org must have Multiple SAML Configurations enabled. Federated user authentication is supported via SAML 2.0 Service Provider Initiated and Identity Provider Initiated flows. Limits: • Identity Connect does not support mapping and synchronization of Salesforce Permission Set License Assignments
M
My Domain - A benefit of configuring 'My Domain' is that it enables support for SP-initiated single sign-on, improving the user experience, and allowing users to access 'deep links' into their environment via SSO. In order to take advantage of SAML for desktop and mobile apps you must deploy My Domain. 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
Mobile App- the Force.com platform considers the Salesforce mobile app to be a connected app. IP Relaxation refers to IP restrictions for your users. You can either enforce or bypass these restrictions.
Enforce IP restrictions: Salesforce app users are subject to the org’s IP restrictions, such as IP ranges set in the user’s profile.
Relax IP restrictions with second factor: Users bypass the org’s IP restrictions if they successfully complete an identity verification.
Relax IP restrictions: Users aren’t subject to any IP restrictions.
SSO for mobile The combination of SAML and Oauth protocols is how Force.com enables single sign-on for desktop and mobile applications. By using OAuth to enable users to connect applications to their accounts, and leveraging SAML for the authentication of that connection, the single sign-on integration that was once only applicable for the web-browser can now service a wide variety of user applications.
The OAuth Client (mobile device) makes an authorization request to a hostname you specify. Using an embedded browser, the client (mobile device) asks for authorization from the user, but does so to the custom URL ( using a feature called 'My Domain' ). → in plain eglish the mobile phone creates a tiny web browser inside the mobile, and attempts to load the URL of the Force.com OAuth Authorization Service. (my domain)
Scope Parameter Values
OAuth requires scope configuration both on server and on client. The agreement between the two sides defines the scope contract.
Server side—Define scope permissions in a connected app on the Salesforce server. These settings determine which scopes client apps, such as Mobile SDK apps, can request. At a minimum, configure your connected app OAuth settings to match what’s specified in your code. For hybrid apps and iOS native apps, refresh_token, web, and api are usually sufficient. For Android native apps, refresh_token and api are usually sufficient.
Client side—Define scope requests in your Mobile SDK app. Client scope requests must be a subset of the connected app’s scope permissions.
ValueDescription
apiAllows 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_apiAllows access to Chatter REST API resources only.
custom_permissionsAllows access to the custom permissions in an organization associated with the connected app, and shows whether the current user has each permission enabled.
fullAllows 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.
idAllows 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.
refresh_token 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.
visualforceAllows access to Visualforce pages.
webAllows the ability to use the access_token on the Web. This also includes visualforce, allowing access to Visualforce pages.
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)
O
openid - Allows access to the current, logged in user’s unique identifier for OpenID Connect apps. The openid scope 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.
Oauth OAuth (Open Authorization) is an open protocol that provides secure API authorization from applications in a simple and standardized way. OAuth can authorize access to resources without revealing user credentials to apps. Apps that use OAuth can also directly authenticate and access Salesforce resources without a user present. OAuth 2.0 authorization framework 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
OAuth URL parameters
“redirect_uri” → After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request.
2.“state” → An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery
scope → The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued.
OAUTH 2.0.A AUTHENTICATION FLOWS:
Web server flow: - 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 flow: Desktops and mobiles, - 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 Flow: Reuse an existing authorization, JSON Web Token (JWT) is a JSON-based security token encoding that enables identity and security information to be shared across security domains. - 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 User password flow: Use the username-password authentication flow to authenticate when the consumer already has the user’s credentials. This OAuth authentication flow passes the user’s credentials back and forth. Use this authentication flow only when necessary. No refresh token is issued.
SAML Bearer Assertion Flow: A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider. The service provider relies on its content to identify the assertion’s subject for security-related purposes.
Refresh Token Flow: refresh token flow is for renewing tokens issued by the web server or user-agent flows.
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. 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 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
P
Phishing & Malware - What Salesforce Recommends You Do implement the following changes to enhance security:
Modify your Salesforce implementation to activate IP range restrictions. This allows users to access Salesforce only from your corporate network or VPN. For more information, see Restrict Where and When Users Can Log In to Salesforce.
Set session security restrictions to make spoofing more difficult. For more information, see Modify Session Security Settings.
Educate your employees not to open suspect emails and to be vigilant in guarding against phishing attempts.
Use security solutions from leading vendors to deploy spam filtering and malware protection.
Designate a security contact within your organization so that Salesforce can more effectively communicate with you. Contact your Salesforce representative with this information.
Consider using two-factor authentication techniques to restrict access to your network. For more information, see Two-Factor Authentication.
Use Transaction Security to monitor events and take appropriate actions. For more information, see Transaction Security Policies
R Refresh Token — If the application is using the Web server or user-agent OAuth authentication flows, a refresh token may be provided during authorization that can be used to get a new access token. Refresh token is not a flow - its a process inside other flows (web server and user-agent)
S service provider - A service provider is a website that hosts apps
SAML → Security Assertion Markup Language, is the The identity federation standard. Security Assertion Markup Language (SAML, pronounced sam-el [1] ) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider . As its name implies, SAML is an XML-based markup language for security assertions (statements that service providers use to make access-control decisions). SAML is also:
A set of XML-based protocol messages
A set of protocol message bindings
A set of profiles (utilizing all of the above)
Troubleshoot SAML Assertions — > Use the Salesforce SAML Validator to test and fix a SAML assertion. + SAML Browser tools or Developer Tools on Network logs
Single Sign On - TWO TYPES OF SSO:
delegated authentication single sign-on (SSO) -->You can integrate Salesforce with the authentication method of your choice using delegated authentication single sign-on (SSO). You can integrate with your LDAP (Lightweight Directory Access Protocol) server or authenticate with a token instead of a password. You manage delegated authentication at the permission level, not at the org level, giving you more flexibility. With permissions, you can require some to use delegated authentication while others use their Salesforce-managed password. It can connect to SOAP services. It can NOT connect to REST services It can be assigned by Permission Sets. It can be assigned by Profiles. It can not be assigned by custom permissions With delegated authentication, a user can experience a slight delay when logging in while the user account becomes available in the org. Federated SSO — federated authentication does not validate the user's actual password on the Force.com platform. the platform receives a SAML assertion in an HTTP POST request It establishes trust between Identity Store and Service Provider. It improves affiliated applications adoption rates. It enables quick and easy provisioning and deactivating of users. DIFFERENCE BETWEEN THE TWO
First, 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.
Second, 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.
SAML SSO Settings:
Issuer. Often referred to as the entity ID for the identity provider., eg http://axiomsso.herokuapp.com
Entity Id. The issuer in SAML requests generated by Salesforce, and is also the expected audience of any inbound SAML Responses. - usually the domain, eg https://rusticnastalje-dev-ed.my.salesforce.com
Identity Provider Login URL → The URL where Salesforce sends a SAML request to start the login sequence. (This field appears in Developer Edition production and sandbox organizations by default and in production organizations only if My Domain is enabled. This field does not appear in trial organizations or sandboxes linked to trial organizations.)
SAML Identity Location --> The location in the assertion where a user should be identified: NameIdentifier element or an Attribute element
SAML IDP parameters
RelayState: This captures the location of the resource the user originally requested. The RelayState will be provided from salesforce, so you just have to relay it back across the URL exactly the way you received it.
StartURL→ To direct your users to a specific location after authenticating, you need to specify a URL with the startURLrequest parameter. This URL must be a relative URL; passing an absolute URL results in an error. If you don’t add startURL, the user is sent to either /home/home.jsp (for a portal or standard application) or to the default sites page (for a site) after authentication completes.
SAML SSO & My domain
(1) If you are using My Domain, you can identify which users are logging in with the new login URL, and when. We can follow the path Your Name > Setup > Manage Users > Login History to look at the Username and Login URL columns. (2) When you use My Domain, since the target hostname at Salesforce is unique to your Organization, the correct IdP data for SSO can be looked up immediately from your own SSO configuration. (3) Use of My Domain when you have multiple Orgs (either production or sandboxes) allows your users to use exactly the same Salesforce Username for all of their Orgs. This makes doing SSO against your IdP-side credentials (AD, LDAP, Integrated Windows Authentication, etc.) easier since there is only one IdP identity per user that needs to be verified. In the best case, this means that one SSO login at one Org will allow that user access directly to any of their other Orgs without a new login. (4) Also in case of your own domain, you have your own SSL (hence increased security) and better SSO because you are using your own domain name rather than salesforce. So it improves your SSO because your name is in the domain. (5) When you are doing SAML SSO into Salesforce by starting with a Salesforce link (login page, deep link, Outlook Sync URL, etc.), Salesforce will not know in advance what Identity Provider you need to use, since it does not even know yet what Organization you are trying to SSO into. SP-initiated SSO - This process is referred to as SP-initiated SSO, and is distinct from the scenario where you start SSO at the IdP and send the identity information to Salesforce along with SAML protocol information that identifies your Organization and your IdP (IdP-initiated SSO). For generic login page setups, SP-initiated SSO requires that the user do an IdP-initiated SSO at least once first so that Salesforce can set a cookie in their browser identifying the IdP. (6) If single sign-on is enabled for your organization, API and desktop client users can't log into Salesforce unless their IP address is included on your organization's list of trusted IP addresses or on their profile, if their profile has IP address restrictions set. (7) Furthermore, the single sign-on authority usually handles login lockout policies for users with the “Is Single Sign-On Enabled” permission. However, if the security token is enabled for your organization, then your organization's login lockout settings determine the number of times a user can attempt to log in with an invalid security token before being locked out of Salesforce. (8) We do recommend customers not to enable single sign-on for system administrators. If your system administrators are single sign-on users and your single sign-on server has an outage, they have no way to log in to Salesforce. System administrators should always be able to log in to Salesforce so they can disable single sign-on in the event of a problem. 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
T
What is two-way SSL? - in two-way SSL, both the client and server presents a certificate to prove their identity to the other party. In two-way SSL, the identities of the client and server are represented by digital certificates. The trust between the two parties is established by having the certificates signed by a mutually trusted certificate authority. Currently, Force.com only trusts certificates that have been signed by a commercial, trusted certificate authority (often referred to as a trusted CA or just a CA Force.com only trusts certificates that have been signed by a commercial, trusted certificate authority (often referred to as a trusted CA or just a CA). The trust between the two parties is established by having the certificates signed by a mutually trusted certificate authority. When using mutual authentication/2-way SSL, Salesforce.com can present a self-signed certificate to the target host (that must present a CA signed certificate to Salesforce), provided that this certificate has been configured in the target host (installed in the target server's keystore).