To follow up, Bryan was correct. I stopped NiFi, cleared out the authorizations.xml file, and restarted, and was able to access the application.
I believe this is contained in the Jira link, but for anyone on the list, I agree we should focus on having the toolkit produce a certificate with the DN in the “expected” format/order for now, and in 1.x, have the authorizer code normalize the DN to the prescribed order before applying authorization policies. Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Aug 8, 2016, at 12:06 PM, Bryan Bende <[email protected]> wrote: > > 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! >>> >>> >>> >>> >>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
