Friday, 30 November 2007
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.
1. User attempts to access a resource at the SP and is prompted for their email address as an identifier (this is likely their corporate email address).
2. User is redirected to the SP federation server with domain name as a query parameter.
3. SP federation server checks domain name against white list to determine if this is a trusted SSO-enabled IdP.
4. SP federation server retrieves and caches signed meta-data file from IdP at the URL expressed by the IdP’s entityid - http://saml.idp-domain-name.com. The metadata contains the IdP's certificate, the SSO Service endpoint and optionally single logout endpoints. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the IdP matches the signing certificate DN.
5. SP federation server redirects user to IdP SSO URL with signed AuthNRequest.
6. IdP federation server checks white list using domain name from Issuer field in AuthNRequest.
7. IdP federation server validates the AuthNRequest. The federation server retrieves and caches signed metadata file from SP at the URL expressed by the SP’s entityid - http://saml.sp-domain-name.com. The metadata contains the SP's certificate, the Assertion Consumer Service endpoint and optionally single logout endpoints and attribute requirements. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the SP matches the signing certificate DN.
8. IdP authenticates user.
9. IdP federation server creates SAML Assertion containing users email address (and other optional attributes) and uses the SAML Post Binding to redirect the user back to the SP.
10. SP federation server validates the SAML Assertion (including verifying the signature over SAML Response) and checks its white list using the domain name from the Issuer field in the SAML Response.
11. The SP generates the local session cookie and redirects the browser to the requested resource.
