Odd Duo Exception after upgrading to 3.3.0 from 3.2.0

[Strickland, David R]

Christopher,

Thanks, this is really helpful. We were still scratching our heads about how
you got this working based on your earlier email.

Since you're going with native Duo support, are there any notable
differences between the native Duo flow and the Unicon plugin? I can see the
advantage of not having to fiddle with a third party plugin, but I couldn't
find a compare/contrast of the two methods anywhere.

Thanks!
David

David Strickland
Lead Software Engineer
Identity and Access Management
The University of Texas at Austin

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Christopher
Bongaarts
Sent: Thursday, March 16, 2017 5:46 PM
To: users at shibboleth.net
Subject: Re: Odd Duo Exception after upgrading to 3.3.0 from 3.2.0

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-cl
ass>
          <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,${id
p.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    %%

--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6162 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20170316/51cc8997/attachment-0001.p7s>