SAML and Delegated Authentication
Apex Single Sign On
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.
As an update as of Summer 08 we do support SAML 1.1 Browser Post Profile for web based access. As this note says though, we still have issues with SAML and the API. So browser access only for SAML today. You can use SAML and a password at the same time. This way the password can be used for API and SAML for web. The password can use Delegated Authentication or use the standard salesforce.com password store.
Why Delegated Authentication
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.
Posted by Benji Jasik on July 25, 2005 at 10:11 AM in Security | Permalink
Comments
Q. 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?
A. Two Solutions:
1/ InfoCard system. Windows will help you selecting the InfoCard and hence and the client application will know whom to talk to get the SAML token.
2/ You can write your client in such a way that before doing the invocation of web service it retrieves its policy & metadata and there lies the information which identity provider to invoke to get the SAML token.
Regards Kapil
Posted by: Kapil Sachdeva | Aug 24, 2005 7:49:34 AM
for 2/ how does it know where to get to get its policy & metadata from? AFAICS this is the same issue just with an extra step.
Posted by: Simon Fell | Aug 24, 2005 10:16:58 AM
You might be interested in this ISTR Journal article about how company (Vordel) and our partner Entrust provided a joint Web and Web Services authentication solution for a customer. The solution uses WS-Trust RST (Request Security Token) messages to request SAML tokens from a STS (Security Token Service).
This solution has been in production usage for over a year now.
The jouirnal article includes examples of all the SAML and WS-Trust messages used. To read the journal article in PDF or text, go to http://dx.doi.org and insert the following document ID: doi:10.1016/j.istr.2005.02.002
In answer to your specific question: In this customer rollout, the security token requester (in this case our VordelDirector product) was pre-configured to know the address of the STS (in this case Entrust's GetAccess product). There was also a seperate trust context between the requester and the STS. As Simon Fell points out, putting a "metadata-exchange" step before the WS-Trust step would have simply pushed the problem back one step. All of the implementations of "metadata lookup" schemes which I have seen so far have had a proprietary element to them for the initial "discovery" piece.
I'd be happy to talk more about the solution - send me an email if you like. We covered a lot of practical ground and addressed a lot of issues which realistically are only addressed in customer rollouts like this.
Posted by: Mark O'Neill | Oct 5, 2005 10:58:20 AM
If you configure ASP.NET authentication to use Windows authentication and you enable impersonation, ASP.NET will impersonate the user represented by this security token.
Posted by: Sarah | Jan 6, 2006 11:29:10 AM
Article reproduced from Apex Blog Here