Monday, July 25, 2005

Interesting post at sforce

Benji at had an interesting post today on the sforce blog. Here's the juicy part:

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?

Benji raises some excellent points here...he's effectively pointing out the issue of discovering a security token service. What makes this complicated is the security token service in many of Sxip's customers is on a private network, and customers don't wish to expose the url to the general public. An anonymous discovery service either can't personalize the response to either customer a or b, or you end up exposing sts endpoint locations inside customer a or b.

Anyone have any ideas on this tricky problem?


Anonymous said...

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.


cmort said...

Thanks for the comments!

Infocard has potential, but at the moment, we've got a ways to go before its a viable approach.

In terms of meta-data exchange, we'd need this to be relative to the identity of the invoker, so the client would at least need to emit the salesforce org in which the user resides. The policy would need to be dynamic based upon that.