simplesamlphp -> PingFederate IDp not returning to originating page

[Jon August]

I got simplesamlphp working fairly easiy with my company's PingFederate IDp.  Thank you to the developers for making this - it works great and allows me to provide really great services to my colleagues.

The problem I'm having is that when the SAML transaction comes back from the IDp, I always end up at index.php even if I originated from somewhere else.

For example, this is the code I have at the top of "index.php" and at the top of "superSecretFunction.php":

require_once ('simplesamlphp/lib/_autoload.php');
$as = new SimpleSAML_Auth_Simple('default-sp');
$as->requireAuth();
$attributes = $as->getAuthData('saml:sp:NameID');
$userEmail = $attributes['Value'];

Whether you start at index.php or superSecretFunction.php, after authorizing you at the IDp, the browser will return to index.php.

I can share any of the config files you would like to see - just let me know.

Thanks,

   Jon

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-06 20:44]:

> The problem I'm having is that when the SAML transaction comes back
> from the IDp, I always end up at index.php even if I originated from
> somewhere else.

If I had to guess I'd say RelayState never works correctly then and
ending up at index.php is a function of your web server.
That at least explains why starting at /index.php "works" and starting
elsewhere does not.
Anyway, you'll need to trace the HTTO requests and responses in the
browser and look at what the SimpleSAMLphp SP puts into the
RelayState, what the RelayState value is when its returned from the
SAML IDP (the IDP must return it verbatim) and where SimpleSAMLphp
redirects the browser to after processing the SAML Assertion (after it
has been HTTP POST'ed to the SP's ACS URL).
-peter

[Jon August]

OK, I dug a little deeper.

It looks like if there is no valid session found, it will authenticate with the IdP, and it does send the IdP the correct RelayState parameter on the URL.

It authenticates and sends the browser back to / which is the same as index.php - which is why it works when you go to index.php.

If there is a valid session found, it will simply load the correct page and simplesamlphp shares the AuthData from the session.

Where should I look to see if the IdP is sending back the RelayState?  I don't see any mention of it in the simplesamlphp log except for when it's going to the IdP.  And this is what I see in the apache log:

xxx.xxx.xxx.xxx - - [06/Jul/2016:22:39:47 -0400] "GET /superSecretFunction.php HTTP/1.1" 302 1965

xxx.xxx.xxx.xxx - - [06/Jul/2016:22:39:48 -0400] "POST /simplesaml/module.php/saml/sp/saml2-acs.php/default-sp HTTP/1.1" 303 593

xxx.xxx.xxx.xxx - - [06/Jul/2016:22:39:48 -0400] "GET / HTTP/1.1" 200 4928

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-07 04:43]:

> Where should I look to see if the IdP is sending back the RelayState? I
> don't see any mention of it in the simplesamlphp log except for when it's
> going to the IdP. And this is what I see in the apache log:

Where previously I said you should:

> Anyway, you'll need to trace the HTTP requests and responses in the
> browser

With both HTTP-Redirect and HTTP-Binding there will be a seperate
parameter in SAML request and response messages, called RelayState.
By default SimpleSAMLphp puts the originally requested URL into that
value, verbatim., making this simple to debug.
Note down what the URL is you initially requested, what the RelayState
value is when the SP sends a SAML authentication request to the IDP
(must match the URL you wanted to access), and again what the
RelayState value is when the IDP sends a reponse to the SP. That (the
RelayState value coming from the IDP) is where the SAML SP should be
redirecting you to after finishing with processing the SAML assertion.
-peter

[Jon August]

I do see the RelayState parameter on the SAMLRequest url, but I don't see any RelayState value in the SAMLResponse at all.  However, if I set a RelayState value in authsources.php, it will go to the url specified there, but I still don't see that value in the SAMLResponse.

I spoke with the IdP owner and she says that the problem is that simplesamlphp is putting the SAMLRequest on the URL when simplesamlphp sends the request to the IdP. 

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-07 16:29]:

> I spoke with the IdP owner and she says that the problem is that
> simplesamlphp is putting the SAMLRequest on the URL when simplesamlphp
> sends the request to the IdP.

If the IDP owner (and/or Ping) has questions as to the legal use of
RelayState that can't be answered by looking at the SAML specification
there's also the saml...@lists.oasis-open.org mailing list for
guidance and interpretation.
-peter

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-07 16:29]:

> I spoke with the IdP owner and she says that the problem is that
> simplesamlphp is putting the SAMLRequest on the URL when
> simplesamlphp sends the request to the IdP.

