Thursday Jul 02, 2009

SAML 2.0 SSO with Salesforce.com CRM


SAML 2 support is available since Winter 09 Release. OpenSSO console team is in the process of building a cool task flow for this, which will significantly reduce the number of steps listed here. Look out for it in Build 12.

Prerequisites:
  • For each OpenSSO user that needs to access Saleforce.com, choose a user profile attribute to map to a Saleforce.com user. We will call this the "federationID". Note that this value should be unique for each user. As an example we will use the OpenSSO email profile attribute (mail). Also note that for obvious security reasons the identified profile attribute must be changeable by authorized administrators only, ie it should not be changeable by the user. Please refer to OpenSSO Delegated Admin feature to set up appropriate privileges.
  • Decide the exact SAML attribute name the IDP will populate the "federationID" with.
  • Setup up OpenSSO IDP with xml signing turned on. Note the provider id of the IDP configuration. In my setup it is : http://sa.idp.com:8080/sa
  • Export the OpenSSO (IDP) public key to a file
    For example, if your OpenSSO IDP uses the out-of-the-box test certificate, execute the following in a terminal on the box hosting the OpenSSO server:
    $ cd <openssoconfig_dir>
    $ keytool -export -keystore keystore.jks -alias test -file cert.cer
    <openssoconfig_dir> is the base bootstrap directory you specified during OpenSSO installation.
Salesforce.com end :
  • Login to http://www.saleforce.com as admin user.
  • Navigate to Setup->Security Controls->SingleSignOn Settings. Enable SAML and fill up the dialog presented.
    • Select version 2.0
    • Import the IDP certificate - in my setup I entered cert.cer file saved in Prerequisites steps above.
    • Enter fields that tell Salesforce.com how the authenticated user is identified in the SAML assertion from the IDP. In my example I specified mail saml attribute. Note that this must match exactly the OpenSSO setup described in "OpenSSO end" steps below.
    Saving the configuration displays a generated Salesforce.com login url such as the following :
    Save this url string - it will be needed while configuring OpenSSO service provider.
  • Navigate to Setup->Manage Users->Users For each user enter the FederationID value corresponding to the OpenSSO profile attribute chosen. In my setup chose a user setup its FederationID to "demo@example.com" :

Configuring OpenSSO end
  • If not already created, login to OpenSSO console and create a Hosted Identity Provider either via the Task flow or other means. Make sure you choose the "Sign Assertion" option and specify a certificate to use for signing. OpenSSO comes with a default "test" certificate.
  • Provision the "federationID" value for each user that needs access to Salesforce.com. As an example - login to OpenSSO console as amadmin, navigate to RootRealm->Subjects->demo and setup the demo user's Email attribute as demo@example.com:
  • Create a new Service provider representing Saleforce.com
    • Login to OpenSSO console as amadmin
    • Download enclosed salesforceSPMetadata.xml
    • >Start "Create hosted SP" task flow
    • Import salesforceSPMetadata.xml metadata (Optionally : specify the URL from this blog :
      http://blogs.sun.com/rangal/resource/salesforceSPMetadata.xml
      directly in the task flow field)
    • Navigate to Saleforce.com service provider created in the last step, select Services tab and enter the salesforce.com URL obtained earlier in the "Salesforce.com end" steps.

    • Setup saml attribute to be sent as part of the Assertion to identify Salesforce.com user. This is done by configuring the attribute mapper either on IDP configuration or SP configuration. If IDP attribute mapper is configured, all SPs will receive the attribute and if only Salesforce.com SP configuration is setup - that attribute will only be sent to Salesforce.com. In my setup I changed SP attribute mappper to map OpenSSO user profile attribute mail to SAML attribute mail.

