Shibboleth Developers

["Scott Cantor" <>]

> as more and more info vendors upgrade to Shib v1.3, should we be 
> encouraging them to make endpoints available that support the 
> Artifact profile? Clearly, only IdPs running Shib v1.3 would be able 
> to support this -- but would it be a better solution for them?

Any given SP already supports it unless you work to avoid it. The problem is
that a broken and WAYF-centric Shib design makes using it very difficult
because if you pick the artifact location initially as "shire", it will
cause problems since the Shibboleth AuthnRequest isn't profile aware.

Few production IdPs support artifact anyway because it introduces state.
Even in 2.0, the hassle of setting up directly addressable uniquely named
and indexed SSL endpoints will not really encourage people to use it. But
the WAYF issues have to be addressed regardless before any multi-profile
environment will work well.

The problem isn't "supporting" the profile, it's leveraging it due to
limitations imposed by the request protocol, the WAYF, and the "separate
endpoint" requirement of the SP in that version.

Actually processing artifacts isn't something an SP deployer has to do
anything special to enable, apart from leaving the default configuration of
/SAML/Artifact intact. An IdP-first flow is the more likely way to make use
of it in the general case, but IdP-first flows are considered more viable
than they usually are in practice for most services, IMHO.

Having a lot of options to choose from in SAML wasn't really ever targeted
at our kinds of N x N apps. It's more for partner to partner outsourcing
where everything is nailed down and you pick which to use in advance.

-- Scott