Shibboleth IdP V3 /Shibboleth/Redirect

[mat houser]

We had the same problem last summer I think. For some reason we had
configured SAML:2.0:bindings:... configured for
idp/profile/Shibboleth/... in our handler.xml in addition to the
idp/profile/SAML2 ones. The only place where the idp/profile/Shibboleth
URLs were used was in the InCommon federation metadata, so when I was
testing out IdP v3 it was working for everybody except InCommon SPs.

I'm not really sure why we had modified the handler.xml to do this, or
indeed why we had our metadata published this way, but it looks like we
weren't totally alone in having done this. 

Since the IdP worked with both profile URLS I changed what we had published 
with InCommon a while before we deployed v3 to production and it just quietly
switched over to the correct profile URLs on v2.

-mat


-- 
-------------
mat:houser
mhouser at uwm.edu
uwm:uits:iam-support
-------------


On Thu, 21 Jan 2016, Cantor, Scott wrote:

> The metadata was submitted before my time here, so I am unsure why this
> has remained like that other than it works. On the actual idp-metadata file of
> the v2 IdP, those bindings aren't there.

That metadata is irrelevant to any and everything. The only way that changes would be if you modify the old IdP's handler.xml file, I believe (short of doing web rewrites of course).

> Of course if I were to change those
> bindings to /idp/profile/SAML2/ it would break our current instance. My
> question is: Is there a way to add these bindings to the new IdP so that
> during cutover they work?

Unfortunately, the only practical way for the moment is to modify a system file, system/conf/webflow-config.xml

The ability to change the flow locations of the built-in flows isn't really exposed right now. It's possible to do a *lot* of work to avoid touching that file but the end result is no easier to maintain across upgrades so it's not really worth it.

> Would a URL redirect be the best way to tackle this?

A rewrite, not a redirect. And not really, that would break the IdP's enforcement of message location checking, requiring additional changes to make that work.

-- Scott