Shibcas and Shibboleth IdP 3.4.6

[Cantor, Scott]

> This may or may not be an issue anybody here would be able to address, as it
> appears to be a Shibcas issue, but we wanted to post here just in case.

That is affected, yes. I'll add it to the Release Notes. The need for the security fix necessitated violating the normal rules around API stability for plugins, there just wasn't a good alternative.

It is also a bug in the plugin, because it's using implementation code directly, which is a no-no, and this is why. While the API changes were breaking, it's the use of the ExternalAuthenticationImpl class directly in that flow file that renders it formally incorrect. That isn't specifically why it broke, but it's critical that people stop relying on implementation classes in custom flows.

> Does anyone have any feedback on whether we would still be vulnerable to
> such an attack?  Or, any suggestions for updating to Shibboleth IdP 3.4.6 while
> using Shibcas?

The change made should mirror the patch applied to the external-authn-flow.xml file in the redirection step at the top, but it's still an unsupported approach. Direct use of the External flow would be a "supportable" way to do this, alternatively one would need to build one's own copy of the non-API class involved to avoid that dependency.

But the breaking change is to the context class' constructor.

-- Scott