Odd Duo Exception after upgrading to 3.3.0 from 3.2.0

[Cantor, Scott]

On 3/28/17, 12:55 PM, "users on behalf of Christopher Bongaarts" <users-bounces at shibboleth.net on behalf of cab at umn.edu> wrote:

> This most recent one was extra confusing to me, as it seemed awfully
> late in the game for the IdP to not have an auth flow descriptor for the 
> Duo flow, seeing as how it had recently finished running to authenticate 
> me.... :/  So I figure it was that somehow the descriptor got wired in
> in one place, or the global Config class kinda-sorta wired it in, but it 
> didn't end up in the AFD list that got injected into the StorageManager 
> somehow (but I'm not sure how - the default storage manager bean def is 
> just injecting a ref to the main shibboleth.AvailableAuthenticationFlows 
> list bean).

That's why we don't support this sort of thing. Our objects are free to copy those collections for their own internal purposes, and that particular example is a common case, it copies the collection of AFDs into a map as it filters out any nulls. There are similar cases all over where the injected collections are copied. Generally if we intend that a collection be "live", we use a service abstraction that crosses an explicit locking boundary so that it's safe to change on the fly just in case. The access control layer is an example of that.

So likely what happened is that incidental ordering issues caused the collection to get injected and processed in a different order from before, and it was purely coincidental that it ever worked.

We do not provide an API to register flows or the associated objects at runtime, and at present there is absolutely no way to register an authentication flow without deployer modifications to configuration files. That would not be possible given the current design because we don't have a service layer between the components using the information and the information itself. No amount of game playing will reliably avoid that step.

-- Scott