Friday, December 4, 2009

Implementing Single Sign-on with SalesForce.com

Getting single sign-on to work with Salesforce.com is pretty straightforward. They support both SAML 1.1 and now 2.0 formats using IdP-initiated POST Bindings. ADFSv2 Beta 2 currently does not support IdP-initiated SSO; although, from what I’ve heard will in RTM. So do get this working, you can do this through a custom STS.

All SalesForce.com requires is the Username or Federation ID to be passed as an assertion within the SAML token. This can be presented in either the Subject or as an Attribute value. The simplest method is to do it through the subject. On the Saleforce.com side, the federation single sign-on using SAML settings should be:

  1. SAML Enabled: yes
  2. SAML User ID Type: Username
  3. SAML User ID Location: Subject
  4. SAML Version: 2.0
  5. The public key of your Token Signing Certificate needs to be uploaded for validating token authenticity

Salesforce.com provides a validation tool to compare your generated SAML Response against the SSO settings on their server. This is pretty helpful in working through errors.

Getting a properly formatted SAML Response is probably the most important key for federated authentication to work. If there is something not standard or funky in the token, the STS that attempts to consume it will likely throw an error.

Below is a working SAML 2.0 token we’re using for Salesforce.com (note that I’ve removed my signature information):

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination=
https://login.salesforce.com ID="fhlaclpimfkgkjpbdijjcjahbhbldojhekcojnog" IssueInstant="2009-12-04T09:52:35Z" Version="2.0"><Signature xmlns="http://www.w3.org/2000/09/xmldsig#">……</Signature>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">mycompany.com</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="baofcgcmpmmekakjkkbomfbefcfdljgbkbdifohm" IssueInstant="2009-12-04T09:52:35Z" Version="2.0">
<saml:Issuer>mycompany.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">ccalderon@mycompany.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2009-12-05T09:52:35Z" Recipient=
https://login.salesforce.com />
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2009-12-04T01:52:22Z" NotOnOrAfter="2009-12-05T09:52:35Z">
<saml:AudienceRestriction>
<saml:Audience>
https://saml.salesforce.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2009-12-04T09:52:35Z">
<saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="ssoStartPage" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xmlns:xs="
http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">https://localhost/SalesForce.SSO/SSOLogin.aspx</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="logoutURL" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xmlns:xs="
http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">https://www.salesforce.com</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

2 comments:

Unknown said...

I thought that SF.com supported SP-initiated SSO and SAML 2.0 now. Any ideas on how to setup that scenario?

- said...

There was one thread on their forum that hinted in SP-initiated SSO and I would have preferred an SP-initiated if I could, but from what I know they only support IdP-initiated. Referencing the OpenSSO stuff online, they also use IdP-initiated and speaking with anyone from SF, there wasn't anyone that led me to believe otherwise. We're using the current seasonal version too. If I hear something, I'll post it.