Skip to Content.
Sympa Menu

shibboleth-dev - RE: Checklist (difference between installation and tarball)

Subject: Shibboleth Developers

List archive

RE: Checklist (difference between installation and tarball)


Chronological Thread 
  • From:
  • To:
  • Subject: RE: Checklist (difference between installation and tarball)
  • Date: Thu, 15 Sep 2005 14:32:45 -0400

At 2:11 PM -0400 9/15/05, Howard Gilbert wrote:
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.


let's disable it for the time being....

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.]


yes, let's change the order....


Nate -- after taking a quick look at the draft doc, I'm assuming that I could follow your IQ directions, modifying the the config files within the newly installed SP, and it should work?

-- couple of quick nitswith the doc --

1) the bottom of the "second half" describes the process of generating the keys + certs; the bottom of that page has a link to what sseems to be the 3rd part; the 3rd part starts off by repeating the keys + certs info

2) at the bottom of the third part, I see this:

L. Access your Test Resource:

As a final step to the initial configuration, you will try to access this test resource. From here the service provider should be hardened and further configured for production deployment. While any InQueue identity provider should recognize this service provider, it is recommended that Example University be used, which is a known entity provided for this purpose.

you might want to move the 2nd sentence (... should be hardened...) further down... they're still testing at this point....



Archive powered by MHonArc 2.6.16.

Top of Page