how to check authentication in a IDP-inititaed process flow?

[stpe...@hotmail.com]

I have an external IDP that my SP is connected to (exchanging metadata with). An SSO works just fine with a particular flow--if I send a request to the IDP from the SP to check if I am authenticated I can determine if I am or not and I can get the attributes and complete the SSO.

However, I cannot figure out how to determine if the user is logged in when the person lands on my site coming from the IDP first. That is, the process is always going to be that the user goes to the IDP (and logs in etc), redirects to the SP and the SP should let them in. However, I cannot get the session that the IDP sets. isAuthenticated() ALWAYS returns FALSE. If I use something like SAML tracer I see that the IDP does send me an assertion when the user is redirected to my SP.

So this works (and does not show the user the IDP log in page as they are loggedin already):
        $auth = new SimpleSAML_Auth_Simple($this->spname);
        $auth->requireAuth();
        $attributes = $auth->getAttributes();

But this does not work (as isAuthenticated() already shows FALSE)
        $auth = new SimpleSAML_Auth_Simple($this->spname);
        $auth->isAuthenticated()
        $attributes = $auth->getAttributes();

So what API do I use on my SP for this?

Thanks.

[stpe...@hotmail.com]

Is the problem that the process has to go to the SP first to start the session for simplesamlphp to capture and then let the IDP log the user in and return to the SP? Is the problem here that the idea of "IDP-initiated" SSO's is not that you start on the IDP? I just see how the assertion posted to the acs.php URL for the SP can be retrieved. I still must be missing something. I just don't know what.

[Jaime Perez Crespo]

Hi,

On 16 Nov 2017, at 04:00 AM, stpe...@hotmail.com wrote:
> Is the problem that the process has to go to the SP first to start the session for simplesamlphp to capture and then let the IDP log the user in and return to the SP?

No, you don’t need to have already a session in the SP for IdP-initiated SSO to work.

> Is the problem here that the idea of "IDP-initiated" SSO's is not that you start on the IDP?

It doesn’t matter how you reach the IdP. In IdP initiated, you have a URL in the IdP that you can visit to trigger authentication and be redirected to the SP. How you reach your URL is irrelevant.

> I just see how the assertion posted to the acs.php URL for the SP can be retrieved. I still must be missing something. I just don't know what.

Have you looked at the (SimpleSAMLphp) logs? If you are getting the assertion back but isAuthenticated() returns false, there must be some problem while processing the assertion. You need to check the logs.

> On Wednesday, November 15, 2017 at 3:03:03 PM UTC-5, stpe...@hotmail.com wrote:
>> I have an external IDP that my SP is connected to (exchanging metadata with). An SSO works just fine with a particular flow--if I send a request to the IDP from the SP to check if I am authenticated I can determine if I am or not and I can get the attributes and complete the SSO.
>>
>> However, I cannot figure out how to determine if the user is logged in when the person lands on my site coming from the IDP first. That is, the process is always going to be that the user goes to the IDP (and logs in etc), redirects to the SP and the SP should let them in. However, I cannot get the session that the IDP sets. isAuthenticated() ALWAYS returns FALSE. If I use something like SAML tracer I see that the IDP does send me an assertion when the user is redirected to my SP.
>>
>> So this works (and does not show the user the IDP log in page as they are loggedin already):
>> $auth = new SimpleSAML_Auth_Simple($this->spname);
>> $auth->requireAuth();
>> $attributes = $auth->getAttributes();
>>
>> But this does not work (as isAuthenticated() already shows FALSE)
>> $auth = new SimpleSAML_Auth_Simple($this->spname);
>> $auth->isAuthenticated()
>> $attributes = $auth->getAttributes();
>>
>> So what API do I use on my SP for this?

—
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

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

[stpe...@hotmail.com]

So I do see the assert and decrypted info from the IDP posted to the sp.php protocol in the log file. I do not see any errors except each attempt starts with

Nov 16 09:05:31 SimpleSAMLphp DEBUG [a9988f6ef8] Session: '[my sp URI]' not valid because we are not authenticated.
Nov 16 09:05:31 SimpleSAMLphp DEBUG [a9988f6ef8] Session: '[my sp URI]' not valid because we are not authenticated.
Nov 16 09:05:31 SimpleSAMLphp DEBUG [a9988f6ef8] Session: '[my sp URI]' not valid because we are not authenticated.
Nov 16 09:05:31 SimpleSAMLphp DEBUG [a9988f6ef8] Session: '[my sp URI]' not valid because we are not authenticated.

But then I see, like I said, what I would expect and need:
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Received SAML2 Response from [the IDP in question]
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Has 2 candidate keys for validation.
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Validation with key #0 failed without exception.
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Validation with key #1 failed without exception.
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Decrypted message:
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="
. . . assertion
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Filter config for [the IDP in question] ->[me . . . my sp app]/sp/metadata.php: array (
all this stuff that looks like parameters and binary values
...


So why can I not retrieve the attributes or show that they were authenticated if it is in my SP simplesaml logs when the IDP posts the info to me?

Thanks

On Wednesday, November 15, 2017 at 3:03:03 PM UTC-5, stpe...@hotmail.com wrote:

[stpe...@hotmail.com]

Also this is at the very end of each log file for the assertion. But I still get not authenticated when I use isAuthenticated to test.

Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Session: doLogin("[my sp uri]")
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] Received message:
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b] <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_49a4a87a-dd21-4cdb-b060-3652d28dbd6f" Version="2.0" IssueInstant="2017-11-16T14:07:10.293Z" Destination="https://[my sp uri]sp/saml2-acs.php/[my sp uri]" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified">
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b]   <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">[IDP URI]</Issuer>
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b]   <samlp:Status>
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b]     <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b]   </samlp:Status>
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b]   <EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
Nov 16 09:07:16 SimpleSAMLphp DEBUG [89299ab37b]     <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element">

