Odd Duo Exception after upgrading to 3.3.0 from 3.2.0

[Christopher Bongaarts]

There was one more adjustment required in order to make single sign-on 
work for Duo.  Had to manually add one line to the end of the 
shibboleth.AvailableAuthenticationFlows list in 
conf/authn/general-authn.xml:

   <ref bean="authn/Duo"/>

Without it, the IdPSession refused to save the authn result:

2017-03-27 16:26:57,028 - WARN 
[net.shibboleth.idp.session.impl.StorageBackedIdPSession:573] - No flow 
descriptor installed for ID authn/Duo, unable to save result to storage

I'm not sure how the rest of the authn stuff managed to work without 
this - maybe it's part of the "magic" of the initial-authn stuff, or the 
programmatic AFD registration sorta-kinda worked for some things in 3.3.0.

I'm looking forward to throwing this away and building "real" MFA flows 
with the built-in Duo support :)

On 3/16/2017 5:45 PM, Christopher Bongaarts wrote:
> So it turns out I was mistaken about this.  Duo was not actually 
> working in this case, it just allowed the IdP to load successfully.  
> Trying to invoke a Duo-protected login lead to an error, I think 
> (something like the flow couldn't be found). Ultimately after fiddling 
> with it long enough, we managed to get things working again by 
> tweaking the web.xml file and the layout of the plugin jar.
>
> This is essentially what we ended up with.  If I was planning to 
> continue using the Unicon plugin instead of the 3.3 native Duo/MFA 
> flow support, there is probably some cleanup that could be done. This 
> is mostly intended as a hint in case other folks are in the same 
> situation.
>
> - Used the stock 3.3.0 web.xml file plus our local additions, and 
> added a paths to the servlet contextConfigLocation:
>
> @@ -87,7 +87,7 @@
> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
>
>          <init-param>
> <param-name>contextConfigLocation</param-name>
> - <param-value>${idp.home}/system/conf/mvc-beans.xml, 
> ${idp.home}/system/conf/webflow-config.xml</param-value>
> + 
> <param-value>classpath*:/META-INF/net.shibboleth.idp/webflow-config.xml,${idp.home}/system/conf/mvc-beans.xml, 
> ${idp.home}/system/conf/webflow-config.xml</param-value>
>          </init-param>
>          <init-param>
> <param-name>contextClass</param-name>
>
> - Unpacked, rearranged, and repacked the shibboleth-duo-auth-1.0.1.jar 
> file:
>
> -- Moved META-INF/shibboleth-idp/conf/webflow-config.xml to 
> META-INF/net.shibboleth.idp/webflow-config.xml
> -- Moved META-INF/shibboleth-idp/conf/global.xml to 
> META-INF/net.shibboleth.idp/postconfig.xml
> -- Moved META-INF/shibboleth-idp/flows to 
> META-INF/net/shibboleth/idp/flows
> -- Removed net/unicon/iam/shibboleth/idp/authn/duo/webflow/* (this was 
> the programmatic hook for wiring in the flows that happens 
> automatically in 3.3.0 if you get the flows in the right place; having 
> it caused errors about redefining or reregistering the flows)
>
> With these changes, the plugin jar ended up with enough things in the 
> "right" place to be found, and Duo is working for us in 3.3.0.
>
> Sorry for any wild goose chasing....
>
> On 2/3/2017 4:45 PM, Cantor, Scott wrote:
>> On 2/3/17, 5:32 PM, "users on behalf of Christopher Bongaarts" 
>> <users-bounces at shibboleth.net on behalf of cab at umn.edu> wrote:
>>
>>>   The two changes we made that we effectively reverted to the 3.3.0 
>>> delivered version were the contextConfigLocation
>>> values, which we had modified as directed by the Duo module docs.  
>>> The one at the webapp level is different between
>>> (stock) 3.2.1 and (stock) 3.3.0:
>> Right, but one is a superset of the other, and their flow couldn't 
>> have been depending on the new values.
>>
>> What we changed in 3.3 was just to deprecate the original hook we 
>> provided and to formally define a pre- and post- hook that could 
>> explicitly control its interactions with our own system beans.
>>
>>> So our mucking with the values, and/or the (lack of) change to the 
>>> webapp-level parameter, apparently is enough to make
>>> the IdP unable to find certain parent flows (Mark's couldn't find 
>>> the c10n flow; in our case it couldn't find the abstract
>>> authn flow).
>> There's an explicit mechanism in 3.3 for jars to define flows to the 
>> system on the fly now, so the original cause of the problem, whatever 
>> it is, should be fixed for extension authors in the future. There 
>> really was no way to define flows without copying files into 
>> idp.home/flows/, that was simply a requirement pre-3.3.
>>
>> I know roughly what the problem was, I just don't know how the 
>> web.xml changes could have fixed it. Very weird.
>>
>> -- Scott
>>
>>
>

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%