The base file is here for comparison: https://github.com/apache/nifi-registry/blob/master/nifi-registry-resources/src/main/resources/conf/identity-providers.xml#L23
On Mon, Mar 19, 2018 at 5:34 PM, Bryan Bende <[email protected]> wrote: > For your first file, is what you showed there actually wrapped in > <identityProviders> </identityProviders> or is it exactly what you > showed? > > It may just be that you only copied/pasted the one provider, but the > root element is not <provider>, so as it is shown there it would not > parse. > > On Mon, Mar 19, 2018 at 2:54 PM, Scott Howell <[email protected]> > wrote: >> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>