In case I wasn't clear before: In my view it's the job of the party
claiming it's someone else's fault to prove that, not everyone else
(such as this list, or you as the one deploying that software) to
jump up in defense of open source software and show that SimpleSAMLphp
is doing it correctly.
-peter

[Jon August]

I hope that I didn't give the impression that I thought there was something wrong with SimpleSAMLphp.  My goal is solely to get my application working with respect to getting back to the page that the authentication originated from. As I am familiar with SAML for an extremely short time, I am unaware of all the intricacies of how the SP and the IdP communicate.  I am here for suggestions on how I can resolve my issue.  I'm sorry if I said the wrong thing.

I only mentioned my colleague's comment in case there was an option to remove the SAMLRequest from the URL in case some IdP (including Ping) had difficulty with that.  Apparently that is not the case and I will push back to the IdP owner.

However, I'm still not clear where I would find the RelayState coming back from the IdP so I can back up my claim that the IdP is failing to send this back.  As I mentioned, even when it works properly, I don't see it in the SAMLResponse.  Is there a tool I can use or a log I can check to see this particular communication?

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-07 16:56]:

> I hope that I didn't give the impression that I thought there was something
> wrong with SimpleSAMLphp. My goal is solely to get my application working
> with respect to getting back to the page that the authentication originated
> from. As I am familiar with SAML for an extremely short time, I am unaware
> of all the intricacies of how the SP and the IdP communicate. I am here
> for suggestions on how I can resolve my issue. I'm sorry if I said the
> wrong thing.

You didn't (and there's nothing to apologise for). I just wanted to
point out what one can reasonably expect on a support list like
this. Going on a wild-goose chase merely because someone said that
someone else claimed there was an error in the software isn't included
in that.

> I only mentioned my colleague's comment in case there was an option
> to remove the SAMLRequest from the URL in case some IdP (including
> Ping) had difficulty with that. Apparently that is not the case and
> I will push back to the IdP owner.

Since many here (myself included) never had any issues with SSP and
RelayState I'm assuming SSP handles this correctly, as in per-the-spec
and interoperably. I'm not aware of a configuration option in SSP that
would cause an incorrect default behaviour by SimpleSAMLphp to be
changed to a correct, interoperable one.

> However, I'm still not clear where I would find the RelayState
> coming back from the IdP so I can back up my claim that the IdP is
> failing to send this back. As I mentioned, even when it works
> properly, I don't see it in the SAMLResponse. Is there a tool I can
> use or a log I can check to see this particular communication?

It's not part of the SAML Response XML (element) itself. As I've
already tried to explain twice, it's part of the HTTP Reponse headers
that accompany the SAML response.
In the HTTP POST there's a "SAMLResponse", and next to that you should
find another header/parameter/form element called "RelayState".
Look at a non-broken setup for details (e.g. using the TestShib SAML
IDP together with the TestShib SAML SP) or at the spec:

In Bindings it's section 3.4.3 for the request (HTTP-Redirect), and
3.5.3 for the request (HTTP-POST) and response (alawys HTTP-POST in
the WebSSO profile).
-peter

[Jaime Perez Crespo]

Hi Jon,

On 07 Jul 2016, at 16:56 PM, Jon August <jona...@gmail.com> wrote:
> I hope that I didn't give the impression that I thought there was something wrong with SimpleSAMLphp. My goal is solely to get my application working with respect to getting back to the page that the authentication originated from. As I am familiar with SAML for an extremely short time, I am unaware of all the intricacies of how the SP and the IdP communicate. I am here for suggestions on how I can resolve my issue. I'm sorry if I said the wrong thing.

Not at all, don’t worry ;-)

> I only mentioned my colleague's comment in case there was an option to remove the SAMLRequest from the URL in case some IdP (including Ping) had difficulty with that. Apparently that is not the case and I will push back to the IdP owner.

I’m not sure I understand correctly, but anyway: the SAMLRequest is just a parameter of the request, just as the RelayState. Whether it is part of the URL or sent as a POST parameter, depends on the binding in use. That’s determined in the IdP metadata, and SimpleSAMLphp will automatically do whatever the IdP metadata says. In any case, sending a SAMLRequest in the URL is the normal and even recommended behaviour. I seriously doubt that’s a problem for the Ping IdP.

A different way to interpret your statement would be that they complain about the SAMLRequest being part of the URL in the RelayState, but that makes no sense at all, and it’s definitely not the case. So I’m not sure what are they complaining about here...

> However, I'm still not clear where I would find the RelayState coming back from the IdP so I can back up my claim that the IdP is failing to send this back. As I mentioned, even when it works properly, I don't see it in the SAMLResponse. Is there a tool I can use or a log I can check to see this particular communication?

