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