Learn the Language of Identity

Learning Objectives

After completing this module, you’ll be able to:

• 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.
  

Identity Standards and Protocols

Hard to believe that you can keep your users’ identities secure when they don’t have to sign in to external websites or apps? How can so many companies’ products, even competing products, work together?

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.

• SAML
  
• OAuth 2.0
  
• 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). Security Assertion Markup Language (SAML) is the protocol that makes it happen.

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.
  

SAML Assertion

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.

OAuth 2.0 Protocol

OAuth (Open Authorization) 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 that 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.

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—as Amazon and PayPal do, 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.

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.

SAML Flow for SSO

For the curious, the following diagram shows how SAML communication flows during the SSO process. This is what’s happening under the covers. Don’t worry if you’re not interested in peeking. It’s not in the test.

The SSO process all happens with lightning speed, but a few steps are involved.

1. The user tries to access Salesforce.
   
2. Salesforce recognizes the SSO request and generates a SAML request.
   
3. Salesforce redirects the SAML request back to the browser.
   
4. The browser redirects the SAML request to the external identity provider.
   
5. The identity provider verifies the user’s identity and packages the SAML assertion containing the user authentication.
   
6. The identity provider sends the SAML assertion to the browser.
   
7. The browser redirects the assertion to Salesforce.
   
8. Salesforce verifies the assertion.
   
9. The user is now signed in and can access Salesforce.
   

Identity Terminology Cheat Sheet

How’s that for a crash course on the topic of identity protocols? When words sound similar and differences are nuanced, it can be hard to keep them straight. So here’s a cheat sheet. Hope it helps!

What’s Next?

You’ve had a whirlwind tour of industry standards for identity access and management. Don’t worry if it’s hard to keep them straight. For now, just remember that Salesforce Identity uses protocols to implement its features.

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.

Resources

• Salesforce Help: SAML SSO Flow
  
• Salesforce Help: Identify Your Users and Manage Access