Enabling ECP in SP 2.4.3

[Scott Koranda]

> On 9/9/11 8:56 PM, "Scott Koranda" <skoranda at gmail.com> wrote:
> >
> >(not sure if you are addressing me or the OP...)
> 
> You; I was trying to find out if there was documentation somewhere that
> was incorrect.
> 
> >- add a discovery service as early investigation into federation,
> >resulting in
> 
> I think it's accidental that it works in that order. I guess it might.
> 
> The intention is that the protocol initiators come before the discovery.
> You don't need the copy that's at the end, it won't ever run.
> 

Ah, I see. 

In the interest of improving the documentation...

I have gone through and re-read all the documentation on this
page 

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionInitiator

to understand how I convinced myself that the second SAML2
initiator at the end was necessary.

I think it comes down to 

- not realizing the impact of this statement:

"Typically, the deployer configures a chain in which a number
of SSO protocols are listed, in order of preference, followed
by a handler for some kind of "discovery" protocol that will
take over if the IdP is not known or provided via a query
string parameter"

- instead fixating on these two statements, one for the
  chaining initiator and one for the discovery service
initiator:

"Identified by type="Chaining", wraps a sequence of
SessionInitiator handlers so that they run in series. The
series ends when a handler indicates that a response to the
browser was returned. If no response is sent, an error
results."

"Used alone, the SAMLDS handler will simply display an error
when the result is returned because it cannot itself cause an
authentication request to be generated."

But after re-reading the documentation, I have no solid
suggestion for how to improve it--it says in order what it
needs to say.

Thanks,

Scott K