Learn the Language of Identity
- Identify the industry standards used for identity and access management.
- Know how SAML is related to XML.
- Know the difference between an identity provider and service provider.
The answer: industry standards and protocols for identity and access management. That might sound intimidating, but it doesn’t have to be. 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.
- OAuth 2.0
- OpenID Connect
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.
This is how SAML works. 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.”
Wait a minute. What’s the difference between an identity provider and a service provider? Basically, the identity provider is the one authenticating the user. The service provider is asking for the authenticated identity. We’ll talk more about identity and service providers later on in this unit.
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.
SAML and XML
SAML is an XML-based protocol, which means that the packages of information being exchanged are written in XML. XML is supposed to be (almost) human-readable so that you can get some idea of what’s going on. That’s good news when you’re trying to figure out if things are working correctly.
The following diagram illustrates a portion of a SAML assertion. Does it look like gibberish? Look again and you can see that it doesn’t look all that bad. It contains information about a user’s username, phone number, and first name.
In this example, the Salesforce org passes the user’s information to another application. The application can use that information to authorize the user and personalize the user’s experience. But most importantly, the user doesn’t have to sign in again to access the application.
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.
The following is an example of an app asking the user for permission to access information using OAuth 2.0.
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.
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 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.
The SSO process all happens with lightning speed, but a few steps are involved.
- The user tries to access Salesforce.
- Salesforce recognizes the SSO request and generates a SAML request.
- Salesforce redirects the SAML request back to the browser.
- The browser redirects the SAML request to the external identity provider.
- The identity provider verifies the user’s identity and packages the SAML assertion containing the user authentication.
- The identity provider sends the SAML assertion to the browser.
- The browser redirects the assertion to Salesforce.
- Salesforce verifies the assertion.
- The user is now signed in and can access Salesforce.
|One Term||That’s Easily Confused with This Term|
|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.|
|Protocol specifies the set of rules that enable systems to exchange information. Generally, the term protocol and standard are used interchangeably.||Standard is a specification, a set of industry practices that vendors agree to support. Often, a standard contains a protocol to specify how the companies implement the standard.|
|Username and password are what the user supplies to log in to a system.||Credentials are basically the same thing.|
|Single sign-on (SSO) enables a person to log in once and access other apps and services without logging in again.||Social sign-on enables a person to log in to an app using the credentials established with a social account like Google. That app accepts the Google credentials, and the user doesn’t have to create another account and password.|
|Identity provider is a trusted service that enables users to access other websites and services without logging in again.||Service provider is a website or service that hosts apps and accepts identity from an identity provider.|
Now let the fun begin! Have you had enough of concepts and definitions? Let’s put some of what you’ve learned into action. Later in this trail, you’ll set up security features in your Salesforce Dev org.