SP with IdP-Initiated: Seems to Log In but Not Authenticated

[Angus Atkins-Trimnell]

I am building my first SAML SP.  We have a customer who uses Ping Federated and requires IdP-initiated SSO and I am using simplesamlphp.  I have set up the SP and we have attempted some SSO connections.  My reading of the logs (and the code) seems to indicate that the proper certificate is being found and doLogin is being called without error.  However, when my code runs on the page redirected to through relay state, SAML is reporting that the user is not authenticated.  The logs and the code on my page are below.

Log entries:

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] Received SAML2 Response from 'XXXX:SAML2'.

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] No certificate in message when validating against fingerprint.

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] Found 1 certificates in SAML2_Assertion

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] Has 1 candidate keys for validation.

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] Validation with key #0 succeeded.

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] Filter config for XXXX:SAML2->https://xxxxxxxx.xxxxxxxxxx.com/: array (  0 =>   sspmod_core_Auth_Process_LanguageAdaptor::__set_state(array(     'langattr' => 'preferredLanguage',     'priority' => 90,  )),)

Aug 10 15:32:19 simplesamlphp DEBUG [eaef6d214a] Session: doLogin("sp-demo")

Aug 10 15:32:20 simplesamlphp DEBUG [5c3a80d060] Session: 'XXXX:SAML2' not valid because we are not authenticated. 

Code from relay state page:

require_once('/includepath/simplesamlphp/lib/_autoload.php');

$as = new SimpleSAML_Auth_Simple('XXXX:SAML2');

$as->requireAuth();

$attributes = $as->getAttributes();

In the metadata for the IdP, I have set the entity ID to my SAML SP URL.  I also have the SSO Service of the IdP URL set and the cert fingerprint.  I don't have anything else set for the IdP.

Can anyone validate that the logs indicate what I think they do (everything is going correctly at SP but it is not recognizing authentication on the relay state page)? If information about my metadata is needed, please let me know.

Thanks in advance for any information.

--Angus

[Angus Atkins-Trimnell]

As there has been no response to this thread, I would like to try to reframe the question.

My understanding of the flow in IdP-initiated SAML is as follows:

• The user will sign into their IdP, which will authenticate them and construct an Assertion to send to my SP in a response
  
• When my SP (simplesamlphp) receives the response it will:
  
• Unpack the Assertion
  
• Check the certification on the Assertion against the fingerprint in the IdP metadata
• Get any attributes on the Assertion
• Log the user in
• Redirect the user to the relay state provided in the initial request or configured in the SP
• (Assumption) When the user is redirect to the relay state (a page in my Web Application), the authentication status and any attributes will be available to the page by calling the SimpleSAML_Auth_Simple() method, passing in the name of the IdP in metadata.
  

What I'm really concerned with is this last assumption.  Is this a proper assumption?  Do any special session configuration variables need to be set in the metadata or the SP configuration to make this information accessible to page indicated in Relay State?

I very much appreciate any response to this question.  I'm quite at a stand-still at this time without, at least, knowing that I am in the right ballpark with respect to my assumptions.

Cheer!

--Angus

[Peter Schober]

* Angus Atkins-Trimnell <angusat...@sbcglobal.net> [2015-08-16 19:33]:

> My understanding of the flow in IdP-initiated SAML is as follows:

It's fully identical to the normal SP-initiated flow, you're only
replacing a SAML 2.0 specified (standard) authentication request to

> - *(Assumption)* When the user is redirect to the relay state (a

> page in my Web Application), the authentication status and any
> attributes will be available to the page by calling the
> SimpleSAML_Auth_Simple() method, passing in the name of the IdP
> in metadata.

SimpleSAMLphp will create a session with the appropriate data in
it. By default that's an ordinary PHP session, the name of the cookie
as well as the path should be configurable in config/config.php, IIRC.
Obviously that will influence from where you'll be able to access
data structures from that session.

> What I'm really concerned with is this last assumption. Is this a
> proper assumption? Do any special session configuration variables
> need to be set in the metadata or the SP configuration to make this
> information accessible to page indicated in Relay State?

