allowing federation with mixed IDPs: some have ArtifactResolution and some do not

[Cantor, Scott]

On 3/3/17, 6:47 AM, "dev on behalf of Pascal Rigaux" <dev-bounces at shibboleth.net on behalf of pascal.rigaux at univ-paris1.fr> wrote:

> I'm looking at using "HTTP Artifact" for IDP->SP (to avoid "HTTP POST" which breaks browser navigation).
>
> Context: a federation where only a few IDPs have ArtifactResolution.

Artifact is stateful so it is very difficult to deploy and you'll never see it used heavily.

> I see various solutions:

My SP software is really not designed to use it, it doesn't have any clean way to select it unless it's forced to. I believe you can probably reorder the priority so it always tries to pick Artifact first and that's probably what you'd have to do, but I don't actually recall how to do it. I think it may be driven by the order of the bindings in the protocols.xml file.

> if the AuthnRequest have neither AssertionConsumerServiceURL nor ProtocolBinding, the IDP chooses the first
> AssertionConsumerService from SP metadata.

The IdP isn't the issue, the SP decides this because it always sends the URL. In practice anyway.

> choose Artifact AssertionConsumerServiceURL only if the IDP metadata has ArtifactResolution.
>  Looking at shibboleth-sp code, it seems it needs a little rework.

The SP already does that check, as far as I'm aware, but it always picks POST if it can by default.

> Did I miss something?

Yes, do something more productive with your time than force use of an undeployable binding. (*)

-- Scott

(*) It's not really undeployable in SAML 2.0, and Shibboleth 3 does provide hooks for doing what you have to do with it, which is to expose dedicated URLs for different server nodes and communicate out which node to fetch the assertion from. Nobody wants to deploy that way because load balancers are much simpler when you just expose one fixed location for everything.