More and more vendors are taking what they classically sold as an on premise solution and delivering their applications via the cloud.  While this makes a lot of sense both for the vendors as well as their customers, it does introduce a problem with authenticating users.  With the on premise solutions, they likely used Windows Integrated authentication for web applications to seamlessly log the customer’s users into their web application or they simply authenticated using the customers on premise Active Directory.

Identity Federation and Single Sign-On (SSO)

Now that the web applications are hosted in the cloud, how do these cloud applications authenticate the users?  One answer is to create separate user accounts and passwords into the cloud application. This works, but is not user friendly because users now have another account and password for each cloud application.  With a Single Sign-On (SSO) approach, the user is able to use their existing corporate credentials to access the cloud applications without requiring separate accounts for each application. The industry standard to provide this Single Sign-On is known as Federation or Identity Federation.  Identity Federation is where two organizations establish a trust between two security realms.  A federation server on one side (Identity Provider or IdP) is responsible for authenticating the user and issuing a token.  A Federation server on the other side (Relying Party or RP) accepts the token and validates the token containing the identity of the authenticated user.  A rely party (RP) is the term in Federation for the cloud based application that the end user is accessing. IP-RP graphic When the user attempts to access the cloud application (RP), the user is redirected back to their company’s IdP to authenticate with their existing corporate credentials.  This setup provides controlled access to applications by authenticated users without requiring the user to have another account and password within the cloud application.

Protocols, Trusts, Certificates, Assertions, Encryption, Signing, Oh My!

Now that we’ve determined that Federation is the right solution, the only thing left to do is build Federation support into the cloud SaaS application, right?  The answer is not that simple.  While Identity Federation is built on open standards there are many moving parts. Identity Federation is simply the broad term for how the single sign-on is performed. The first item that must be decided and agreed upon by both the IdP and the RP is what protocol to use.   Think of the protocols as different languages.  In Federation the most common standards are WS-trust, WS-Federation, SAML 1.0, SAML 2.0, and Shibboleth.  As an application vendor are you going to add support for all of these so that customers can choose the protocol they want to use? The complexities continue with having to decide technical details such as what data elements should be sent in the assertion, the details around signing and encryption, as well as the trading of SSL certificates.  Things get even more complicated if the customer does not have a certain data element you need or have it stored in attribute named something different. All of these items needs to be ironed out for each and every federated trust with a new customer.   That, however, is not the biggest issue.  The biggest issue is the ongoing and growing cost to continue to maintain and grow an increasing infrastructure of a Federation service.  As you add new customers, you add additional cost and maintenance of your service.  Beyond server maintenance, patching, and monitoring, certificate maintenance is a huge manual task in and of itself.  Certificates often have an expiration of 1 to 2 years, at which time new ones need to be manually generated and traded between IdP and RP. federated trusts graphic Simply put, you are no longer just in the business of what your cloud application does. You are now in the Federation business, running a global authentication service that is continuously growing both in complexity as well as cost. The good news is that it doesn’t have to be that way… Find out how you can get out of the authentication business in next week’s post, “Get Out of the Authentication Business (Part 2)” and download the Optimal Cloud for Cloud Based Application Vendors whitepaper today.  


  • The database in which all of your organization’s sensitive identity data is stored.
  • A digital ledger in which digital transactions are recorded chronologically and publicly.
  • Securely managing customer identity and profile data, and controlling customer access to applications and services.
  • The means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.
  • A legal framework that sets guidelines for the collection and processing of personal information of individuals within the EU.
  • The policy-based centralized orchestration of user identity management and access control.
  • An authentication infrastructure that is built, hosted and managed by a third-party service provider.
  • A security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction.
  • A global provider of innovative and affordable identity access management solutions. 
  • Managing and auditing account and data access by privileged users.
  • Tools and technologies for controlling user access to critical information within an organization.
  • An authentication process that allows a user to access multiple applications with one set of login credentials.