How to specify DiscoFeed when remote shibd used?

[Gernot Hassenpflug]

Hello all,

Background
----------

I've been working for some months with SP version 2.4 and IdP version
2.1.5 on CentOS4.8 (details in previous posts on this list: use of
nginx as a front-end server terminating the incoming SSL connection,
and apache 1.3 as a back-end server).

The configuration files are as supplied in the source packages, with
changes to the required parameters made according to the
documentation. No copnfiguration files have been downloaded from other
internet sites or anything like that.

For finding an IdP, I have used successfully 3 different
configurations. These are:

1) direct connection to a single IdP (no discovery service).

2) DS (discovery service) using the Japanese Shibboleth federation, on
   which our test servers are registered.

3) And since last week EDS (embedded discovery service) on the SP, for
   which the DiscoFeed configuration is necessary.

The relevant shibboleth2.xml lines of the working EDS configuration is
as follows:

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://sptest3.manaba.jp/shibboleth-ds/index.html">
     SAML2 SAML1
</SSO>

<!-- JSON feed of discovery information. -->
<Handler type="DiscoveryFeed" Location="/DiscoFeed"/>


<MetadataProvider type="XML" uri="https://metadata.gakunin.nii.ac.jp/gakunin-test-metadata.xml"
      backingFilePath="federation-metadata.xml" legacyOrgNames="true" reloadInterval="7200">
    <MetadataFilter type="RequireValidUntil" maxValidityInterval="1296000"/>
    <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/training-fed.crt"/>
</MetadataProvider>

Alternatively, the metadata could be a static file (often used when I
work with non-registered test servers, such as sptest3 in this case):

<MetadataProvider type="XML" file="/etc/shibboleth/gakunin-test-metadata-gernot.xml"/>

Remote shibd configuration
--------------------------

Although not recommended according to the documentation, I am tasked
with exploring the use of shibd on a remote server. 

For this purpose I prepared two identically-configured servers (same entityID).
On the first (xxx.xxx.xxx.101), I stopped shibd, and set the TCPListener as follows:

<TCPListener address="xxx.xxx.xxx.103" port="1600"/>

As I understand it, this sets the IP address and port on which the web
service now looks for shibd connection.

On the second (xxx.xxx.xxx.103), I stopped httpd (and other services not related to
shibd), and set TCPListener as follows:

<TCPListener address="xxx.xxx.xxx.103" port="1600" acl="xxx.xxx.xxx.101 xxx.xxx.xxx.103 127.0.0.1"/>

As I understand it, the shibd daemon listens on this IP address and
port, and permits access from xxx.xxx.xxx.101 (I don't think I need
the other 2 addresses in the ACL).

iptables on the shibd server (xxx.xxx.xxx.103) has been opened to
allow access from the httpd server (xxx.xxx.xxx.101) on TCP port 1600.

Problem
-------

The above remote shibd setup works fine for the first 2 types of
configurations (direct use of a single IdP, and use of DS). However,
DiscoFeed no longer works, so EDS cannot be implemented.

When I try to access DiscoFeed, as in

curl -k https://sptest3.manaba.jp/Shibboleth.sso/DiscoFeed

then I get an HTML error page that "The page you are looking for is
temporarily unavailable. Please try again later."

On the other hand, the Status and Metadata pages appear perfectly fine.

I have tried to set DiscoFeed to the full path, like this:

<Handler type="DiscoveryFeed" Location="https://sptest3.manaba.jp/Shibboleth.sso/DiscoFeed"/>

However, there was no change. If I try to set the path to use the IP
address of the machine on which the shibd is running
(xxx.xxx.xxx.103), then there is no connection made at all.

I have set most native.logger and console.logger variables to DEBUG
but there are no error messages I can see in either shibd.log or
shibd_warn.log.

As it stands, I have gotten stuck after experimenting and reading
through various bits of documentation on the Shibboleth site, so if
there are any hints as to what I should be looking for, I would very
much appreciate it.

Best regards,
-- 
Gernot Hassenpflug