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