Initial Setup -- Cannot Get SP and IDP Talking
peter.schober at univie.ac.at
Tue Nov 5 03:59:38 EST 2013
* Sam Agnew <saa2012 at qatar-med.cornell.edu> [2013-11-05 08:26]:
> We are trying to set up a new Shibboleth implementation. Initially,
> we set up an IDP on a Windows 2012 server box with a Centos 6 box as
> the SP. We were getting the message validation errors that we have
> read are often a result of time differences. Although we set up NTP
> on both boxes we thought it might be simpler to configure both IDP
> and SP on the same Centos box.
This is not in fact any easier but certainly possible.
> We followed a tutorial at:
That doesn't cover running the IdP and SP inside the same webserver
(or prevent two webservers fighting over tcp port 443).
> Since we had an SP configured on the Centos box we simply installed
> the IDP there as well. We can contact the IDP and even its login
> page (https://unixadmin.qatar-med.cornell.edu/idp/login.jsp) however
> we cannot get the SP to successfully use the IDP. We get varients on
> the following:
Assuming Apache httpd proxies everything in /idp to Apache httpd and
serves up the rest itself (incl. mod_shib)...
> Unable to locate metadata for identity provider (https://unixadmin.qatar-med.cornell.edu/idp/shibboleth)
That just means that. The SP has no metadata for the IdP.
> 2013-11-05 10:19:59 ERROR XMLTooling.libcurl.InputStream : error
> while fetching https://unixadmin.qatar-med.cornell.edu: (22) The
> requested URL returned error: 403 Forbidden
If that is the entityID (or the URL for metadata) of the IdP then it
does not match the above entityID which ends in "/idp/shibboleth".
Also maybe the machine does not resolve the correct hostname or virtal
host from localhost itself.
If you just want to make sure everything works cofigure the SP to use
metadata for the IdP from the local file system, by default from
> As far as we can see, however, the URL works. Visiting the URL
> (https://unixadmin.qatar-med.cornell.edu/idp/shibboleth) outputs an
> XML file:
Not that fetching metadata from the entityID itself is recommended for
production use, but try to fetch that URL from the machine itself,
e.g. using curl or wget (or elinks or telnet or whatever).
More information about the users