Use the "SAML Tracer” Firefox extension. You will see all the SAML messages and request parameters. If they are sending the RelayState back, it will be there. As Peter said, as a parameter, *not* inside the SAMLResponse XML document.

I would also recommend you to start looking at your logs. The information there should be helpful to debug your issue. By the way, you said:

> However, if I set a RelayState value in authsources.php, it will go to the url specified there, but I still don't see that value in the SAMLResponse.

Does that mean that if you set the RelayState manually in config/authsources.php, then it works and you are getting back to the right page?

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Jon August]

Hi Jaime,

Not at all, don’t worry ;-)

OK.  Thanks for following up.  :-) 

I’m not sure I understand correctly, but anyway: the SAMLRequest is just a parameter of the request, just as the RelayState. Whether it is part of the URL or sent as a POST parameter, depends on the binding in use. That’s determined in the IdP metadata, and SimpleSAMLphp will automatically do whatever the IdP metadata says. In any case, sending a SAMLRequest in the URL is the normal and even recommended behaviour. I seriously doubt that’s a problem for the Ping IdP.

A different way to interpret your statement would be that they complain about the SAMLRequest being part of the URL in the RelayState, but that makes no sense at all, and it’s definitely not the case. So I’m not sure what are they complaining about here...

I was wary when the IdP owner made that complaint - didn't seem like it should matter.  The RelayState query param was still present going to the IdP so it shouldn't matter if another parameter is on the URL with it.  I understand now from Peter and your responses that I should see RelayState as a query param coming back along side the SAMLResponse (not inside it).  And I am indeed not receiving it.  

 

Use the "SAML Tracer” Firefox extension. You will see all the SAML messages and request parameters. If they are sending the RelayState back, it will be there. As Peter said, as a parameter, *not* inside the SAMLResponse XML document. 

I have now used  "HTTP Trace" and "SAML Message Decode" on Chrome (Firefox is not set up in our dev environment) and I can clearly see which are query parameters and which are decoded SAML payloads.  And it is evident that I am not receiving the RelayState parameter back from the PingFederate server.

 

I would also recommend you to start looking at your logs. The information there should be helpful to debug your issue. By the way, you said:

> However, if I set a RelayState value in authsources.php, it will go to the url specified there, but I still don't see that value in the SAMLResponse.

Does that mean that if you set the RelayState manually in config/authsources.php, then it works and you are getting back to the right page? 

Sorta... if I set RelayState manually in config/authsources.php, it does indeed go to the page specified in that variable, however, it is not returning to the originating page.  So, no matter which page I go to, it will always redirects to the page set in config/authsources.php.  This isn't terribly useful information I realize now.  

I have shared some of the documentation now with the IdP owner, but they are now saying that I need to send the originating page in "TargetResource" instead of "RelayState".  Just mentioning what she said in case it helps clear up some kind of configuration discrepancy on her side.  

She has also just asked me if my SSO profile is IdP initiated SSO or SP initiated SSO.  This question is confusing to me.  I am writing an application that is relying on the PingFederate server (an IdP, correct) to authenticate the desktop user and send their identity back to the ACS on SSP.  Doesn't that make my application a SP?  Doesn't that mean it is SP initiated?

Thanks for the help.  It is difficult to figure out where to go with this since both components of this system presumably work fine for other people.  And it works mostly fine for me - except for sending my users to a default page instead of the page they came from.

 

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-07 22:33]:

> I was wary when the IdP owner made that complaint - didn't seem like it
> should matter. The RelayState query param was still present going to the
> IdP so it shouldn't matter if another parameter is on the URL with it. I
> understand now from Peter and your responses that I should see RelayState
> as a query param coming back along side the SAMLResponse (not inside it).
> And I am indeed not receiving it.

It's not a query parameter -- stricly speaking -- for the HTTP
reponse, it's part of the HTML form content which is HTTP POST'ed to
the SP. (One is the SAMLResponse, the other the
RelayState. Whatever/wherever one is, the other one should be next to
it.)

