Here is my file
<provider>
<identifier>ldap-identity-provider</identifier>
<class>org.apache.nifi.registry.security.ldap.LdapProvider</class>
<property name="Authentication Strategy">SIMPLE</property>
<property name="Manager DN">cn=Manager,dc=mobilgov,dc=com</property>
<property name="Manager Password”>redacted</property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url”>redacted</property>
<property name="User Search Base">ou=users,dc=mobilgov,dc=com</property>
<property name="User Search Filter">uid={0}</property>
<property name="Identity Strategy">USE_DN</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
Here is my authorizers.xml
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
<class>org.apache.nifi.registry.security.authorization.file.FileUserGroupProvider</class>
<property name="Users File">conf/users.xml</property>
<property name="Legacy Authorized Users File"></property>
<property name="Initial User Identity 1”>redacted</property>
</userGroupProvider>
<accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>org.apache.nifi.registry.security.authorization.file.FileAccessPolicyProvider</class>
<property name="User Group Provider">file-user-group-provider</property>
<property name="Authorizations File">conf/authorizations.xml</property>
<property name="Initial Admin Identity”>redacted</property>
<property name="NiFi Identity 1"></property>
</accessPolicyProvider>
<authorizer>
<identifier>managed-authorizer</identifier>
<class>org.apache.nifi.registry.security.authorization.StandardManagedAuthorizer</class>
<property name="Access Policy
Provider">file-access-policy-provider</property>
</authorizer>
</authorizers>
> On Mar 19, 2018, at 12:59 PM, Bryan Bende <[email protected]> wrote:
>
> 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.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
