It looks like that error would happen if your identity-providers.xml contained invalid XML.
Did you start by modifying the identity-providers.xml file that was already there? Can you share the file, or the contents (removing anything sensitive)? On Mon, Mar 19, 2018 at 1:09 PM, Scott Howell <[email protected]> wrote: > So I was able to get the UI pulled up but now I am hitting a roadblock with > my identity-provider.xml. > > I am getting a number of errors like this: > > Caused by: org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'getIdentityProvider' defined in class path resource > [org/apache/nifi/registry/security/authentication/IdentityProviderFactory.class]: > Bean instantiation via factory method failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [org.apache.nifi.registry.security.authentication.IdentityProvider]: Factory > method 'getIdentityProvider' threw exception; nested exception is > java.lang.Exception: Unable to load the login identity provider configuration > file at: /opt/nifi-registry-0.1.0/conf/identity-providers.xml > at > org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:587) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1250) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1099) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:502) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:312) > ~[na:na] > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:310) > ~[na:na] > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200) > ~[na:na] > at > org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:251) > ~[na:na] > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1135) > ~[na:na] > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1062) > ~[na:na] > at > org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:815) > ~[na:na] > at > org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:721) > ~[na:na] > ... 43 common frames omitted > > I know it has to do with the identity-provider.xml but I have my setup just > like the documentation ask for. I turned on debug but was not able to see > anything different or better explanation from it. > > >> On Mar 19, 2018, at 10:06 AM, Kevin Doran <[email protected]> wrote: >> >> Ok, that use case should be fine. >> >> If it were an authorization issue you would see something in the logs saying >> that an authorization attempt failed and the server is responding with a >> 403. Just to be sure, can you enable debug logging if you haven't already, >> i.e., in your nifi-registry/conf/logback.xml file, change >> 'org.apache.nifif.registry' to debug: >> >> <!-- valid logging levels: TRACE, DEBUG, INFO, WARN, ERROR --> >> <logger name="org.apache.nifi.registry" level="DEBUG"/> >> >> If there is nothing being written to nifi-registry-app.log, it points >> towards a connection issue, so I would double check your host, port, and TLS >> settings. You'll have to get an HTTPS cert from a root CA or configure your >> ELB to trust your company's self-signed cert (again, not sure if/how to do >> this, but I assume there should be some way to configure it. It might >> require settings not exposed in the AWS web console.) >> >> On 3/19/18, 10:51, "Scott Howell" <[email protected]> wrote: >> >> Thanks Kevin, >> >> I am just using the ELB to go from the public subnet to the private >> subnet. I will not have multiple instances running of registry. >> >> I will say on my authorizers.xml there is one difference between my nifi >> instance. On my nifi instance I am using file-provider for >> nifi.security.user.authorizer in my nifi.properties. I don’t think from >> reading the documents for nifi-registry that I can use that. If there is a >> way that might be my problem. I was running into some issues with my nifi >> instance when I was using managed-authorizers instead of file-provider. >> >> >> >>> On Mar 19, 2018, at 9:35 AM, Kevin Doran <[email protected]> wrote: >>> >>> Hey Scott, >>> >>> Assuming you are using two-way TLS with client certificates for >>> authentication, I recommend configuring your ELB for TCP passthrough so >>> that the TLS handshake is between the end-client and the NiFi Registry >>> Server (in other words, no decryption/termination of the TLS connection >>> happens in the ELB). If you are using some other form of authentication >>> (e.g., LDAP), you will need to configure your ELB to trust the self-signed >>> key NiFi Registry is using. I'm not sure how to do that as I've never run >>> an ELB with that configuration before. >>> >>> Also, just a note about using an ELB with NiFi Registry: >>> >>> NiFi Registry is currently only supports single-instance use as persisted >>> data and in-memory state is not synced between multiple instances. Are you >>> hoping to use the ELB for actual load balancing, or is it just to take >>> advantage of other ELB features, such as forwarding and security group >>> rules? If the plan is to load balance multiple Registry instances, just be >>> aware that you will probably run into some unexpected behavior. (As you >>> mentioned using authorization, that is one case where I know the in-memory >>> cache of the persisted data will not refresh across instances, so even if >>> you were using some sort of shared network file system attached to multiple >>> Registry instances, such as EFS, it would not work the way you hope.) >>> >>> Hope this helps, >>> Kevin >>> >>> On 3/19/18, 10:20, "Scott Howell" <[email protected]> wrote: >>> >>> Thanks for the quick response. >>> >>> A couple of things I am seeing. >>> >>> 1. There is no error, I don’t see anything in the logs once the service >>> comes up. This is because the health check is not even hitting the instance >>> when secure. >>> >>> 2. Nothing interesting in the nifi-registry-app.logs. That was my concern >>> because on my nifi instance I can see the health check hitting the instance >>> from the ELB. This does not happen on the nifi-registry instance. I see >>> the service startup and it tells me what domain and port I can access the >>> UI but nothing else after that. >>> >>> 3. When I am on an instances in the same private subnet I am able to curl >>> to the instance I get the TLS SSL which tells me the keystore is on the >>> server. I am using a JKS keystore that is self-signed by the company I work >>> for. >>> >>>> On Mar 19, 2018, at 9:10 AM, Bryan Bende <[email protected]> wrote: >>>> >>>> Hello, >>>> >>>> What error are you getting when you cannot access the UI? >>>> >>>> Is there anything interesting in nifi-registry-app.log regarding >>>> authentication/authorization when this happens? >>>> >>>> Can you access the UI securely without going through the ELB? >>>> >>>> Thanks, >>>> >>>> Bryan >>>> >>>> >>>> On Mon, Mar 19, 2018 at 10:05 AM, Scott Howell <[email protected]> >>>> wrote: >>>>> I was able to stand up nifi-registry behind an AWS ELB non-secure. >>>>> Everything was working great and was able to access the UI anonymously. I >>>>> set up the authorization just like on my nifi instances along with the >>>>> authorizers and identity-provider. The service comes up without errors >>>>> and everything looks good but the health check does not pass and I cannot >>>>> access the UI to login. I was wondering if anyone else has ran into this >>>>> issue using nifi-registry. >>> >>> >>> >>> >> >> >> >> >
