Chapter 4: Set

The activity of defining the processes, tools, monitoring mechanisms, and governance required to grant the enterprise’s internal and external users access to the right digital assets in a well-governed and secure manner.

This is what is used to recognize a particular individual or thing. In systems, a unique alphanumeric identifier is usually utilized to recognize someone, such as a national ID, social security number, or even an employee ID.

The process or series of processes used to identify a particular individual or thing uniquely, securely, and confidently. The user is expected to prove their identity using one or more techniques, and once that is done, the application would operate based on the recognized identity.

This is a security mechanism where a successful authentication process would require the user to pass more than one identity validation process using different methods. For example, the user might be requested to provide something they know (such as a password), something they have (such as a one-time token received on a mobile phone), and something they physically possess (such as a fingerprint). In MFA, the user is normally requested to pass three (or more) different security layers. A more relaxed security mechanism is normally referred to as 2FA, which requires passing just two identity validation processes.

This process takes place after authenticating a particular user to grant the right privileges to see, do, and have things within a particular system.

This is a design principle used while designing an authorization strategy where users, applications, and devices are granted the minimal sufficient privileges required to operate normally and deliver their desired functionality.

This means the databases or systems with directory structures that are used to hold information about the users (or, in general, identities) that a particular system uses, such as names, phone numbers, and email addresses, in addition to any other information required to authenticate a user, such as the unique user identifier or passwords (remember, passwords should never be stored in plain text or even in an encrypted form that can be decrypted; passwords are normally stored as hash values that are impossible to reverse/decrypt).
The identity store can also contain the user’s group memberships, which define the privileges granted to a particular user. The identity store can simply be a database or something more advanced, such as Microsoft AD.

The IDP (or IdP) is a trusted system that manages the identities of known users/principals. It normally includes capabilities such as creating, updating, and generally maintaining the different identity information. Moreover, it provides authentication services that can be used by other applications.
IDPs can provide identity maintenance and authentication services either by using their own capabilities or relying on connected identity stores. In other words, the IDPs do not necessarily need to maintain the values used for authentication (such as passwords) as they can connect to the identity store that does and rely on the identity store itself to provide the authentication services while providing a layer on top of that to facilitate and standardize the entire process and associated user experience.

The applications provide specific services for internal or external users and rely on other IDPs to provide IAM capabilities (including user management and authentication). SPs typically have their own user repositories (such as databases) and user access control management consoles.
Depending on its role in a particular SSO setup, Salesforce can play the role of IDP, SP, or both. Other SP examples include applications such as Workday, SAP, and many others.

This is a process where a user is allowed to authenticate once to access multiple applications. A common form of SSO is where a user authenticates to one application using any authentication mechanism (such as credentials) and then attempts to access resources that belong to another application also linked with the same SSO mechanism. The user would not need to authenticate again in this case.

A unique identifier for users to map local users to the IDP’s users. The federated identifier can take multiple shapes and forms, such as an email address, social security number, or simply a unique enterprise ID.

User provisioning is the process of creating a user in an identity repository. That includes global and local identity repositories. Normally, there will also be a set of roles assigned to the user in each repository.
De-provisioning is exactly the opposite process and involves deactivating or deleting an identity from global and local identity stores, including any roles associated with it.

This is a tool/module used to manage the user’s privileges to access specific functionalities, database objects, records, or fields. This tool/module is used to assign users specific roles that control what these users can see and do across the entire network. Depending on the RBAC tool itself, roles might also be referred to as group memberships.

This is a standard to automate the transfer of identity/principal information across the systems. It can be used to provision and de-provision users within an SSO-integrated landscape.

The process of uniquely identifying a person using biological attributes, such as a fingerprint, retina scan, voice, facial recognition, and more.

This is a solution that provides identity services in a SaaS fashion. It normally offers an online portal with some tools and control panels to configure and style it in the desired way. Examples of these providers include Okta, Microsoft Azure identity management, Ping Identity, and, to some extent, Salesforce.

This technique uses different tools and algorithms to calculate a risk score for the user trying to access a secure resource or attempting to authenticate. Based on the calculated risk score, the user might be asked to provide a second factor of authentication or more.

This is a protocol that was designed to provide a standardized mechanism to interact with data stored in a hierarchical directory structure.

This is a tool that stores the enterprise data (usually, policies, roles, and permissions) in a hierarchical structure. These types of tools are normally referred to as directory service databases.

In some use cases (particularly when accessing APIs), authentication can typically take one of two flavors. You either authenticate using a named principal (also known as a service user) where you only need to authenticate a single integration user, or you follow a per-user policy, which means that you authenticate each user connected to the system at least once.

These are well-defined processes that describe precisely how to use the given IAM standard to authenticate a user for a given use case.

The SAML standard was created in 2001. It is currently in version 2.0, which was released in 2005. SAML is considered a standard for both authentication and authorization, and it is based on XML. In SAML, the SP can ask an IDP to authenticate and authorize a user/principal using a SAML assertion request. The IDP responds with a SAML assertion response.

OAuth is an open standard that was created to solve a particular problem, normally referred to as access delegation or secure delegated access, which is simply allowing an application (normally referred to as the client) to access resources or perform activities on a server (normally referred to as the resource server) on behalf of a user. The standard facilitates this process without the need for the user to share their credentials with the client. This is done by utilizing tokens issued by an IDP, upon the user’s approval, containing a description of what the client is authorized to access and do on the resource server.

OpenID is a standard based on OAuth 2.0, but it is designed for a different purpose. It is designed to provide a federated authentication mechanism that is similar to SAML. It adds a set of different functionalities on top of OAuth 2.0, but the one you should be particularly aware of is an additional token generated called the ID token. The ID token contains information about the authenticated user, such as first name, email, federated identity, and the requesting client, in addition to custom attributes that could be added by the IDP. This token can help confirm the identity of the individual for whom this token has been issued.

This authentication protocol is used over networks (such as a local enterprise network) to provide SSO capabilities. It uses tickets, which are similar in principle to tokens.

The access token is the ultimate token that your applications are after. This is the token that will allow an application to authenticate to a resource server and request resources (such as retrieving specific data) on behalf of the user.

A token that is used to get a new access token periodically or whenever needed. Refresh tokens are issued for clients in specific use cases. Refresh tokens normally have longer longevity than access tokens. Sometimes, they can be set so that they never expire (until they get revoked). Refresh tokens should be stored in a secure location by the client application.

A token that provides a mechanism for the client application to verify the identity of the user for whom this token has been issued. The ID token contains information such as the time of issue and the time of expiry, in addition to data regarding the authenticated user, such as the user’s unique identifier.

JWT is a standard to format data that can be used to assert the identity of a party to other parties as well as asserting a set of information (referred to as claims) that is included in the token itself. ID tokens are one type of token that use the JWT format.

This is also known as the session ID. The session token is a unique string (normally, a hash value) that identifies a particular session for the currently logged-in user.

This is a special type of token. It is used in one of the OAuth 2.0/OpenID flows (the web server flow). It has a very short TTL, and it is created by the authorization server and returned (via the browser) to the client application.

SAML assertions can be used to authenticate a user to a particular resource server/SP. They contain information such as user identity, issue time, and expiry time.

When you attempt to access Salesforce APIs and authenticate using a basic authentication mechanism (username/password), you need to append the security token to the password provided. The token itself is a case-sensitive alphanumeric key. You should try to avoid basic authentication as much as possible and utilize one of the standards mentioned before, such as OIDC.