[stpe...@hotmail.com]

at this point I am at a loss. I've played around with this all day. I cannot seem to get to the decrypt assertion/attributes I see in the saml log file when the IDP posts it to the acs.php protocol for my sp. I can do a ispassive set up where I send the request back to the idp with the login() function but to me that is what I was already doing . . . just requiring authentication . . . getting a response back from the IDP that there is one and seeing that they are logged in/authenticated . . . retrieiving their attributes. I want to be able to determine this the first time the IDP redirects to the SP. I just cannot seem to do it. I do not see any errors in the log.

[Jaime Perez Crespo]

Hi,

It looks like decryption of the assertion is working, but not the verification of the signature. Make sure you have configured the remote IdP metadata according to their SAML metadata, and check with them that they are using the right key to sign their responses, corresponding to the signing certificate in the IdP metadata.

On 16 Nov 2017, at 22:33 PM, stpe...@hotmail.com wrote:
> at this point I am at a loss. I've played around with this all day. I cannot seem to get to the decrypt assertion/attributes I see in the saml log file when the IDP posts it to the acs.php protocol for my sp. I can do a ispassive set up where I send the request back to the idp with the login() function but to me that is what I was already doing . . . just requiring authentication . . . getting a response back from the IDP that there is one and seeing that they are logged in/authenticated . . . retrieiving their attributes. I want to be able to determine this the first time the IDP redirects to the SP. I just cannot seem to do it. I do not see any errors in the log.

[stpe...@hotmail.com]

I checked and they have the correct key. I have the correct metadata for them.The SP initiated works fine with no changes whatsoever. It is the IDP-initiated that fails. So it has to do with something that they are doing when posting. I cannot figure it out. I am still getting the decrypted assertion in the log file when they post to us. But I still cannot get isAuthenticated to work. It is always false. But if I immediately perform another redirect back to them to start a SP-initiated login all works fine .. . decryption takes place . . . matching signatures works . . . authentication works . . . isAuthenticated works. . . without them logging in again . . . so immediately following up with a sp-initiated log in does not require reauthentication either . . . the IDP sees the original session that was valid. . . but upon the second trip back to the SP . . . the SP recognizes the assertion and logs the user in. So there is something still I am missing on the first trip to the sp from an idp-initiated post. I am still trying to figure it out. But your comment on keys etc . . . unearthed the discussions around "Unable to validate Signature" that are related to <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>. I have yet to figure out if my problem is related to that but I do see that they are using sha256 and that using it in the past (before your updates) causes this same error. It must be related to the method somehow. I just don't know how yet. But this is only an issue with IDP-initiated SSO attempts.

[Jaime Perez Crespo]

Hi,

We really can’t help you without more information, such as complete logs for both successful and unsuccessful authentications, the SAML exchanges for both, etc.

In any case, if it works when you get a response to a SAML request sent by your SP, but it doesn’t when you get an IdP-initiated message, then it must be something the IdP is doing wrong. The signature method has nothing to do here, as SHA-256 has been supported for a long time.

Also, note that “signature" is not equal to “encryption". The SAML metadata allows an entity to differentiate both by specifying different keys for each of them. So the fact that you can decrypt the response and see its contents does not mean that the signature will be validated. SimpleSAMLphp will try to decrypt the response and verify the signature. If the signature cannot be verified for some reason, it will discard the message, even if the message was successfully decrypted.

On 29 Nov 2017, at 01:09 AM, stpe...@hotmail.com wrote:
> I checked and they have the correct key. I have the correct metadata for them.The SP initiated works fine with no changes whatsoever. It is the IDP-initiated that fails. So it has to do with something that they are doing when posting. I cannot figure it out. I am still getting the decrypted assertion in the log file when they post to us. But I still cannot get isAuthenticated to work. It is always false. But if I immediately perform another redirect back to them to start a SP-initiated login all works fine .. . decryption takes place . . . matching signatures works . . . authentication works . . . isAuthenticated works. . . without them logging in again . . . so immediately following up with a sp-initiated log in does not require reauthentication either . . . the IDP sees the original session that was valid. . . but upon the second trip back to the SP . . . the SP recognizes the assertion and logs the user in. So there is something still I am missing on the first trip to the sp from an idp-initiated post. I am still trying to figure it out. But your comment on keys etc . . . unearthed the discussions around "Unable to validate Signature" that are related to <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>. I have yet to figure out if my problem is related to that but I do see that they are using sha256 and that using it in the past (before your updates) causes this same error. It must be related to the method somehow. I just don't know how yet. But this is only an issue with IDP-initiated SSO attempts.