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-api/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]
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-assembly/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 
> <http://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 
> <http://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\x00\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] <mailto:[email protected]>
> [email protected] <mailto:[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] 
>> <mailto:[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 
>> <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!
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to