Just to provide a quick update on this, I posted my findings here: https://issues.apache.org/jira/browse/NIFI-2476
Long story short, there is nothing actually wrong with the authorization code, the issue stemmed from the fact that the DN was being show in different formats in different places. - openssl showed it as CN=ca.nifi.apache.org, OU=NIFI - keytool showed it as OU=NiFi, CN=ca.nifi.apache.org - NiFi received it as OU=NiFi, CN=ca.nifi.apache.org So the Initial Admin in authorizers.xml has to be OU=NiFi, CN= ca.nifi.apache.org. Currently the certs coming from nifi-toolkit always come across with the OU before the CN. Since most people are more familiar with seeing the CN come first, I'm suggesting (if possible) we have the toolkit produce it with the CN before the OU for the 1.0.0 release. On Mon, Aug 8, 2016 at 10:42 AM, Bryan Bende <[email protected]> wrote: > Andy, > > Thanks for reporting this issue, I'm going to attempt to reproduce shortly. > > One question... in your last email when you said you changed > authorizers.zml to have OU=NiFi, CN=ca.nifi.apache.org , did you wipe out > authorizations.xml before restarting? > > The policies for the Initial Admin are only generated when no other > policies exist. So if you started the app once with CN=ca.nifi.apache.org, > OU=NIFI you would already have policies for that user, and it wouldn't > generate policies OU=NiFi, CN=ca.nifi.apache.org unless you went in and > cleared out authorizations.xml (either remove the file completely, or > delete everything between <policies></policies>). > > Thanks, > > Bryan > > > On Fri, Aug 5, 2016 at 8:51 PM, Andy LoPresto <[email protected]> > wrote: > >> Ok, I changed the authorizers.xml IAI to “OU=NiFi, CN=ca.nifi.apache.org” >> and it fails with the same message, so it does not appear to be a simple >> String comparison issue. >> >> Andy LoPresto >> [email protected] >> *[email protected] <[email protected]>* >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Aug 5, 2016, at 5:42 PM, Andy LoPresto <[email protected]> wrote: >> >> After using Incognito browsers and re-importing the CA certificate as a >> client cert, I was able to connect to the app through the browser, but the >> authorization does not seem to be working: >> >> logs/nifi-user.log >> >> 2016-08-05 17:19:42,904 INFO [main] o.a.nifi.authorization.FileAuthorizer >> Populating authorizations for Initial Admin: CN=ca.nifi.apache.org, >> OU=NIFI >> 2016-08-05 17:19:42,932 INFO [main] o.a.nifi.authorization.FileAuthorizer >> Authorizations file loaded at Fri Aug 05 17:19:42 PDT 2016 >> 2016-08-05 17:35:30,943 INFO [NiFi Web Server-18] >> o.a.n.w.a.c.IllegalStateExceptionMapper java.lang.IllegalStateException: >> Kerberos ticket login not supported by this NiFi.. Returning Conflict >> response. >> 2016-08-05 17:35:30,958 INFO [NiFi Web Server-77] >> o.a.n.w.s.NiFiAuthenticationFilter Attempting request for (OU=NIFI, CN= >> ca.nifi.apache.org) GET https://localhost:10443/nifi-a >> pi/flow/current-user (source ip: 127.0.0.1) >> 2016-08-05 17:35:30,960 INFO [NiFi Web Server-77] >> o.a.n.w.s.NiFiAuthenticationFilter Authentication success for OU=NIFI, >> CN=ca.nifi.apache.org >> 2016-08-05 17:35:30,974 INFO [NiFi Web Server-77] >> o.a.n.w.a.c.AccessDeniedExceptionMapper OU=NIFI, CN=ca.nifi.apache.org >> does not have permission to access the requested resource. Returning >> Forbidden response. >> >> Is the reversed order of the RDNs just an artifact of the logging, or is >> the comparison being done between Strings as opposed to the actual “object” >> model of the DN? I have written a utility method in CertificateUtils# >> compareDNs(String dn1, String dn2) which will parse the DNs and compare >> for equality regardless of order if this is the issue. It appears that the >> authentication was successful but the permissions are not available for >> that user? >> >> >> Andy LoPresto >> [email protected] >> *[email protected] <[email protected]>* >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Aug 5, 2016, at 5:29 PM, Andy LoPresto <[email protected]> wrote: >> >> Joe, >> >> I was able to verify all signatures, build, verify the contrib-check, and >> start an unsecured instance and use it as normal. >> >> However, when I attempted to deploy secured instances (using the tool >> contributed in NIFI-2193), I encountered issues with authentication. >> >> Steps to recreate: >> >> 1. Build the app as normal. >> 2. Use the tis-toolkit in “standalone” mode to generate a CA key & >> certificate, generate a node certificate, use the CA key to sign the node >> certificate, and then combine the CA certificate and key into a PKCS12 >> keystore to use as a temporary client certificate to gain access to the UI. >> From the unzipped nifi directory: >> hw12203:/Users/alopresto/Workspace/scratch/release_verification/nifi-1.0.0-BETA >> (master) alopresto >> 🔓 5s @ 17:06:16 $ cd nifi-toolkit/nifi-toolkit-asse >> mbly/target/nifi-toolkit-1.0.0-BETA-bin/nifi-toolkit-1.0.0-BETA/ >> hw12203:...toolkit-assembly/target/nifi-toolkit-1.0.0-BETA-bin/nifi-toolkit-1.0.0-BETA >> (master) alopresto >> 🔓 3s @ 17:06:20 $ ./bin/tls-toolkit.sh standalone -c ca.nifi.apache.org >> 16/08/05 17:07:00 INFO standalone.TlsToolkitStandaloneCommandLine: No >> nifiPropertiesFile specified, using embedded one. >> 16/08/05 17:07:00 INFO standalone.TlsToolkitStandalone: Running >> standalone certificate generation with output directory >> ../nifi-toolkit-1.0.0-BETA and hostnames [localhost] >> 16/08/05 17:07:00 INFO standalone.TlsToolkitStandalone: Successfully >> generated TLS configuration for localhost:10443 in >> ../nifi-toolkit-1.0.0-BETA/localhost >> 16/08/05 17:07:00 INFO standalone.TlsToolkitStandalone: Successfully >> generated TLS configuration for all hosts >> hw12203:...toolkit-assembly/target/nifi-toolkit-1.0.0-BETA-bin/nifi-toolkit-1.0.0-BETA >> (master) alopresto >> 🔓 40s @ 17:07:01 $ ossl pkcs12 -export -out client.p12 -inkey >> nifi-key.key -in nifi-cert.pem >> Enter Export Password: >> Verifying - Enter Export Password: >> hw12203:...toolkit-assembly/target/nifi-toolkit-1.0.0-BETA-bin/nifi-toolkit-1.0.0-BETA >> (master) alopresto >> 🔓 6s @ 17:08:00 $ tl >> . >> .. >> ├── [2.4K] client.p12 >> .. >> ├── [ 170] localhost/ >> │ ├── [3.0K] keystore.jks >> │ ├── [8.3K] nifi.properties >> │ └── [ 925] truststore.jks >> ├── [1.2K] nifi-cert.pem >> └── [1.6K] nifi-key.key >> >> 5 directories, 36 files >> hw12203:...toolkit-assembly/target/nifi-toolkit-1.0.0-BETA-bin/nifi-toolkit-1.0.0-BETA >> (master) alopresto >> 🔓 5s @ 17:08:05 $ >> >> 3. Copy the nifi.properties to conf/ and the keystore.jks and >> truststore.jks to the top-level directory for the new instance. >> 4. Update the authorizers.xml Initial Admin Identity with the DN from the >> client (CA) cert. >> openssl x509 -in nifi-cert.pem -text -noout >> >> <property name="Initial Admin Identity">CN=ca.nifi.apache.org, >> OU=NIFI</property> >> 5. Start NiFi. >> >> The exception from the nifi-app.log boiled down to: >> >> Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid >> content was found starting with element 'groups'. One of '{policies}' is >> expected. >> at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper. >> createSAXParseException(ErrorHandlerWrapper.java:203) ~[na:1.8.0_92] >> ... 68 common frames omitted >> 2016-08-05 16:54:18,621 INFO [Thread-1] org.apache.nifi.NiFi Jetty web >> server shutdown completed (nicely or otherwise). >> >> The content of authorizations.xml is: >> >> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >> <authorizations> >> <groups/> >> <users/> >> <policies/> >> </authorizations> >> >> It seems that it is an element ordering issue? If I put “<policies/>” >> first, it then breaks with: >> >> Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.d: Invalid >> content was found starting with element 'groups'. No child element is >> expected at this point. >> >> Removing both “<groups/>” and “<users/>” allows the application to start >> up, but I cannot connect through the browser using the client certificate. >> I can make a TLS connection using $ openssl s_client -connect >> localhost:10443 -state -debug -CAfile nifi-cert.pem -cert nifi-cert.pem >> -key nifi-key.key and then send ‘HEAD / HTTP/1.1’ in the terminal, which >> triggers a HTTP 400 status from the application: >> >> 2016-08-05 17:25:50,242 WARN [NiFi Web Server-21] >> org.eclipse.jetty.http.HttpParser Illegal character 0x20 in >> state=HEADER_IN_NAME for buffer >> HeapByteBuffer@3a3e608d[p=5,l=16,c=17408,r=11]={HEAD >> <<</ HTTP/1.0\n>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00} >> 2016-08-05 17:25:50,242 WARN [NiFi Web Server-21] >> org.eclipse.jetty.http.HttpParser bad HTTP parsed: 400 Illegal character >> 0x20 for HttpChannelOverHttp@105cb966{r=0,c=false,a=IDLE,uri=null} >> >> Am I missing a step in the configuration of a secure instance? So far, I >> had success with configuring the IAI and then performing the rest of the >> configuration using the NiFi UI. >> >> >> >> Andy LoPresto >> [email protected] >> *[email protected] <[email protected]>* >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> On Aug 5, 2016, at 1:41 PM, Joe Percivall <[email protected] >> <[email protected]>> wrote: >> >> Hello Apache NiFi community, >> >> Please find the associated guidance to help those interested in >> validating/verifying the release so they can vote. >> >> # Download latest KEYS file: >> https://dist.apache.org/repos/dist/dev/nifi/KEYS >> >> # Import keys file: >> gpg --import KEYS >> >> # [optional] Clear out local maven artifact repository >> >> # Pull down nifi-1.0.0-BETA source release artifacts for review: >> >> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.0.0-BETA/ >> nifi-1.0.0-BETA-source-release.zip >> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.0.0-BETA/ >> nifi-1.0.0-BETA-source-release.zip.asc >> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.0.0-BETA/ >> nifi-1.0.0-BETA-source-release.zip.md5 >> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.0.0-BETA/ >> nifi-1.0.0-BETA-source-release.zip.sha1 >> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.0.0-BETA/ >> nifi-1.0.0-BETA-source-release.zip.sha256 >> >> # Verify the signature >> gpg --verify nifi-1.0.0-BETA-source-release.zip.asc >> >> # Verify the hashes (md5, sha1, sha256) match the source and what was >> provided in the vote email thread >> md5sum nifi-1.0.0-BETA-source-release.zip >> sha1sum nifi-1.0.0-BETA-source-release.zip >> sha256sum nifi-1.0.0-BETA-source-release.zip >> >> # Unzip nifi-1.0.0-BETA-source-release.zip >> >> # Verify the build works including release audit tool (RAT) checks >> cd nifi-1.0.0-BETA >> mvn clean install -Pcontrib-check >> >> # Verify the contents contain a good README, NOTICE, and LICENSE. >> >> # Verify the git commit ID is correct >> >> # Verify the RC was branched off the correct git commit ID >> >> # Look at the resulting convenience binary as found in >> nifi-assembly/target >> >> # Make sure the README, NOTICE, and LICENSE are present and correct >> >> # Run the resulting convenience binary and make sure it works as expected >> >> # Send a response to the vote thread indicating a +1, 0, -1 based on your >> findings. >> >> Thank you for your time and effort to validate the release! >> >> >> >> >> >
