Shibboleth Developers

["Howard Gilbert" <>]

Right now you can say N to the IdP and Y to the SP install. If that is a
problem, I can will disable the IdP question in the beta distribution.

If the SP is to match its description in the Metadata and its configuration
in the sp.xml, then it has to run on port 9443 and have a cert for
sp.example.org.

Digression: The IdP doesn't contact the SP directly, but only indirectly by
sending the handlerURL (formerly shire URL) as the Browser redirect URL.
Therefore, every tester in every different location can use sp.example.org
as their SP host name provided that the machine on which the Browser is
running associates that hostname with the IP address of the machine on which
they have installed the test SP. You can do that by setting the hosts table
on the machine on which you are running the test Browser, but at some point
this trick becomes annoying.

The alternative is to put a real host name and port number to replace the
dummy in /usr/local/shibboleth-sp/etc/sp.xml.

<Sessions lifetime="7200" timeout="3600" checkAddress="false"
handlerURL="https://sp.example.org:9443/shibboleth-sp/Shibboleth.sso"; 
handlerSSL="false" idpHistory="true" idpHistoryDays="7">

If you change the handleURL to be a real host name, then that gets sent to
the IdP as the "shire" and becomes the address to which the Browser is
redirected after signon. However, if this is an HTTPS URL, then the Tomcat
on which the test SP is running has to have a certificate that matches this
name and its {tomcat}/conf/server.xml has to have a <Connector> that
associates that certificate with the port number in the handlerURL.

Summary: the handler URL in the sp.xml configuration of the SP has to
conform to the server.xml in the Tomcat config. Otherwise the POST comes
back from InQueue and goes to the wrong machine, wrong port, or you get the
annoying popup that the cert name doesn't match.

Also, if we are going to use InQueue as the test, then we probably want to
flip in the distribution the order and default for the two WAYF definitions
in sp.xml:

<!-- This default example directs users to a specific IdP's SSO service. -->
<SessionInitiator isDefault="true" id="example"
Location="/WAYF/idp.example.org"
Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
wayfURL="https://idp.example.org:443/shibboleth-idp/SSO";
wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>
                                
<!-- This example directs users to a specific federation's WAYF service. -->
<SessionInitiator id="IQ" Location="/WAYF/InQueue"
Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
wayfURL="https://wayf.internet2.edu/InQueue/WAYF";
wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>

So that the IQ comes first and isDefault. [I suppose that isDefault should
be the determining factor here, but I believe the code currently follows the
"comes first" rule.]

________________________________________
From: Nate Klingenstein 
[mailto:]
 
Sent: Thursday, September 15, 2005 11:54 AM
To: 

Subject: Re: Checklist (difference between installation and tarball)

I may very well have misheard, but I thought we developed a consensus on the
last development call that we were moving towards a default environment of
testing against InQueue's Example State rather than continuing to distribute
both the IdP and SP. The documentation I wrote reflects this.

I think the best way I can describe what I thought the installation process
would look like is simply to point to the documentation I've written. The
first half is in http://shibboleth.internet2.edu/guides/sp/javainstall.html
and second half at
http://shibboleth.internet2.edu/guides/sp/initialtomcat.html . The original
set of docs I wrote for the .zip install are at
http://shibboleth.internet2.edu/guides/sp/javazipinstall.html .