PingFederate IdP startSSO.ping: How to pass data to be placed into SAML attributes?

Question

I have a need to pass data from one system to another, during SSO using PingFederate.

Currently my link looks like this:

https://pingfederate.myexample.org/startSSO.ping?TargetResource=https%3A%2F%2Fwebapp.othercompany.org%3FkeepParam%3DkeepThisOnURLparamOne%3DvalueOne%26paramTwo%3DvalueTwo

TargetResource, decoded, looks like this:

https://webapp.othercompany.org?
    keepParam=keepThisOnURL
    &paramOne=valueOne
    &paramTwo=valueTwo

After pingfederate processes the request, it ends up making a post to othercompany, copying the entire TargetResource into RelayState, params and all:

POST https://sso.othercompany.org
SAMLResponse: {paramOne: valueOne; paramTwo: valueTwo} //(in actual saml format)
RelayState: https://webapp.othercompany.org?keepParam=keepThisOnURL&paramOne=valueOne&paramTwo=valueTwo

My goal is to pass paramOne and paramTwo into SAML attributes somehow, but NOT carry those params over onto RelayState, keeping only keepParam=keepThisOnURL:

POST https://sso.othercompany.org
SAMLResponse: {paramOne: valueOne; paramTwo: valueTwo} //(in actual saml format)
RelayState: https://webapp.othercompany.org?keepParam=keepThisOnURL

Is this possible to do with PingFederate?

E.g., is there any other way to pass data into startSSO.ping from a browser request besides sneaking them into TargetResource?

Or if they can only be appended to TargetResource, can the value be modified (strip off most params) before copying into RelayState?

Answer 1

The reason that the parameters were tacked into the Relay State is because you URLEncoded them, So PingFed thought they were just part of the TargetResource.

Instead, you would do something like this:

https://pingfederate.myexample.org/idp/startSSO.ping?
  paramOne=valueOne&
  paramTwo=valueTwo&
  TargetResource=https%3A%2F%2Fwebapp.othercompany.org%3FkeepParam%3DkeepThisOnURL

I should point out two things, the first being a showstopper:

• fulfilling attributes via parameters passed in the startSSO.ping calls is not supported and won't work properly until at least one of two current feature requests are fulfilled, PPQ-1141 and PPQ-2815. Neither of these are currently scheduled (low request volume) in the development trains, so if this is critical to your work, get in touch with your Ping account executive to have your needs communicated.
• I should point out that this overall methodology probably doesn't make a whole lot of sense from an operational standpoint, simply because it means that you will be dependent on an IdP initiated transaction because you have no way of fulfilling this with an SP-initiated transaction.

Based on those, I would recommend trying to architect another solution by which you could set those attributes, which I recognize may be difficult - especially if they are only derived at runtime, rather than via query to a datastore.