What is SINGLE-SIGN-ON & FEDERATION?

Let’s look at the difference between Single Sign-On and authentication…...

Basically, authentication is what we have to do to determine who you are and Single Sign-On is the result you get from it.

So you sign on once and that Single Sign-On gives you access to all of the applications that you’ve got access to.

Ex: Consider that there are 3 apps, each app pops up a sign-on and a possible sign-on for each app with proper sign-on methods, and it is authenticating. But in that case, you are not getting a one time experience.

And Single Sign-On, allows the user to log in once and access each app without re-entering authentication factors. you own all these apps. Within your enterprise and you can probably achieve Single Sign-On across it and get that efficiency.

“But there are situations where your enterprise also speaks to partner apps.🧐👀”

Let’s see what this is and what concepts we can use efficiently….

Assume, you have a new requirement that web application must be accessed by the users from some other partner organization. Partner organization has their employee’s user accounts in salesforce SAAS applications. Users from partner organizations who need to login to the web application must be authenticated with their user account in salesforce.com. How we are going to achieve this?

Essentially, we do is sign up with the ID server to know who you are, and we’re using that identity talk to salesforce. And it’s telling them who you are.

This is basically called the Federation.

With Identity Server, you can configure multiple IDPs that users can be authenticated. In this use case, users from its own enterprise can be authenticated with the enterprise user store. And users from a partner organization can be authenticated with salesforce.com.

The other important thing is whether we use any standard with this concept???

Yes, of course,

With this example, Salesforce adheres to an identity standard called SAML 2. Our Identity provider also should adhere to that. So utilizing the standard protocol we’re able to tell Salesforce. This is the user XYZ. You don’t have to worry about checking. I’ve already checked and I know who it is. You can give him access.

The whole scenario is also, basically, it’s kind of standard-based Single Sign-On.

But again, we have our doubts, which “Do we give our own credentials to the Salesforce”???

NO, WE DO’'NT

Actually, it’s not telling Salesforce how an Identity provider determines who you are. It’s telling it who you are.

During authentication, credentials provided by the user and maps that to a particular set of attributes in the identity store related to the authenticated user.

Then Federation takes one or more of those attributes and sends them to Salesforce.

The important thing is, Federation provides some kind of trusting relationship because as an employee I can protect my anonymity in order to gain access to that service.

In the Last Part, you can see there are a lot of standards for doing federation. Let’s go through some of the more popular standards.

SAML 2 — The Security Assertion Markup Language (SAML), is an open standard that allows security credentials to be shared by multiple computers across a network. It’s got a lot of security the aspect around it.

OAuth 2.0 — OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

OpenID Connect — OpenID Connect has become the leading standard for single sign-on and identity provision on the Internet. Its formula for success: simple JSON-based identity tokens (JWT), delivered via OAuth 2.0 flows designed for web, browser-based and native / mobile applications.

Shibboleth — Shibboleth is a single sign-on log-in system for computer networks and the Internet. It allows people to sign in using just one identity to various systems run by federations of different organizations or institutions. The federations are often universities or public service organizations.

Finally, we get some idea about SSO & Federation,

And also one thing important, Standards-based Single Sign-On which helps us not only have a single standard in our own enterprise but also with partner services as well across to other enterprises. That means these standards are associated with the Federation also.

With this, we just take Salesforce as an example scenario, as well as we have there are many scenarios for the federation,

Ex: Google apps, Facebook, Yahoo, Microsoft Windows Live, etc…...

Thanks 😊…...