Can Federation help solve the SaaS phishing issue?

Most people are aware of the recent security issues that SalesForce.com are facing as a result of the successful phishing attacks against them (more here). I am expecting that this will be the straw that finally breaks the back of the SaaS market as they come to understand that secure internet SSO via federation is not a ‘nice to have’ but a ‘must have’.

One of the attack vectors that make a phishing attack possible is a public web form available on the internet that collects user credentials. Phishers make a look-alike form and get a user to submit their real credentials to the fake form and then take those credentials and submit them to the real form to get access to the phished users data.

IdP initiated federated SSO eliminates the need to put a web form out on the internet to collect credentials. In this model credentials are collected at an internal enterprise site and then federated over to the SaaS vendor - so there is no public web form to use to trick users. Generally speaking in this model the user always accesses the SaaS provider from a link on their corporate intranet portal.

From discussions we have had with a number of different SaaS vendors we have realized that IdP-initiated federation is too restrictive. These SaaS vendors want to support roaming users who may not be always connected to the company intranet (e.g. the salesforce), as well as access from ‘deep’ links such as bookmarks or URL’s contained with email messages.

This is where SP-initiated federation (optionally using email address based IdP discovery) comes into play. In this model an unauthenticated user can start at the SaaS provider, be redirected to their corporation for authentication and then be returned to the SaaS application with a SAML token that gives them access. SaaS customers will have to make their employee authentication service available on the Internet much like they do with employee remote access. In this case the risk of phishing attacks against a specific SaaS vendor is distributed across their customer base. Every organization’s externally facing login web form will be different and can even incorporate stronger authentication as necessary. In the future I imagine that a SaaS customer could even go one step further and outsource their authentication process to a SaaS provider specializing in strong authentication and identity verification.

One last area of feedback we have received is in relation to SaaS plugins for desktop software such as mail, calendar, browsers and IDE’s. The use of these plugins also requires authentication and generally means the use of a password that is quite often cached in the plugin after first use. SaaS providers don’t consider federation to be providing the whole solution until these plug-ins are also supported. Fortunately the SAML 2.0 specification includes the ECP (Enhanced Client/Proxy) SSO profile that can be used to address this problem. I will blog more about how we are planning to use ECP to solve this specific use case.

As far as I can tell there should be no reason that every SaaS provider should not be striving to eliminate passwords from their environment entirely. As can be seen by the issues Salesforce.com is currently facing, the cost and risk of supporting user passwords has risen significantly and will continue to do so. From a SaaS perspective, our goal at Ping is to make Federation so easy and cost effective to setup and administer that it is not worth looking at any other alternative authentication scheme.