SP Simplified Protocol Configuration and artifact resolution

[Cantor, Scott]

On 11/22/11 5:16 PM, "Scott Koranda" <skoranda at gmail.com> wrote:

>Is that the correct approach?

It's probably simpler to just comment out the other bindings from the
protocol definition file. Or possibly just reorder the bindings, I think
that will work also. But you'll get failures with any IdP that doesn't
support artifacts. It's really all or nothing.

>Since protocols.xml includes
>
><Binding id="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
>path="/SAML2/Artifact" />
>
>will there be a conflict between the initiator plugin
>resulting from the <SSO> element with that I have explicitly
>configured?

You're not meant to use both approaches, either/or is much safer. I should
update the page. I don't know what it will do, probably supersede the
original handler. If there's already an artifact ACS in place, you just
have to get it used. That's what doesn't really work well because the
indexes aren't clear.

You have to specify an acsIndex in the handler or on the URL or
RequestMap. There's no other way to control the response. The index has to
map to the *internal* index, and if you really want to use that, it's best
to use an index far afield from anything else so it's explicitly under
your control.

To Peter's suggestion, the indexes in the metadata mean nothing to the SP
and they rarely match the indexes it knows for endpoints. Which is why
using acsByIndex is a bad idea and should really not be used with this SP.
It just doesn't work with this design.

My advice is experiment with it, turn up the logging if you need to, and
see what happens.

But the main point is what I said at the top. Once you pick artifact,
you're dead if the IdP doesn't support it. It doesn't fall through.

-- Scott