Now it is so simple to use OpenSSO as an Identity Provider to SSO with Salesforce.com applications using the SAMLv2 protocol. Out of the box OpenSSO supports an easy to use work flow feature that enable the customers to integrate salesforce.com applications to their existing authentication infrastructure.
There are multiple ways to achieve the SSO with Salesforce.com, the IDP users’ attributes can be sent to SP
- As an attribute statement in the SAML assertion
- As an nameId element in the SAML assertion subject statement
In the same manner SP at the salesforce.com can use two options to which of its local attribute used to perform the SSO, it can be one of these
- Salesforce.com user’s Federation ID attribute
- Salesforce.com user’s user id
In this example I am configuring the IDP to send the attribute value as an attribute statement in the SAML assertion. The SP salesforce.com configured to use Federation ID attribute to match the IDP user’s attribute
2.0 Create circle of trust (COT) in the IDP(OpenSSO)
To start with create a COT in the OpenSSO, you can leave empty on the attribute mapping part, this is optional. Your Salesforce.com application will be the SP that would be part of this COT.
once the COT is created in the OpenSSO, you would see an option to configure Salesforce CRM application, click on that to continue the process.
3.0 Configure OpenSSO meta data for Salesforce.com CRM Application
Once you click on the configure salesforce CRM application link then you will be guided to create a attribute mapping of your IDP (OpenSSO) user attribute value that will be mapped to the salesforce.com CRM application users’ Federation ID attribute, this is the critical piece of information to achieve the SSO. In this example I am going to send IDP users’ telephoneNumber as part of the assertion so the users at the salesforce.com could use this information to perform the SSO. Essentially SAMLv2 SSO will be successful if the authenticated(at the IDP) identity’s telephoneNumber matches uniquely with a user’s Federation ID attribute at the salesforce.com application domain.
in this case the attribute ‘telephoneNumber‘ is passed on to SP(salesforce.com) inthe assertion statement as ‘ATTR_PHONE‘, value of this attribute will be picked up and matched with one of the salesforce.com user’s Federation ID attribute, a match would mean a successful SSO.
At this point you will be shown with a certificate value which needs to be exported to the salesforce.com domain, in turn a login URL that would be provided by the salesforce.com domain would have to be loaded in to the OpenSSO.
the following image shows the certificate presented by the OpenSSO server
4.0 Configure the SP Side(Salesforce.com)
You need to logon to salesforce.com as an admin user to perform this step. Basically the certificate from OpenSSO server needs to be loaded in to the Salesforce.com domain, besides this there are few configurations needs to be updated.
as you can see the attribute ATTR_PHONE is being mapped to the local Salesforce.com users attribute.
Once you save the above information, there will be another screen would appear some thing like this
The steps 3 and 4 are kind of interdependent and parallel, I have broken it up in to steps for readability.
5.0 Configure the users in IDP and SP
In order to successfully verify the SAMLv2 SSO you need to configure atleast one user in each provider side.
at the OpenSSO IDP side , I am using the default ‘demo’ user , for this I have updated the telephoneNumber attribute of ‘demo’ user to match with the salesforce.com users’ Federation ID.
User at the OpenSSO:(IDP)
User at the SP side(Salesforce.com)
6.0 Verification of SSO
NOTE: Currently this task is being implemented, this feature will be available soon.
One can verify the SSO by manually by using the following url
Steps two through five completes the configuration of SSO between OpenSSO and Salesforce.com. Now you can verify the SSO between these two entities using the common task in the OpenSSO ‘Test Federation Connectivity’.
Login as amadmin to the OpenSSO console, click on Test Federation Connectivity’ under common tasks tab. Now you will be viewing the COT that you have created in step 2. Click on this then you would see the SP and IDP URLs.
Now click on the Start Test button, this will walk you through the sequence.
once you enter the user ‘demo’ with password ‘changeit’ , you should be seeing the salesforce.com page, if not SSO did not go through.
The IDP side attribute is passed in the SAMLv2 assertion
<saml:NameID Format=”urn:oasis:names:tc:SAML:2.0:nameid-format:transient” NameQualifier=”http://cal2.red.iplanet.com:33030/opensso” SPNameQualifier=”https://saml.salesforce.com”>Fg+lA6Qd/7zoMgCGeXlpo7y2Mm+b</saml:NameID><saml:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”>
<saml:SubjectConfirmationData NotOnOrAfter=”2009-08-08T20:57:55Z” Recipient=”https://login.salesforce.com/?saml=MgoTx78aEPduTIxbWh0K.a290YU8eQKCDWk6.coqPw5O5NdayLNHlFttA6″/></saml:SubjectConfirmation>
</saml:Subject><saml:Conditions NotBefore=”2009-08-08T20:37:55Z” NotOnOrAfter=”2009-08-08T20:57:55Z”>
<saml:AuthnStatement AuthnInstant=”2009-08-08T20:47:54Z” SessionIndex=”s29811cf51ac0d7b19030e5936ac12a389e01ca401″><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute Name=”ATTR_PHONE“><saml:AttributeValue xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:type=”xs:string”>888-786-2786</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>