Provided the resource you want to access the data structures from the
session shares the same protocol (HTTPS, ideally) and hostname (FQDN)
as the SP's ACS URL, and the session's path is set to '/' (or
something where SimpleSAMLphp can write the session cookie to, and you
own code can access it) that should Just Work.
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2015-08-17 15:09]:

> * Angus Atkins-Trimnell <angusat...@sbcglobal.net> [2015-08-16 19:33]:
> > My understanding of the flow in IdP-initiated SAML is as follows:
>
> It's fully identical to the normal SP-initiated flow, you're only
> replacing a SAML 2.0 specified (standard) authentication request to

[ something got lost here ]

… the IDP with a proprietary (non-standard) request to the IDP.
Everything else is the same.
-peter

[Angus Atkins-Trimnell]

Peter,

Thanks for the response.  I'm a little concerned about your comment that the FQDN between the target and the SP have to match.  I set up a new URL for the SP (based on a requirement from the customer).  So, my reading of this is if I have an SP at https://saml2.mydomain.com, that redirects to a target such as https://admin2.mydomain.com/customerid, the authentication information will not be available to the target page.  Is this correct?

Thanks.

--Angus

[Peter Schober]

* Angus Atkins-Trimnell <angusat...@sbcglobal.net> [2015-08-17 19:00]:

> Thanks for the response. I'm a little concerned about your comment that
> the FQDN between the target and the SP have to match. I set up a new URL
> for the SP (based on a requirement from the customer). So, my reading of
> this is if I have an SP at https://saml2.mydomain.com, that redirects to a
> target such as https://admin2.mydomain.com/customerid, the authentication
> information will not be available to the target page. Is this correct?

By default a HTTP cookie referencing the PHP session created by
SimpleSAMLphp will be set to the FQDN of the SAML SP (after having
accepted and "in exchange for" the SAML Assertion).
A conforming HTTP User Agent will not send this HTTP Cookie to another
host (different FQDN), so any code running on that other FQDN would
never get the session cookie from the browser and hence could not
access the session on the server. (That's one reason why moving the
processing of SAML protcol messages out to a seperate vhost doesn't
make much sense.)

The simplest way to work around this security feature would be to let
every and any host in the shared DNS domain read those HTTP Cookies,
by issuing the cookie to the shared DNS domain, instead of to the
FQDN. At least your example above implies a shared domain of
"mydomain.com" between the two FQDNs, and probably a shared server
hosting the two vhosts -- otherwise you'd be unable to share a session
between them anyway (with the default session storage, that is).
-peter

[Angus Atkins-Trimnell]

I have update the cookie_domain to the second-level domain name in the simplesamlphp config and, on my target page, call ini_set to make sure the cookie domain setting in PHP is the same.  I also update the session save path in config to match the value in the PHP installation.  I am still getting a "not valid because we are not authenticated" message in the log and my target page is not processing (because of requireAuth()).  I have checked the cookies on the browser and we have both  PHPSESSID and SimpleSAMLAuthToken cookies and they show the second-level domain.  I have a feeling there is just some configuration tweak that I am missing.  I've checked session.save_handler, session.cookie_path and session.name and they all seem to line up between simplesamlphp and PHP.  

Is there anything else that I might be missing?

Thanks.

--Angus

On Tuesday, August 11, 2015 at 9:36:04 AM UTC-5, Angus Atkins-Trimnell wrote:

[Jeffery Thompson]

Had to sign up just to say thank you. I was getting super frustrated trying to get my SP to authenticate on the page after the RelayState redirect. The SimpleSAMLphp logs didn't show any errors with my SAMLResponse but kept saying the AuthToken cookie was missing, so I was very confused as to what was going on. Your comment made me take a look at the session cookie domain in my config. Turns out, I had 'session.cookie.domain' => '*.mydomain.com', but the star wasn't working like a wildcard, so I switched it to '.mydomain.com' and now it is actually authenticating on my application page. Thank you so much! Hope this post helps anyone struggling with the same issue.