Initial Setup -- Cannot Get SP and IDP Talking

[Sam Agnew]

Peter,

I think we have made some progress. I now get an error from the SP after successful authentication rather than an error from IDP saying that it doesn't know how to talk to SP.

What I am now getting after successful login on the loginpage (UserPassword auth via LDAP) is the following from the SP:

opensaml::FatalProfileException at (https://unixadmin.qatar-med.cornell.edu/Shibboleth.sso/SAML2/POST)

Unable to establish security of incoming assertion.

The shibd.log says:
2013-11-20 11:45:18 WARN Shibboleth.SSO.SAML2 [3]: detected a problem with assertion: Unable to establish security of incoming assertion.

The idp-process.log says:
11:45:17.730 - INFO [Shibboleth-Access:73] - 20131120T084517Z|207.162.244.209|idpt.qatar-med.cornell.edu:443|/profile/SAML2/Redirect/SSO|
11:45:17.766 - INFO [Shibboleth-Audit:1028] - 20131120T084517Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_8ac89e978b934d5ec1771ffea29681ef|https://unixadmin.qatar-med.cornell.edu|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://idpt.qatar-med.cornell.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_7eb3ab888531f740072f6ec8607f70cf|saa2012|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||_5359dddae06ba7c86cd49eb0196f7570||

I can provide any other information if it will help.
IDP: idpt.qatar-med.cornell.edu<http://idpt.qatar-med.cornell.edu>
SP:  unixadmin.qatar-med.cornell.edu<http://unixadmin.qatar-med.cornell.edu>
Secure URL: https://unixadmin.qatar-med.cornell.edu/secure (Apache, AuthType shibboleth)

Thanks!

Sam


On Nov 14, 2013, at 1:15 PM, Peter Schober wrote:

* Sam Agnew <saa2012 at qatar-med.cornell.edu<mailto:saa2012 at qatar-med.cornell.edu>> [2013-11-14 10:33]:
Error Message: No peer endpoint available to which to send SAML
response

The IdP does not have correct metadata for the SP (or the SP is
misconfigured).

12:23:30.805 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:206] - Relying party 'https://unixadmin.qatar-med.cornell.edu/secure' requested the response to be returned to endpoint with ACS URL 'http://unixadmin.qatar-med.cornell.edu/Shibboleth.sso/SAML2/POST'  and binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' however no endpoint, with that URL and using a supported binding,  can be found in the relying party's metadata

That seems pretty clear, no?

Above you have the entityID of the SP (which you for some reason set
to "https://unixadmin.qatar-med.cornell.edu/secure") and that contains
an ACS URL referencing the SAML metadata <AssertionConsumerService>
element, or rather its "Location" XML attribute.

So you now know what the IdP is looking for and you know that it
cannot find something in all the metadata it has configured that
matches these requirements.

Why this is the case is for you to debug. You could post the metadata
the IdP has on record for that SP, if needed.

Personally I find it unusual (and would recommend against it) that the
SP requests responses to be sent to plain http endpoints (instead of
https). If the IdP has metadata with https URLs in them the SP is
possibly misconfigured.

2013-11-14 12:15:19 ERROR Shibboleth.ArtifactResolution.SAML2 [1]: error while processing request: Invalid content type for SOAP message.

Unrelated, but of course ERRORs and WARNs are never good. Why Artifact
would play any role here is beyond me. Are you specifically trying to
use Artifact, e.g. to make the SP work on plain http without
generating security warnings from the browser?

I have an inkling that this probably relates to the SP and IDP not
able to agree on how to handshake the success but I'm not able to
figure out how to resolve this.

I don't know what "how to handshake the success" means, but first and
foremost the IdP does not have correct metadata for the SP.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


--
Sam Agnew
System Administrator
IT Department
Weill Cornell Medical College in Qatar



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131120/7cad0db7/attachment.html