Believe it or not, we federate every single day in the real world.  The whole concept of federation is that a "service provider" trusts the "identity provider".  In the case of federated single sign on in the enterprise, this means that Salesforce.com (the service provider) trusts Active Directory (the identity provider) and allows you access.

In the real world, the best example is your driver's license.  When you present your driver's license to the bank to prove that you are you, the bank (service provider) is trusting that the DMV (identity provider) has properly vetted you with birth certificates, social security cards, or other identity information.  Because of this trust, or federation, you don't have to carry all of these documents with you everywhere and prove to every single person that you are you.  They trust the DMV (or whatever institution in your country provides driver's licenses) to have taken the appropriate steps to prove your identity.

Don't get me wrong, IT systems are the real world.  And you just need a mechanism to trust your identity provider.  And something akin to a driver's license.  Thankfully, we have several standards that act as a driver's license: SAML, OAuth, OpenID, WS-Trust and WS-Federation. 

When a user authenticates into the service provider (in this case Salesforce.com), Salesforce.com asks for ID.  Since the application is federated with empowerID, the user doesn't have to pull out all of her identity documentation, she just needs the driver's license, in this case a SAML token.  Reaching into her wallet (actually the secure token server in empowerID), she pulls out her SAML token (actually, empowerID sends it to the service provider) and presents it as evidence that she is who she says she is and should have access to the application.

Since Salesforce.com trusts the identity provider and hence the SAML token, the user is authenticated and allowed in to the application.  No username and password (analagous to the mess of identity documents like birth certificates, etc) or difficulties in signing in.

There are other Federated Single Sign On Scenarios (this is scenario number 1, corporate login to cloud application).  But in each one, consider the SAML token (or other protocol) to be the driver's license.  Your user presents this token as identity proof to the bank teller or airline ticket representative or retail clerk and that person (service provider) trusts that you are who you say you are and lets you in.

Once you have this capability, it is easy to trust partners, customers, contractors, and other entities inside or outside of your organization and offer them single signon.  Imagine you are a book publisher who wants to sell books and offer other service options to consumers, authors and editors in an external portal. 

You won't get very far if you are forcing them to re-enter passwords and user names for each application.  Once you authenticate them once against empowerID (your identity provider), they are federated into every single one of those applications.  And the best part is that unlike the real world, they only have to reach into the secure token service once for that SAML token, it moves along with them presenting itself every time they hit a federated application.

Take a look at our whitepaper and see if any of these scenarios apply to you and let's make federated single sign on a real world solution for you.  Click the button below to download your copy of the whitepaper.