To test your debugging process on a non-pathological case, fire up the
SAML tracer plugin (or whatever you're using), go to
https://sp.testshib.org/ and enter
https://idp.testshib.org/idp/shibboleth as the IDP into the only form
field on that page. On the resulting testshib IDP login page are the
test credentials to use for login, pick any. After successful login
check your browser's logs again and look for the RelayState parameter
in both the authn *request* to the IDP and the *response* from the IDP.
That's where the RelayState would be, esp in the response.

> Sorta... if I set RelayState manually in config/authsources.php, it
> does indeed go to the page specified in that variable, however, it
> is not returning to the originating page. So, no matter which page
> I go to, it will always redirects to the page set in
> config/authsources.php. This isn't terribly useful information I
> realize now.

The final redirect to the initially requested resource (what the SP
dynamically puts into the RelayState parameter) happens from the SP
after processing the SAML. So if you hard-code the RelayState on that
SP to some URL you're overriding the dynamic value with this, and so
that's where you'll always end up. I.e., works as designed and doesn't
help with your problem.

> I have shared some of the documentation now with the IdP owner, but
> they are now saying that I need to send the originating page in
> "TargetResource" instead of "RelayState". Just mentioning what she
> said in case it helps clear up some kind of configuration
> discrepancy on her side.

That's not SAML, though. That would for other (see below) requests,
but you're using SAML and sending them SAML protocol messages, so
those must be according to the SAML spec.

> She has also just asked me if my SSO profile is IdP initiated SSO or
> SP initiated SSO. This question is confusing to me.

What they're saying is: *If* you're sending a proprietary,
Ping-specific authentication request to the IDP (what sometimes is
called "IDP-initiated", which is a really bad name) -- instead of a
OASIS SAML 2.0 standard-defined authentication request (which is
called "SP-intiated") -- then we want you to put the originally
requested URL into a parameter called TargetResource. (Where in SAML
that parameter would be called RelayState and is created by
SimpleSAMLphp for you automatically).
But you're not. (The "If" at the beginning of the above paragraph.)

> I am writing an application that is relying on the PingFederate
> server (an IdP, correct) to authenticate the desktop user and send
> their identity back to the ACS on SSP. Doesn't that make my
> application a SP? Doesn't that mean it is SP initiated?

Correct on all accounts. The real issue is this: If your SP sends a
*SAML* authentication request to the IDP, and the IDP processes that
and sends back a SAML Reponse, they're acting as a SAML IDP. And that
means they MUST also send back the RelayState they're given *verbatim*.

What their own parameter is called in case someone sent them a
proprietary authentication request (instead of a SAML one) is
irrelevant, since that's not what you're doing.

So the literal reply to them is (in their own words, those make sense
to anyone else) is your "SSO Profile is SP-initiated". Having to ask
you that is a bit silly, of course, since their IDP recieved a SAML
request and sent a SAML response, only one that's missing a mandatory
parameter.
-peter

[Jon August]

> I am writing an application that is relying on the PingFederate
> server (an IdP, correct) to authenticate the desktop user and send
> their identity back to the ACS on SSP.  Doesn't that make my
> application a SP?  Doesn't that mean it is SP initiated?

Correct on all accounts. The real issue is this: If your SP sends a
*SAML* authentication request to the IDP, and the IDP processes that
and sends back a SAML Reponse, they're acting as a SAML IDP. And that
means they MUST also send back the RelayState they're given *verbatim*.

So the literal reply to them is (in their own words, those make sense
to anyone else) is your "SSO Profile is SP-initiated". Having to ask
you that is a bit silly, of course, since their IDP recieved a SAML
request and sent a SAML response, only one that's missing a mandatory
parameter.

So, my IdP owner agreed to switch the profile to SP-initiated SSO, however now the IdP is making the following complaint:

javax.servlet.ServletException: org.sourceid.saml20.bindings.BindingException: Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect is not enabled for (SP) ::: JonAugustEntityID

She says we agreed to HTTP Post, not HTTP-Redirect.  Is there a way to tell simplesamlphp to not use HTTP-Redirect?  Again, I'm not sure what this means since it seems like there is a lot of Redirecting going on.

Thanks for the help, Peter and Jaime. 

[Jon August]

So, my IdP owner agreed to switch the profile to SP-initiated SSO, however now the IdP is making the following complaint:

javax.servlet.ServletException: org.sourceid.saml20.bindings.BindingException: Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect is not enabled for (SP) ::: JonAugustEntityID

She says we agreed to HTTP Post, not HTTP-Redirect.  Is there a way to tell simplesamlphp to not use HTTP-Redirect?  Again, I'm not sure what this means since it seems like there is a lot of Redirecting going on.

Thanks for the help, Peter and Jaime. 

I tried adding this to authsources.php:

 'ProtocolBinding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',

which seems to do what I want from what I read in the docs, but there's still an error.  Please let me know if there's something else I should be looking at.  Thanks.

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-18 21:13]:

> javax.servlet.ServletException:
> org.sourceid.saml20.bindings.BindingException: Incoming binding
> urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect is not enabled for (SP)
> ::: JonAugustEntityID
>
> She says we agreed to HTTP Post, not HTTP-Redirect. Is there a way
> to tell simplesamlphp to not use HTTP-Redirect? Again, I'm not sure
> what this means since it seems like there is a lot of Redirecting
> going on.

