Identity and Access Management

In the real world of salesforce, we might need to connect other applications seamlessly without compromising security, and Identity & Access Management deal with this complication.

In the below picture, salesforce is communicating with different cloud applications like a workday, mule, and other cloud-based applications. Along with this, it connected with Social clouds like Facebook, Linkedin, or Twitter, and premise systems that might be sitting behind the firewall, and mobile applications. 

In the above flow, There are two questions have been raised apart from Integration:

1. How do you determine the identity (Authentication) of the user to be logged in. For example, if someone logged in to salesforce and wanted to open Facebook, you facebook understand the identity of that user.

2. How do you determine the access (Authorization) of the user?

Identity & Access Management provides the answer to these two questions. Identity & Access Management ensures:

-the right people to get

-the right access

-the right resource 

-at the right time.

Authentication Vs Authorization 

Authentication	Authorization
Process of identifying a user based on a set of verifiable credentials such as username & password.	Determines if a user has permission to access resources on the server.
Process or action of proving or showing something to be true, genuine, or valid.	Verify the access of authenticated user and can grant or deny the access
Authentication means who a person is. These days, authentication is often used as shorthand for authorization and authentication.	Authorization means what a person can do.
Authentication can be done on the server itself or it can be sent to a 3rd party to authenticate.	Authorization cannot be done without authentication
Identify Management deals for authentication.	Access Management deals with authorization.
You control who can access your orgs and who can use apps running on the Salesforce Platform, on-premises, in other clouds, and on mobile devices.	You control what can be accessed in your orgs after authentication.

Benefits of Identity 

You control who can access your orgs and who can use apps running on the Salesforce Platform, on-premises, in other clouds, and on mobile devices with Identity which can help you in different ways:

• Convenience - Employees can log in to a workstation and connect to a Salesforce org without logging in again. In fact, they can have a single login that works for all their web and mobile apps. You can give them one-click access to third-party productivity tools and services, like Gmail or Microsoft Office 365. Users don’t have to remember lots of usernames and passwords.

• Control - Managers and supervisors can have more control over their employees. If you want fine-grained control over who uses what, you can require that a manager or supervisor approve employee requests to access an app or service. And when you need to revoke access to an app, you can do that, too.

• Security - The magic of Salesforce Identity is that more convenience plus greater control adds up to enhanced security. One identity source for user credentials across corporate networks and the web makes it easy for you and other Salesforce admins to monitor and manage usage. Reduce redundant accounts, and you reduce your vulnerability to malicious activity. And with multi-factor authentication, you can be twice as confident that your users are who they claim to be.

Features provided of Salesforce Identity

Identity helps to log in to the system in an easier way without compromising security. There are multiple features that support Salesforce Identity:

• Single sign-on

• Connected apps

• Social sign-on

• Multi-factor authentication

• My Domain

• Centralized user account management

• User provisioning

• Identity Connect

• App Launcher

Identity Standards & Protocols-

There are industry standards and protocols for identity and access management which helps users’ identities secure when they don’t have to sign in to external websites or apps. A standard is just a set of widely agreed-upon practices that industry members follow. A standard can include a protocol that specifies how systems exchange information.

Here are the three protocols that Salesforce and other identity vendors follow to implement identity solutions.

1. SAML

2. OAuth 2.0

3. OpenID Connect

SAML Protocol-

When you want users to move seamlessly between Salesforce orgs and applications without logging in repeatedly, you set up single sign-on (SSO). SAML is an XML-based protocol, which means that the packages of information being exchanged are written in XML.

Here are a couple of examples of SAML in action.

• When you’re logged in to Salesforce and then click the App Launcher to get directly to your Gmail inbox, that’s SAML in action.

• When users who are already logged in to another app can access their Salesforce org without logging in again, that’s also SAML in action.

How does SAML work?

• A user tries to access a service. The service provider sends out a request to the identity provider basically asking, “Hey, is it okay if this user accesses my service?” The identity provider makes sure that users are who they say they are by checking its database and then returning a response—an assertion—saying, “Yes, this user is authorized, and here’s some information about the user.”

• The assertion is the information being sent. An assertion can carry detailed information about a user. It can also contain attributes about the user, like first and last names, contact information, maybe even the job title.

• SAML happens in the background. Your users don’t see any of it. They just click an icon or link and open another app without having to provide additional information or log in again. Sometimes their destination already knows something about them (those user attributes) when they get there.

OAuth 2.0 Protocol

OAuth 2.0 is an open protocol used to allow secure data sharing between applications. The user works in one app but sees the data from another. For example, you’re logged in to your Salesforce mobile app and see your data from your Salesforce org.

Behind the scenes, the apps perform a kind of handshake and then ask the user to authorize this data sharing. When developers want to integrate their app with Salesforce, they use OAuth APIs. Here are a couple of examples.

• A mobile app that pulls contacts from a Salesforce org uses OAuth.

• A Salesforce org gets contacts from another service also uses OAuth.

• Workbench uses oAuth 2.0 protocol for connecting with salesforce.

The following is an example of an app asking the user for permission to access information using OAuth 2.0.

OpenID Connect Protocol

• The OpenID Connect protocol adds an authentication layer on top of OAuth 2.0 to enable secure exchange of user information. Like SAML, OpenID Connect sends identity information from one service to another. Unlike SAML, OpenID Connect is built for today’s world of social networks. Have you ever installed a new app and come across a prompt like "Log in with your Google account"? That app is using the OpenID Connect protocol. When you sign in with Google, you’re not creating an account and another password. Only Google holds that information.

• The app developer used the OpenID Connect protocol to enable social sign-on.For instance, when Google verifies a user’s identity on behalf of another service, it’s authenticating the user. In this way, Google is an identity provider.

• Salesforce builds in support for several major social identity providers, including Google, Facebook, and LinkedIn. If a provider isn’t supported out of the box, you can still use it if it implements the OpenID Connect protocol—Amazon and PayPal, for example.

The advantage of the OpenID Connect protocol for users is that they can reduce the number of separate accounts, usernames, and passwords. On the flip side, developers can authenticate their users across websites and apps without having to own and manage password files. This process makes it that much harder for hackers to compromise user accounts.

Service Providers and Identity Providers

In the process of authenticating users, SAML exchanges identity information between the holder of the information called an identity provider (IdP), and the desired service, called a service provider. For Example- In the case where a user logs in to Salesforce and then accesses Gmail, Salesforce is the identity provider, and Google is the service provider. Salesforce can be both a service provider and an identity provider.

Salesforce as a Service Provider

Authenticated users can flow from an external identity provider into Salesforce. In this case, Salesforce is a service provider—users want to get access to this service, and their identity provider allows them to do so. This Salesforce configuration is common because often your company is already using an identity provider. The identity provider could be one of several on the market, like Microsoft’s Active Directory Federation Services (ADFS), Ping Identity’s PingFederate, open-source Shibboleth, or ForgeRock’s OpenAM.

Users log in from an identity provider and are then redirected to Salesforce (the service provider). In another module, you’ll set up SSO with Salesforce as a service provider and a third-party application as the external identity provider.

Salesforce as an Identity Provider

Authenticated users can also flow from Salesforce to other clouds and apps. In this case, Salesforce acts as an identity provider and provides SSO for users to connect to different service providers.