There's been some recent discussion on SXIP's decision to build hardware to support Salesforce.com's delegated authentication protocol.  Delegated authentication is a process where Salesforce makes a secure web services call to an endpoint that a customer defines.  Salesforce can delegate authentication to the customer, which can allow for building web single sign on, integration with two-factor, integration with an LDAP directory, and many other possibilities.

What hasn't been discussed is why Salesforce is using a delegated authentication scheme, rather than just accepting SAML tokens.  So why'd we do it?

Supporting SAML on our website would have been easy.  But we have a huge amount of our traffic that doesn't come to our website, but to our Sforce web service APIs. 

We have an outlook plugin, a plugin for word and excel (office edition), an offline edition, and a wireless edition.  We also have many partners who have build products on top of our APIs.  An example we like to use is access Salesforce on a Blackberry.  We have a number of partners who have successful products to allow customers to access Salesforce on a Blackberry.

How do the clients, which all use web services to authenticate (using login and password today calling our login call), know where to get the SAML token from, in a standard way?  There is no standard way to do this today, and even standards like WS-Trust don't seem to solve this problem.  For example, you build a client using our web services apis.  You deploy to all our customers.  Customer A has one SAML provider.  Customer B has another SAML provider.  How does your code know where to go to get the token when deployed at customer A and at customer B, without configuring all of the clients with the location of the SAML provider? 

We suggest customers can use web single sign on, and a shared password for the clients.  So when I login through the web, a SAML token can be passed through.   When I use the web services-based clients, I use my Active Directory password.  This is a simple solution

For our customers, a hardware based solution is a no-brainer.  It's simpler to deploy, and less to maintain on their end.

We'd love to hear how others are thinking about solving the web + web services authentication problem, when there can be an unlimited number of clients that need to authenticate against your service.

Interesting comments from Craig Burton, Kim Cameron & Marc Canter on the Sxip identity appliance (which supports delegated authentication and Single Sign On for salesforce.com), and the follow up from Sxip. I think it totally makes sense to offer this as an appliance, that's one less server for your overworked and under resourced IT department to have to manage.

Some users get tripped up because their organization has a security policy to cause users to reset their passwords every X days.   After 60 days of the integration working, it fails, because the user got locked out of their account!

If you have an integration user, you have a few options

Your first option is to change your password programmatically when it expires.  LoginResult will come back with the PasswordExpired flag = true, and returns a sessionId that is only good to use the setPassword call.

Another option is a flag on the profile to allow passwords to never expire, called Password Never Expires.

If you plan to enable password never expires we recommend you also lock down access for this integration user by IP ranges.  Use the IP range restriction feature on profiles.

Note that if your organization does not have a security policy to reset passwords every X days, this will not be a problem for you.