Andre, Based on the error, it looks like you've retained your existing authorizers.xml but upgraded the nifi.security.user.authorizer property in your nifi.properties. These two are related. The authorizers.xml file defines the available Authorizers (and now UserGroupProviders and AccessPolicyProviders). The nifi.security.user.authorizer property in nifi.properties defines which authorizer to use (via the identifier) from the authorizers.xml file. If you want to retain your existing authorizers.xml you'll want to keep that property unchanged as well.
I'll add a note in the migration guide to make sure this is clear. Thanks Matt On Tue, Oct 31, 2017 at 12:05 AM, Andre <andre-li...@fucs.org> wrote: > Matt, > > I did some investigation and it seems like if you simply copy the old > authorizers.xml into the new setup NiFi fails with > > ERROR [main] o.s.web.context.ContextLoader Context initialization failed > org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired > dependencies failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Could not > autowire > method: public void > org.apache.nifi.web.NiFiWebApiSecurityConfiguration. > setOtpAuthenticationProvider(org.apache.nifi.web.security. > otp.OtpAuthenticationProvider); > nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'otpAuthenticationProvider' defined in class path resource > [nifi-web-security-context.xml]: Cannot resolve reference to bean > 'authorizer' while setting constructor argument; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'authorizer': FactoryBean threw exception on object > creation; nested exception is java.lang.Exception: The specified authorizer > 'managed-authorizer' could not be found. > > And similar errors for JWT as well. > > Given that populating the new authorizers.xml with the <authorizer> element > from the old authorizers.xml seems to solve the issue, seems to me like we > expect the file to contain references to the new authorizers syntax > despite using the legacy syntax? > > Doesn't seem to be a show stopper but I reckon we should document it. > > Cheers > > > > On Tue, Oct 31, 2017 at 1:43 PM, Matt Gilman <matt.c.gil...@gmail.com> > wrote: > > > Andre, > > > > While 1.4.0 introduces a more granular authorizers configuration, the > > existing 1.3.0 configurations should still be valid. What was breaking > for > > you? > > > > Matt > > > > Sent from my iPhone > > > > > On Oct 30, 2017, at 10:24 PM, Andre <andre-li...@fucs.org> wrote: > > > > > > Folks, > > > > > > I was looking at the upgrade process from 1.3.x to 1.4.0 and it seems > to > > me > > > we introduced a breaking change around the authorizations? > > > > > > When I look at the 1.4.0 authorizers.xml and its version 1.3.0 there's > a > > > massive discrepancy on the XML tree and the existing 1.3.x version does > > not > > > seem to work out of the box on 1.4.0 ? > > > > > > Looking at the docs I couldn't find evidence of the migration being > fully > > > documented? I suspect users may be able to find their way by adjusting > > the > > > instructions for the 0.x upgrade, but shouldn't we have clear > > instructions > > > on the upgrade from 1.3.x to 1.4.0? > > > > > > Cheers > > >
