We have setup SFDC as the IdP for SAML 2.0 based SSO with a third party web application called, say, ACME.

The use case is thus:

  • User navigates to a Contact record
  • User clicks on custom button
  • User is redirected to ACME (SAML authentication happens)

What's special:

  • The ACME web app takes some data in the <saml:Attribute/> attribute
  • The custom data is based on fields from the Contact the user initiated the process

The proposed design:

  • Setup VFPage1 to be opened on click of the custom button, pass contact Id
  • While setting up the Service Provider settings for ACME, provide the full URL of VFPage2 as the ACS URL
  • From the controller of VFPage1, invoke the IdP URL (provided by SFDC) and pass any additional parameters received (ie. contact Id) [redirect to a PageReference of this URL]
  • (Assumption) VFPage2 will receive the SAMLResponse as well as the parameters passed from VFPage1 (ie. contact Id)
  • Query contact fields as required, populate <saml:Attribute/> as required and modify SAMLResponse
  • Do a form post of the modified SAMLResponse to ACME

The challenge:

  • The assumption in the proposed design is not valid. The IdP URL discards any parameters passed to it unless hard coded in the ACL URL setup

Edit: Another problem is that, the signature/digest is no longer valid because the SAML is now modified. Is there a way to sign it post the change? (Maybe I'll post it as a different question)

The solution:


  • The main challenge is to intercept the SAML response generated by SFDC and modify it before passing it to the service provider URL
    – LVS
    Oct 1, 2013 at 15:48
  • Would it work better for VFPage2 to be a REST resource?
    – Benj
    Oct 2, 2013 at 14:45
  • @Benj that would still require me to pass parameters from VFPage1. Idp sits in between and discards anything extra
    – LVS
    Oct 3, 2013 at 7:59
  • Could you use query string parameters instead?
    – Mike Chale
    Oct 15, 2013 at 12:16
  • The query string parameters passed from VFPage1 are discarded one the IDP URL is hit
    – LVS
    Oct 16, 2013 at 7:07

2 Answers 2


You won't be able to modify SAML response, it's signed with SFDC's private key and cannot be tampered with.

You should be able to use the out of the box identity provider if you don't mind getting a little dirty. When you set up a SAML service provider (as a Connected App) that represents your ACME app, add a custom attribute that maps to a field on the User object or a custom setting or a custom metadata record. The User object is available as $User on the field menu when you click on Insert Field button on the custom attribute screen. Custom settings or custom metadata records are not available on the menu but they can still be referenced in a formula via a global variable

Your button on the contact record should invoke IdP-initiated login URL. The value of the User object field or a custom setting has to be set during the click. Sequence of events:

  1. User navigates to a Contact record
  2. User clicks on custom button
    • write the value(s) from the Contact record to the field on the User object or a custom setting or a custom metadata record
    • invoke IdP-initiated login URL
  3. User is sent to ACME with the SAML attribute that will contain your dynamically generated values

If this is not acceptable, then your only other choice is to have another application act as a kind of a SAML proxy. This application could even be another (or perhaps even the same) SFDC org. The application would receive the SAML response, validate it, extract attributes (e.g. ID of the contact record) and finally make an API call to your source org to get the values from the Contact record. Once your app has all of the data, it would turn around and create a SAML response that it can send to ACME.

  • I thought of the writing to user object solution too, but it ain't worth it. thanks for clarifying about the modification, makes sense. going to send the extra stuff as an additional POST parameter
    – LVS
    Oct 17, 2013 at 17:55

For the interim, we're using cookies to store the context of the latest request by a user. This cookie will be set in VFPage1 and used by VFPage2.

Caveat: might not work when a user goes on a button click frenzy - having opened multiple tabs each having a different contact. The behaviour in that scenario might be unpredictable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .