26-Feb-2014 09:28
Feb 26 13:13:15 err tmm2[14202]: 014d0002:3: 8aab4afd: SSOv2 Error: No SP Connector attached to SAML SSO from assigned SAML resources matching authentication request. If ACS URL is present in authentication request it should match ACS URL from SP Connector. If Issuer is present in authentication request it should match entity_id from SP connector. Feb 26 13:13:15 err tmm2[14202]: 014d0002:3: 8aab4afd: SSOv2 Error(16) Unable to find SAML SSO/SP Connector object matching SAML Authn Request
It seems like everything matches up but I keep getting this error. I have checked the following:
AssertionConsumerServiceURL
Sent by SP http://somedomain.com/techy-test/wp-content/plugins/saml-20-single-sign-on/saml/www/module.php/saml/sp/saml2-acs.php/1" F5 ACS http://somedomain.com/techy-test/wp-content/plugins/saml-20-single-sign-on/saml/www/module.php/saml/sp/saml2-acs.php/1
Issuer ID
Sent by SP http://somedomain.com/techy-test/wp-content/plugins/saml-20-single-sign-on/saml/www/module.php/saml/sp/metadata.php/1 F5 SP Entity ID http://somedomain.com/techy-test/wp-content/plugins/saml-20-single-sign-on/saml/www/module.php/saml/sp/metadata.php/1
This data is from the APM logs so what other piece of information is it trying to match to determine the correct SP Connector?
27-Feb-2014 06:35
Found the issue (I needed to read the log more carefully) it turned out that I didn't have a SAML resource and I didn't have a resource on the webtop either. Error tends to be misleading but read as much as the log as you can.
18-Sep-2015 03:36
08-Jun-2018 20:32
Trying to solve the same problem. I'd like to show a webpage to our clients with some error message, instead of just the TCP reset they get now.
24-Jun-2019 12:48
any solution.. right. the APM shouldn't just stop and 'crash' the user it should provide for a graceful exit and message to the customer. The TCP reset is an indication of a condition that isn't being handled correctly by APM. Hoping you found a solution.
24-Jun-2019 15:48 - edited 21-Mar-2022 01:43
hi , thank you for your response. At the time I was writing my post above, we were running BIGIP v12.x, which is the one doing the TCP reset. F5 recognized the issue, and starting with v13 this has been solved with a proper HTML based error message. So, the solution is to upgrade to v13.x or v14.x (the latest version).