I'd assume if you supplied SimpleSAMLphp with correct SAML 2.0
Metadata about the IDP this would just work.
-peter

[Jon August]

> I'd assume if you supplied SimpleSAMLphp with correct SAML 2.0
> Metadata about the IDP this would just work.
> -peter

Me too.

[Peter Schober]

* Jon August <jona...@gmail.com> [2016-07-18 23:40]:

> > I'd assume if you supplied SimpleSAMLphp with correct SAML 2.0
> > Metadata about the IDP this would just work.
>

> Me too.

Not sure there's a question in there? Ask the IDP for SAML 2.0
Metadata describing their entity and import it into SSP using the
provided metadata converter.
-peter

[Jaime Perez Crespo]

Hi Jon,

On 18 Jul 2016, at 21:41 PM, Jon August <jona...@gmail.com> wrote:
> So, my IdP owner agreed to switch the profile to SP-initiated SSO, however now the IdP is making the following complaint:
>
> javax.servlet.ServletException: org.sourceid.saml20.bindings.BindingException: Incoming binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect is not enabled for (SP) ::: JonAugustEntityID
>
> She says we agreed to HTTP Post, not HTTP-Redirect. Is there a way to tell simplesamlphp to not use HTTP-Redirect? Again, I'm not sure what this means since it seems like there is a lot of Redirecting going on.

I’m quite surprised at what you are describing. Seems like they are not much interested in standards or interoperability. SP-initiated SSO is the most common form of SSO since SAML 2.0, which has been around for more than 10 years now.

Regarding HTTP POST vs HTTP-Redirect, what does it mean to “agree to HTTP POST” here? There are multiple bindings possible (HTTP POST, HTTP-Redirect, HTTP Artifact, etc), and each of them has its pros and cons. The most basic interoperability guidelines recommend or even require that SAML messages should be exchanged using the HTTP-Redirect binding, with only one exception: SAML responses should use the HTTP POST binding. There are two main reasons for this:

- The HTTP-Redirect binding is guaranteed to work regardless of the particularities of the user’s browser. HTTP redirections are always followed by all browsers. Therefore, this binding is always preferred provided the SAML message fits in.
- The HTTP POST binding has a problem, which is that it is prone to failures depending on the setup of the user’s browser, as it relies on automatic mechanisms that are not necessarily available (like javascript). It is therefore more fragile, and that makes it only recommended when there’s no other option. It is generally recommended to use it though with SAML responses, as those might be so big that they don’t fit in the URL, so a binding without size limitations is preferred. As a side effect, the HTTP POST binding does not keep track of the responses in permanent storage (via the web server log), helping with privacy and confidentiality.

So my advice would be to tell your IdP to stop interpreting things or doing SAML their way, and start using standards and interoperability recommendations that are proven to work and everybody else is using.

> I tried adding this to authsources.php:
>
> 'ProtocolBinding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
>
> which seems to do what I want from what I read in the docs, but there's still an error. Please let me know if there's something else I should be looking at. Thanks.

That should be irrelevant here, because your metadata should already tell them the same: "send me your SAML responses to the HTTP POST binding endpoint” (unless you messed up with SimpleSAMLphp’s configuration, which I guess you didn’t). So the issue here is that they are ignoring your metadata and configuring things the way they want, instead of following common practice. Additionally, I assume the problem now is the SAML Request that you are sending them using HTTP-Redirect, which they expect to be using HTTP POST.

If you really, really can’t make them understand that they are doing wrong, and therefore you need to submit to their will, what you need to do is edit the metadata you have configured locally for that IdP, and set the HTTP POST binding as the default for them:

https://simplesamlphp.org/docs/stable/simplesamlphp-metadata-endpoints

[arun...@gmail.com]

HI John,

I'm also trying to configure simplesamlphp with PingFederate IDP but facing lot of issues. Can you please give me the steps on how to configure. Also what configuration to be done on the authsources.php file?

[Peter Schober]

* arun...@gmail.com <arun...@gmail.com> [2017-11-10 08:57]:

> I'm also trying to configure simplesamlphp with PingFederate IDP but facing
> lot of issues. Can you please give me the steps on how to configure. Also
> what configuration to be done on the authsources.php file?

You configure SimpleSAMLphp as per the documentation, and add SAML 2.0
metadata to it describing the IDP (as per the docs). Then you try it
out and handle any errors as they appear, possibly asking questions
here, possibly also asking Ping to change settings for your instance
to make it conform to the SAML standard (as shown in the 1.5-year-old
thread you're replying to).
-peter