Test :
  • Start browser and invoke IDP initiated SSO :
    <protocol>://<idphostname>/<port>/<deployuri>/idpssoinit?NameIDFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient&metaAlias=/idp&spEntityID=https://saml.salesforce.com&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

    In my setup I used: http://sa.idp.com:8080/sa/idpssoinit?NameIDFormat=urn:oasis:names:tc:SAML:2.0:nameid-format:transient&metaAlias=/idp&spEntityID=https://saml.salesforce.com&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
    If things work correcly, OpenSSO in IDP role should prompt for user credentials and seamlessly Single SignON to Salesforce.com as the user mapped to the authenticated user.
  • Troubleshooting : Both OpenSSO and Salesforce.com provide excellent online facilities to test SSO.
    • Visit OpenSSO Test Connection Connectivity task flow.
    • Salesforce.com provides a SAML assertion Validator where you can cut and paste a SAML assertion to report errors.
    • Both OpenSSO and Salesforce.com provide error logs - SFDC user logs are under Setup->Manage Users->Login History.

Tuesday Sep 23, 2008

Saleforce.com "Summer 08" has SAML 1.1 support


Kudos to Salesforce.com on SAML1.1 support with the Summer 08 release. This Release note covers it nicely:

...Unlike with delegated authentication, customers do not have to deploy Salesforce-specific software to use SAML. Also, SAML never sends passwords to Salesforce, so it is inherently more secure than other authentication mechanisms....


Wanted to try it out with OpenSSO for a while and finally got a window thanks to the successful OpenSSO code freeze on its way towards Open Express Build 6 / OpenSSO Enterprise 8 (Congrats team!).

Except for the initial learning curve and my rustiness on SAML1.1, it worked quite nicely! Shouldnt take you any more than 15 minutes:

Configuring OpenSSO End (Identity Provider) :
  • Obtain OpenSSO.war, deploy it and configure it. If you want a quicker install, but with some risk since it is new: you can try OpenSSO QuickSetup using Java web start. I chose sa.idp.com as my hostname.
  • Login to the OpenSSO instance as amadmin.
  • Navigate to Federation -> SAML1.1 configuration
  • Register Salesforce.com as a "Destination site". I named it SFDC. Make sure the "POST profile" is chosen. Your config should look something like this :


  • Export the source site public key. OpenSSO provides a keystore with a test certificate in it.
    cd <basedir>/<deployuri>
    keytool -export -keystore keystore.jks -alias test -file cert.cer


    Configuring SalesForce.com end (Service Provider) :
  • Get a Saleforce.com account here.
  • Login to SFDC portal and navigate to Setup (right at the top)->Security Controls->Single Signon Controls
  • Enter all the mandatory fields, and import the OpenSSO public key experted earlier. My setup looks as follows :



    Note that I chose "Federated ID" for my name identifier to directly map the authenticated user in OpenSSO to Salesforce.com user. Alternatively I could have configured OpenSSO to send the Salesforce.com userid either as a part of the Subject or a attribute statement.
    Save your settings - a "Recipient URL" will be shown on he screen. Select and copy this string - this will be needed in the last step.
  • Navigate to Security->Manage Users-> Users - select a user and enter "Edit" mode. Enter the following string in "Federated NameID" field : id=amadmin,ou=user,dc=opensso,dc=java,dc=net Again this is a shortcut - in a real deployment I would have created a new user in opensso and used that dn here.
    One last step- thanks to the choice I made with respect to the name identifier. Login back to the OpenSSO instance, and navigate to SFDC SAML1.1 config. Paste the "Recipient URL" in the "POST URL" field.
    Thats it - to test your setup : Enter the following URL in a browser :
    http://sa.idp.com:8080/sa/SAMLPOSTProfileServlet?TARGET=http://salesforce.com Login as amadmin into OpenSSO if prompted - you should be automatically single signed on to SFDC portal page.

    A leading On-Demand/SaaS provider supporting a open standards based mechanism for single signon is indeed a significant step in accelerating the adoption of these standards over costly and often kludgy proprietary mechanisms. Hoping for SAML2/Logout/AuthZ/Attributes - other protocols in the future.
  • About

    rajeev

    Search

    Categories
    Archives
    « April 2014
    SunMonTueWedThuFriSat
      
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
       
           
    Today