+ Start a Discussion

saml in delegated authentication

Hi all,
  could someone explain better how SAML assertions fit in with the delegated authentication scheme that Salesforce has? The article I found here (http://wiki.apexdevnet.com/index.php/How_to_Implement_Single_Sign-On_with_Salesforce.com) talks about tokens and how SAML tokens can be used. That is where I get confused. Is the token generator something that we have to implement? How do I know what to put in the SAML assertions? 
And also, complete SAML support for SSO is available for the summer 08 release and I was wondering if there any articles like the one above for that.
Thanks in advance. 
In the delegated authentication model, the password carries an authentication token instead, this can be anything that you can later use to verify the authentication, you can use a standard token such as a kerberos ticket, saml assertion etc, or a home grown token using some form of crypto. The important peice is that your listener can validate these tokens as being issued by yourself.

When the token comes from, and later how you verify it, is upto you, you may have existing infrastructure/products that'll generate a saml assertion for you. (or you can just go buy one of the partner products that handle all this for you)

The new SAML support provides for a saml specific entrypoint into the salesforce.com web ui, and follows the standard saml profiles for how that's done. (i.e. this should work with your saml generator product out of the box, where the delegated auth system will not).
So is the new saml support for salesforce the same as how google apps does saml support as well, since you say that salesforce follows the standard profile for SSO (I'm pretty sure google follows the standard profile). I find this hard to believe. There are so many places where there can be differences between the communication that google and salesforce does with the identity provider. For example, google's authentication request in saml assertion format is this:
<?xml version="1.0" encoding="UTF-8"?>

You can see that it gives an ID, issue instant, provider name and acs url attributes. Is this the exact same attributes that salesforce sends to the identity provider as well? I need to know this because I, as the identity provider, need to know what to look for with the saml requests that I get. For example, google uses the AssertionConsumerServiceURL tag to specify the ACS url. But the saml standard specifies another tag (AssertionConsumerServiceIndex) that can be used to do the same thing. Which tag do I account for? There are other places like this where the tags differ. For example, google uses DSA/RSA keys to sign the response but the saml standard uses something else. The service provider can use 4 different SAML bindings as well, and we don't know what salesforce uses. There are specifics like this that we don't have any information on. Am I just thinking too hard about this? Is there some easy (or easier) way I can go about implementing SSO using the new SAML support?

Login to the app, click help, search for saml.
We currently support SAML 1.1 Idp-initiated Browser-Post Profile.  It's interoperable with many Identity Providers out there.  So you authenticated to the Idp first, then Idp will generate an auto-post form contains the SAMLResponse to Salesforce.

Jong Lee


Hi Simon, Jonglee


Could you please assist me with my issue posted at : http://boards.developerforce.com/t5/Security/SSO-Implementation-from-App-A-to-Salesforce-and-Salesforce-to/m-p/327999


It is related to SSO Implementation between App A, Salesforce and then App B.