Session ExpectedInResponseTo missing

[thisisata]

Hi, Please help, if you know whats causing this issue after the authentication response from Idp.

[jaymcguinness]

See if https://github.com/i8beef/SAML2/issues/38 helps

[thisisata]

Thanks for ur reply but I already have latest build - 3.2.0.57.

[jaymcguinness]

I think you'll need to provide a bit more information:

• How/where is it hosted?
• How is session state set-up? Load balanced?

If you dig into the code you'll see the only reason you'll get this error is because the state service is getting nothing back:

var expectedInResponseTo = StateService.Get<string>(ExpectedInResponseToSessionKey);

if (string.IsNullOrEmpty(expectedInResponseTo))
{
    throw new Saml20Exception(ErrorMessages.ExpectedInResponseToMissing);
}

https://github.com/i8beef/SAML2/blob/b2e475c46c558e8246a346ef07fe7dc53f57a318/src/SAML2/Protocol/Saml20SignonHandler.cs

HTH you figure it out.

[thisisata]

Thanks for your time. Yes I debugged and getting exception at this line only - var expectedInResponseTo = StateService.Get(ExpectedInResponseToSessionKey); I have one basic mvc app using .net Framework 4.6 which is hosted in IIS and I am testing it with http://localhost/ssosp/login.ashx there is no load balancer and I dont have any session specific setting in web.config. Do i need any specific section in web.config for session? Thank you again for this sincere help...

[jaymcguinness]

As discussed in https://github.com/i8beef/SAML2/issues/38 it could be the cookies not being set.

If you check in the browser devtools (F12) can you see any cookies being set?

I also notice that you're running this over http:// rather than https:// - a few things like HSTS, RequireSSL or the cookie being set on the secure domain might contribute to this kind of issue.

[thisisata]

I already checked the session in my mvc action method set before sending the authentication request to Idp and that session is available after the response is received from Idp. So there is no issue with the httpcontext.current.session . this saml2.StateService is custom saml2 object, so there seems to be issue with this.

[thisisata]

I think there is some issue with the newer builds, because when i used the build number 2.3.1.0.20, that was created to resolve this issue(#38), every thing is working fine.

[i8beef]

You shoouldn't be using the session provider anymore. At some point that will go away. You have to use the CacheStateService instead. There was a change to cookie policy that most browsers implemented last year which means cookies are only sent if the request referrer is the same domain (which SAML, sometimes / usually isn't on the POST back from the IDP). This means when it comes back with the response from the IDP, the session cookie WON'T be sent, and the session won't be available to retrieve state from.

If you haven't made this switch yet, then this IS a duplicate of #38. Otherwise, let me know and we can dig deeper.

[thisisata]

Hi How are you, it works fine when I am using the 2.3.1.0.20 which was released to resolve issue #38 but when I use any new build then this issue is there. So I think what changes u made in 2.3.1.0.20 are not incorporated in following builds.

[i8beef]

Please post your (redacted) config section so we can see how you have things configured.

[thisisata]

Please find attached config file config.txt

[i8beef]

Ah, you're running over HTTP I take it? Yeah that isn't going to work. The state cache cookie is marked secure, and won't be sent over unsecured channels.

[thisisata]

Now i am running the site over https and this issue is resolved but now facing the new issue: Assertion signature is invalid Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: SAML2.Exceptions.Saml20Exception: Assertion signature is invalid

What happens if we use for this scenario ### omitAssertionSignatureCheck="true", I think its proceeding but then assertion.Subject.Value is "AAdzZWNyZXQx1dOR7KTkFV9F/wyUtIVtTPoV/byCSXINjJAzk40TY9KRH8pLRCbFwj5whY6T0J264CKXQbj+ejGDPkQLvMBpP/OnAEfkWBzwOTE7KJJpnEjUye8sVdemSc8=" which is of no use.

[thisisata]

Hi, this is the final samlResponse(file attached) from Idp, I checked it has SHA256 signing algorithm and that I skipped using omitAssertionSignatureCheck attribute to avoid "Assertion signature is invalid" exception but why its not decrypting the subject value = "AAdzZWNyZXQx1dOR7KTkFV9F/wyUtIVtTPoV/byCSXINjJAzk40TY9KRH8pLRCbFwj5whY6T0J264CKXQbj+ejGDPkQLvMBpP/OnAEfkWBzwOTE7KJJpnEjUye8sVdemSc8=" to plain text saml2Response.txt

[i8beef]

SHA256 is not supported by this library. See #20.

[thisisata]

why its not decrypting the subject value = "AAdzZWNyZXQx1dOR7KTkFV9F/wyUtIVtTPoV/byCSXINjJAzk40TY9KRH8pLRCbFwj5whY6T0J264CKXQbj+ejGDPkQLvMBpP/OnAEfkWBzwOTE7KJJpnEjUye8sVdemSc8=" to plain text saml2Response.txt

[i8beef]

I don't know. Your response example is encrypted so I can't see it.

[thisisata]

finally the user.identity,name gives this value "AAdzZWNyZXQx1dOR7KTkFV9F/wyUtIVtTPoV/byCSXINjJAzk40TY9KRH8pLRCbFwj5whY6T0J264CKXQbj+ejGDPkQLvMBpP/OnAEfkWBzwOTE7KJJpnEjUye8sVdemSc8=" why its not giving the plain text.how to get the authenticated user details.

[i8beef]

Which it would take from the decrypted Subject element. Again, its difficult to actually see what's going on there without decrypting that assertion and looking at the values. If the Subject contained an EncryptedElement instead of a NameId I'm pretty sure it would decrypt that, and then the RESULTING NameId inside that should be unencrypted at that point. I.e., it looks like your Subject value is encrypted ON TOP OF the XML encryption. I have never seen that behavior, but frankly I haven't used SAML in over a decade now, so there could be some new standard your IDP is enforcing that this library doesn't support.

I.e., it looks like you have multiple layers of encryption here, and the final one, the value of the NameId, doesn't get automatically decrypted, likely because that isn't a supported approach right now here. But its hard to say without seeing the actual assertion.

[thisisata]

allowUnsolicitedResponses=true can be used to avoid the issue of Session ExpectedInResponseTo missing.

[i8beef]

At the cost of opening your implementation to session replay attacks, just a warning. That setting is for people with things like identity provider landing pages where they login, and then want to click on a number of applications and get transferred directly into them without hitting a login handshake first. Its ill advised, just FYI.