keytool -import -file salesforce_idp_cert.cer -keystore jbid_test_keystore.jks -alias salesforce-idp
In this part, we will use Salesforce as IDP and sample application from Picketlink as SP.
NOTE: Integration is working from Picketlink version 2.1.2.Final and newer
Disable Single Sign on in SSO settings if you enabled it previously. As in this step, we don't want to login into Salesforce through SSO but we want Salesforce to provide SSO for us and act as Identity Provider.
Identity provider setup - In link Setup -> Security controls -> Identity provider you need to setup Salesforce as IDP.
Generate certificate - first generate certificate on first screen. This certificate will be used to sign SAMLResponse messages sent from Salesforce IDP.
After certificate will be generated in Salesforce, you can download it to your computer.
Configure generated certificate for Identity Provider - In Identity Provider setup, you need to select the certificate, which you just generated
Add service provider - In section Setup -> Security Controls -> Identity Provider -> Service providers you can add your Picketlink application as Service Provider. We will use application sales-post-sig from Picketlink quickstarts.
So in first screen of configuration of your Service provider, you need to add ACS URL and Entity ID like http://localhost:8080/sales-post-sig/. Subject type needs to be Federation ID and you also need to upload certificate corresponding to signing key of sales-post-sig application. You first need to export this certificate from your keystore file. See previous tutorial for how to do it.
In next screen, you can select profile for users, who will be able to login to this Service Provider. By checking first checkbox, you will automatically select all profiles. After confirm this screen, you will have your service provider created. Let's see how your final configuration can looks like after confirming:
WARNING: As mentioned in previous tutorial, you should create your own keystore file for Picketlink and not use example keystore jbid_test_keystore.jks and certificates from it in production environment. In this tutorial, we will use it only for simplicity and demonstration purposes.
As already mentioned, we will use sample application sales-post-sig.war from picketlink quickstarts.
Import salesforce IDP certificate - In sales-post-sig.war/WEB-INF/classes you need to import downloaded certificate from salesforce into your keystore. You can use command like:
keytool -import -file salesforce_idp_cert.cer -keystore jbid_test_keystore.jks -alias salesforce-idp
Identity URL configuration - In sales-post-sig.war/WEB-INF/picketlink.xml you need to change identity URL to something like:
<IdentityURL>${idp-sig.url::https://yourdomain.my.salesforce.com/idp/endpoint/HttpPost}
ValidatingAlias configuration - In same file, you can add new validating alias for the salesforce host of your domain:
<ValidatingAlias Key="yourdomain.my.salesforce.com" Value="salesforce-idp" />
Roles mapping - Last very important step is mapping of roles for users, which are logged through Salesforce IDP. Normally when you have Picketlink as both IDP and SP, then SAMLResponse from IDP usually contains AttributeStatement as part of SAML assertion and this statement contains list of roles in attribute Role . Picketlink SP is then able to parse list of roles from statement and then it leverages SAML2LoginModule to assign these roles to JAAS Subject of logged principal.
Thing is that SAML Response from Salesforce IDP does not contain any attribute statement with roles, so you need to handle roles assignment by yourself. Easiest way could be to chain SAML2LoginModule with another login module (like UsersRolesLoginModule for instance), which will ensure that assigning of JAAS roles is delegated from SAML2LoginModule to the second Login Module in chain. Needed steps:
In sales-post-sig.war/WEB-INF/jboss-web.xml you can change security-domain from value sp to something different like sp-salesforce
<security-domain>sp-salesforce</security-domain>
Create new application policy for this security domain. It differs in each application server, for example in JBoss 7 you need to edit JBOSS_HOME/standalone/configuration/standalone.xml and add this policy to particular section:
<security-domain name="sp-salesforce" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="users.properties"/> <module-option name="rolesProperties" value="roles.properties"/> </login-module> </authentication> </security-domain>
In sales-post-sig.war/WEB-INF/classes you need to create empty file users.properties and non-empty file roles.properties where you need to map roles. For example you can add line like:
tomcat=manager,employee,sales
where tomcat is Federation ID of some user from Salesforce, which you will use for login.
Now after server restart, let's try to access: http://localhost:8080/sales-post-sig/ . You should be redirected to salesforce login page with SAMLRequest sent from your Picketlink sales-post-sig application. Now let's login into Salesforce with username and password of some Salesforce user from your domain (like tomcat user). Make sure that this user has Federation ID and this Federation ID is mapped in file roles.properties on Picketlink SP side like described in previous steps. Now you should be redirected to http://localhost:8080/sales-post-sig/ as logged user.