Odd Duo Exception after upgrading to 3.3.0 from 3.2.0

Christopher Bongaarts cab at umn.edu
Thu Mar 16 18:45:46 EDT 2017


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    %%



More information about the users mailing list