Re: Insufficient permissions on initial start up (NiFi 2.0)
No problem. Glad you got it sorted. Yet at the https URL in the browser, it still tells me it is insecure. > This is happening because the certificate is not issued by a trusted Certificate Authority. The certificate from TinyCert is valid (the connection works) but TinyCert is not a trusted CA from your browser's perspective. Matt On Thu, Apr 25, 2024 at 4:44 PM James McMahon wrote: > When I learned that the initial user in authorizers.xml must match the > certificate *exactly*, I figured it would be an easy matter to use openssl > to inspect the cert. I wanted to be *absolutely* certain I matched it > correctly. > Here is the command: > /opt/nifi/config_resources/keys$ openssl pkcs12 -info -in CN=admin2.p12 > -nodes > > Here is the output. The output informed me of what I thought was the > subject info in the cert: > .. > subject=C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN > = admin2 > issuer=C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = Secure > Digital Certificate Signing, CN = C4 Rampart CA > -BEGIN CERTIFICATE- > MIIExDCCA6ygAwIBAgICeYowDQYJKoZI.. > > This is why I put that in the way that I did. I mean why on earth would it > reverse the DN info and add extra spaces, right!? It's like having a > separate knob for volume on the alarm clock in Seinfeld. Why separate knob, > WHY? > > Anyway I reversed my entry and squashed the extra spacing. I updated > authorizers.xml. I blew away authorizations.xml and users.xml so that nifi > would recreate them at startup. I also fixed > nifi.security.identity.mapping.pattern.dn and > nifi.security.identity.mapping.value.dn in nifi.properties.I restarted > nifi. And as Bryan, Matt, and Isha certainly already suspect, it worked. > > I still have one more thing to figure out. I've got the CA and user cert > info in my browser. I've got a server cert. All have been generated by > tinycert.org. Yet at the https URL in the browser, it still tells me it > is insecure. I do not understand why. > x Not secure https:// > ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi/ > > Anyway, thank you Bryan, Matt, and Isha for replying. > > On Wed, Apr 24, 2024 at 9:05 PM Matt Gilman > wrote: > >> What is this Access Token it cites at top? >>> >> >> NiFi UI attempts to get the access token expiration. However, since >> you're authenticating with a certificate the endpoint returns an >> IllegalState because there was no token in the request. >> >> Looking at the logs and the supplied configuration it appears there are >> spaces and the ordering is reversed in your initial admin identity when >> compared with the value from the certificate. >> >> C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 >> CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US >> >> Hope this helps! >> >> Matt >> >> On Wed, Apr 24, 2024 at 8:41 PM James McMahon >> wrote: >> >>> Looking at the nifi-user.log, I find I am getting a Conflict response, >>> Access Token not found. >>> >>> more ./nifi-user.log >>> 2024-04-25 00:23:49,329 INFO [main] o.a.n.a.FileUserGroupProvider >>> Creating new users file at /opt/nifi/config_resources/users.xml >>> 2024-04-25 00:23:49,352 INFO [main] o.a.n.a.FileAccessPolicyProvider >>> Creating new authorizations file at >>> /opt/nifi/config_resources/authorizations.xml >>> 2024-04-25 00:23:49,573 INFO [main] o.a.n.a.FileAccessPolicyProvider >>> Populating authorizations for Initial Admin: C = US, ST = Virginia, L = >>> Reston, O = C4 Rampart, OU = NIFI, >>> CN = admin2 >>> 2024-04-25 00:24:51,107 INFO [NiFi Web Server-100] >>> o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 >>> [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi >>> nia, C=US] POST >>> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos >>> 2024-04-25 00:24:51,110 INFO [NiFi Web Server-100] >>> o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, >>> OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 >>> .73.40.110 POST >>> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos >>> 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] >>> o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 >>> [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi >>> nia, C=US] GET >>> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration >>> 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] >>> o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, >>> OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 >>> .73.40.110 GET >>> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration >>> 2024-04-25 00:24:51,172 WARN [NiFi Web Server-104] >>> o.a.n.w.a.c.IllegalStateExceptionMapper java.lang.IllegalStateException: >>> *Access Token not found. Returning Conflict >>> response.java.lang.IllegalStateException: Access Token not found* >>>
Re: Insufficient permissions on initial start up (NiFi 2.0)
When I learned that the initial user in authorizers.xml must match the certificate *exactly*, I figured it would be an easy matter to use openssl to inspect the cert. I wanted to be *absolutely* certain I matched it correctly. Here is the command: /opt/nifi/config_resources/keys$ openssl pkcs12 -info -in CN=admin2.p12 -nodes Here is the output. The output informed me of what I thought was the subject info in the cert: .. subject=C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 issuer=C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = Secure Digital Certificate Signing, CN = C4 Rampart CA -BEGIN CERTIFICATE- MIIExDCCA6ygAwIBAgICeYowDQYJKoZI.. This is why I put that in the way that I did. I mean why on earth would it reverse the DN info and add extra spaces, right!? It's like having a separate knob for volume on the alarm clock in Seinfeld. Why separate knob, WHY? Anyway I reversed my entry and squashed the extra spacing. I updated authorizers.xml. I blew away authorizations.xml and users.xml so that nifi would recreate them at startup. I also fixed nifi.security.identity.mapping.pattern.dn and nifi.security.identity.mapping.value.dn in nifi.properties.I restarted nifi. And as Bryan, Matt, and Isha certainly already suspect, it worked. I still have one more thing to figure out. I've got the CA and user cert info in my browser. I've got a server cert. All have been generated by tinycert.org. Yet at the https URL in the browser, it still tells me it is insecure. I do not understand why. x Not secure https:// ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi/ Anyway, thank you Bryan, Matt, and Isha for replying. On Wed, Apr 24, 2024 at 9:05 PM Matt Gilman wrote: > What is this Access Token it cites at top? >> > > NiFi UI attempts to get the access token expiration. However, since you're > authenticating with a certificate the endpoint returns an IllegalState > because there was no token in the request. > > Looking at the logs and the supplied configuration it appears there are > spaces and the ordering is reversed in your initial admin identity when > compared with the value from the certificate. > > C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 > CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US > > Hope this helps! > > Matt > > On Wed, Apr 24, 2024 at 8:41 PM James McMahon > wrote: > >> Looking at the nifi-user.log, I find I am getting a Conflict response, >> Access Token not found. >> >> more ./nifi-user.log >> 2024-04-25 00:23:49,329 INFO [main] o.a.n.a.FileUserGroupProvider >> Creating new users file at /opt/nifi/config_resources/users.xml >> 2024-04-25 00:23:49,352 INFO [main] o.a.n.a.FileAccessPolicyProvider >> Creating new authorizations file at >> /opt/nifi/config_resources/authorizations.xml >> 2024-04-25 00:23:49,573 INFO [main] o.a.n.a.FileAccessPolicyProvider >> Populating authorizations for Initial Admin: C = US, ST = Virginia, L = >> Reston, O = C4 Rampart, OU = NIFI, >> CN = admin2 >> 2024-04-25 00:24:51,107 INFO [NiFi Web Server-100] >> o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 >> [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi >> nia, C=US] POST >> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos >> 2024-04-25 00:24:51,110 INFO [NiFi Web Server-100] >> o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, >> OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 >> .73.40.110 POST >> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos >> 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] >> o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 >> [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi >> nia, C=US] GET >> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration >> 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] >> o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, >> OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 >> .73.40.110 GET >> https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration >> 2024-04-25 00:24:51,172 WARN [NiFi Web Server-104] >> o.a.n.w.a.c.IllegalStateExceptionMapper java.lang.IllegalStateException: >> *Access Token not found. Returning Conflict >> response.java.lang.IllegalStateException: Access Token not found* >> at >> org.apache.nifi.web.api.AccessResource.getAccessTokenExpiration(AccessResource.java:463) >> at >> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >> at java.base/java.lang.reflect.Method.invoke(Method.java:580) >> >> followed by >> >> 2024-04-25 00:24:51,185 INFO [NiFi Web Server-100] >> o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 >> [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi >> nia, C=US] GET >>
Re: Insufficient permissions on initial start up (NiFi 2.0)
> > What is this Access Token it cites at top? > NiFi UI attempts to get the access token expiration. However, since you're authenticating with a certificate the endpoint returns an IllegalState because there was no token in the request. Looking at the logs and the supplied configuration it appears there are spaces and the ordering is reversed in your initial admin identity when compared with the value from the certificate. C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US Hope this helps! Matt On Wed, Apr 24, 2024 at 8:41 PM James McMahon wrote: > Looking at the nifi-user.log, I find I am getting a Conflict response, > Access Token not found. > > more ./nifi-user.log > 2024-04-25 00:23:49,329 INFO [main] o.a.n.a.FileUserGroupProvider Creating > new users file at /opt/nifi/config_resources/users.xml > 2024-04-25 00:23:49,352 INFO [main] o.a.n.a.FileAccessPolicyProvider > Creating new authorizations file at > /opt/nifi/config_resources/authorizations.xml > 2024-04-25 00:23:49,573 INFO [main] o.a.n.a.FileAccessPolicyProvider > Populating authorizations for Initial Admin: C = US, ST = Virginia, L = > Reston, O = C4 Rampart, OU = NIFI, > CN = admin2 > 2024-04-25 00:24:51,107 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 > [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi > nia, C=US] POST > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos > 2024-04-25 00:24:51,110 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, > OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 > .73.40.110 POST > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos > 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 > [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi > nia, C=US] GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration > 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, > OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 > .73.40.110 GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration > 2024-04-25 00:24:51,172 WARN [NiFi Web Server-104] > o.a.n.w.a.c.IllegalStateExceptionMapper java.lang.IllegalStateException: > *Access Token not found. Returning Conflict > response.java.lang.IllegalStateException: Access Token not found* > at > org.apache.nifi.web.api.AccessResource.getAccessTokenExpiration(AccessResource.java:463) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > > followed by > > 2024-04-25 00:24:51,185 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 > [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi > nia, C=US] GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/flow/current-user > 2024-04-25 00:24:51,186 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, > OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 > .73.40.110 GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/flow/current-user > 2024-04-25 00:24:51,192 INFO [NiFi Web Server-100] > o.a.n.w.a.c.AccessDeniedExceptionMapper identity[CN=admin2, OU=NIFI, O=C4 > Rampart, L=Reston, ST=Virginia, C=US], groups[] > *does not have permission to access the requested resource. Unable to view > the user interface. Returning Forbidden response.* > > What is this Access Token it cites at top? > > Based on what I have read in the documentation, nifi itself must be > allowed to create the authorizations.xml file at initial startup. Is there > a reason it would omit permission to view and use the UI? > > On Wed, Apr 24, 2024 at 5:18 PM Matt Gilman > wrote: > >> James, >> >> If you check the nifi-user.log in the logs directory, you should see >> messages for the requests that are being rejected. In that log message you >> should see the identity that you're authenticated with. Can you compare >> that with the user that you've configured the policies for. Hopefully, that >> will help point to where the issue is. >> >> Matt >> >> On Wed, Apr 24, 2024 at 5:03 PM James McMahon >> wrote: >> >>> I still cannot access my own NiFi 2.0 instance. I continue to get this >>> rejection: >>> >>> Insufficient Permissions >>> >>>- home >>> >>> Unable to view the user interface. Contact the system administrator. >>> >>> >>> The canvas flashes for an instant when I try to hit my secure URL, but >>> is immediately replaced with this rejection message. >>> >>> There is no error or warning in nifi-app.log
Re: Insufficient permissions on initial start up (NiFi 2.0)
The identity you put for your initial admin is: C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 Which does not match the identity shown in the logs that is coming from your client cert: CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US It is case and whitespace sensitive and the ordering is reversed. On Wed, Apr 24, 2024 at 8:42 PM James McMahon wrote: > Looking at the nifi-user.log, I find I am getting a Conflict response, > Access Token not found. > > more ./nifi-user.log > 2024-04-25 00:23:49,329 INFO [main] o.a.n.a.FileUserGroupProvider Creating > new users file at /opt/nifi/config_resources/users.xml > 2024-04-25 00:23:49,352 INFO [main] o.a.n.a.FileAccessPolicyProvider > Creating new authorizations file at > /opt/nifi/config_resources/authorizations.xml > 2024-04-25 00:23:49,573 INFO [main] o.a.n.a.FileAccessPolicyProvider > Populating authorizations for Initial Admin: C = US, ST = Virginia, L = > Reston, O = C4 Rampart, OU = NIFI, > CN = admin2 > 2024-04-25 00:24:51,107 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 > [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi > nia, C=US] POST > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos > 2024-04-25 00:24:51,110 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, > OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 > .73.40.110 POST > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos > 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 > [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi > nia, C=US] GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration > 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, > OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 > .73.40.110 GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration > 2024-04-25 00:24:51,172 WARN [NiFi Web Server-104] > o.a.n.w.a.c.IllegalStateExceptionMapper java.lang.IllegalStateException: > *Access Token not found. Returning Conflict > response.java.lang.IllegalStateException: Access Token not found* > at > org.apache.nifi.web.api.AccessResource.getAccessTokenExpiration(AccessResource.java:463) > at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > > followed by > > 2024-04-25 00:24:51,185 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 > [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi > nia, C=US] GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/flow/current-user > 2024-04-25 00:24:51,186 INFO [NiFi Web Server-100] > o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, > OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 > .73.40.110 GET > https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/flow/current-user > 2024-04-25 00:24:51,192 INFO [NiFi Web Server-100] > o.a.n.w.a.c.AccessDeniedExceptionMapper identity[CN=admin2, OU=NIFI, O=C4 > Rampart, L=Reston, ST=Virginia, C=US], groups[] > *does not have permission to access the requested resource. Unable to view > the user interface. Returning Forbidden response.* > > What is this Access Token it cites at top? > > Based on what I have read in the documentation, nifi itself must be > allowed to create the authorizations.xml file at initial startup. Is there > a reason it would omit permission to view and use the UI? > > On Wed, Apr 24, 2024 at 5:18 PM Matt Gilman > wrote: > >> James, >> >> If you check the nifi-user.log in the logs directory, you should see >> messages for the requests that are being rejected. In that log message you >> should see the identity that you're authenticated with. Can you compare >> that with the user that you've configured the policies for. Hopefully, that >> will help point to where the issue is. >> >> Matt >> >> On Wed, Apr 24, 2024 at 5:03 PM James McMahon >> wrote: >> >>> I still cannot access my own NiFi 2.0 instance. I continue to get this >>> rejection: >>> >>> Insufficient Permissions >>> >>>- home >>> >>> Unable to view the user interface. Contact the system administrator. >>> >>> >>> The canvas flashes for an instant when I try to hit my secure URL, but >>> is immediately replaced with this rejection message. >>> >>> There is no error or warning in nifi-app.log >>> >>> Has anyone experienced a similar problem? >>> >>> >>> Here is my authorizers.xml: >>> >>> >>> >>> file-user-group-provider >>> >>> org.apache.nifi.authorization.FileUserGroupProvider >>>
Re: Insufficient permissions on initial start up (NiFi 2.0)
Looking at the nifi-user.log, I find I am getting a Conflict response, Access Token not found. more ./nifi-user.log 2024-04-25 00:23:49,329 INFO [main] o.a.n.a.FileUserGroupProvider Creating new users file at /opt/nifi/config_resources/users.xml 2024-04-25 00:23:49,352 INFO [main] o.a.n.a.FileAccessPolicyProvider Creating new authorizations file at /opt/nifi/config_resources/authorizations.xml 2024-04-25 00:23:49,573 INFO [main] o.a.n.a.FileAccessPolicyProvider Populating authorizations for Initial Admin: C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 2024-04-25 00:24:51,107 INFO [NiFi Web Server-100] o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi nia, C=US] POST https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos 2024-04-25 00:24:51,110 INFO [NiFi Web Server-100] o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 .73.40.110 POST https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/kerberos 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi nia, C=US] GET https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration 2024-04-25 00:24:51,166 INFO [NiFi Web Server-104] o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 .73.40.110 GET https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/access/token/expiration 2024-04-25 00:24:51,172 WARN [NiFi Web Server-104] o.a.n.w.a.c.IllegalStateExceptionMapper java.lang.IllegalStateException: *Access Token not found. Returning Conflict response.java.lang.IllegalStateException: Access Token not found* at org.apache.nifi.web.api.AccessResource.getAccessTokenExpiration(AccessResource.java:463) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) followed by 2024-04-25 00:24:51,185 INFO [NiFi Web Server-100] o.a.n.w.s.NiFiAuthenticationFilter Authentication Started 173.73.40.110 [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virgi nia, C=US] GET https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/flow/current-user 2024-04-25 00:24:51,186 INFO [NiFi Web Server-100] o.a.n.w.s.NiFiAuthenticationFilter Authentication Success [CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US] 173 .73.40.110 GET https://ec2-44-219-227-80.compute-1.amazonaws.com:8443/nifi-api/flow/current-user 2024-04-25 00:24:51,192 INFO [NiFi Web Server-100] o.a.n.w.a.c.AccessDeniedExceptionMapper identity[CN=admin2, OU=NIFI, O=C4 Rampart, L=Reston, ST=Virginia, C=US], groups[] *does not have permission to access the requested resource. Unable to view the user interface. Returning Forbidden response.* What is this Access Token it cites at top? Based on what I have read in the documentation, nifi itself must be allowed to create the authorizations.xml file at initial startup. Is there a reason it would omit permission to view and use the UI? On Wed, Apr 24, 2024 at 5:18 PM Matt Gilman wrote: > James, > > If you check the nifi-user.log in the logs directory, you should see > messages for the requests that are being rejected. In that log message you > should see the identity that you're authenticated with. Can you compare > that with the user that you've configured the policies for. Hopefully, that > will help point to where the issue is. > > Matt > > On Wed, Apr 24, 2024 at 5:03 PM James McMahon > wrote: > >> I still cannot access my own NiFi 2.0 instance. I continue to get this >> rejection: >> >> Insufficient Permissions >> >>- home >> >> Unable to view the user interface. Contact the system administrator. >> >> >> The canvas flashes for an instant when I try to hit my secure URL, but is >> immediately replaced with this rejection message. >> >> There is no error or warning in nifi-app.log >> >> Has anyone experienced a similar problem? >> >> >> Here is my authorizers.xml: >> >> >> >> file-user-group-provider >> org.apache.nifi.authorization.FileUserGroupProvider >> /opt/nifi/config_resources/users.xml >> >> C = US, ST = Virginia, L >> = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 >> >> >> file-access-policy-provider >> >> org.apache.nifi.authorization.FileAccessPolicyProvider >> file-user-group-provider >> /opt/nifi/config_resources/authorizations.xml >> C = US, ST = Virginia, L >> = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 >> >> >> >> >> managed-authorizer >> >> org.apache.nifi.authorization.StandardManagedAuthorizer >>
Re: Insufficient permissions on initial start up (NiFi 2.0)
James, If you check the nifi-user.log in the logs directory, you should see messages for the requests that are being rejected. In that log message you should see the identity that you're authenticated with. Can you compare that with the user that you've configured the policies for. Hopefully, that will help point to where the issue is. Matt On Wed, Apr 24, 2024 at 5:03 PM James McMahon wrote: > I still cannot access my own NiFi 2.0 instance. I continue to get this > rejection: > > Insufficient Permissions > >- home > > Unable to view the user interface. Contact the system administrator. > > > The canvas flashes for an instant when I try to hit my secure URL, but is > immediately replaced with this rejection message. > > There is no error or warning in nifi-app.log > > Has anyone experienced a similar problem? > > > Here is my authorizers.xml: > > > > file-user-group-provider > org.apache.nifi.authorization.FileUserGroupProvider > /opt/nifi/config_resources/users.xml > > C = US, ST = Virginia, L > = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 > > > file-access-policy-provider > > org.apache.nifi.authorization.FileAccessPolicyProvider > file-user-group-provider > /opt/nifi/config_resources/authorizations.xml > C = US, ST = Virginia, L = > Reston, O = C4 Rampart, OU = NIFI, CN = admin2 > > > > > managed-authorizer > > org.apache.nifi.authorization.StandardManagedAuthorizer > file-access-policy-provider > > > > > Here is my authorizations.xml (nifi creates at first startup): > > > > > resource="/flow" action="R"> > > > resource="/data/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" > action="R"> > > > resource="/data/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" > action="W"> > > > resource="/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" action="R"> > > > resource="/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" action="W"> > > > resource="/restricted-components" action="W"> > > > resource="/tenants" action="R"> > > > resource="/tenants" action="W"> > > > resource="/policies" action="R"> > > > resource="/policies" action="W"> > > > resource="/controller" action="R"> > > > resource="/controller" action="W"> > > > > > > > > Here is my users.xml (nifi creates at first startup): > > > > > > identity="C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN > = admin2"/> > > > > > On Wed, Apr 24, 2024 at 8:21 AM James McMahon > wrote: > >> I'll review this closely once again when I get back to this system >> tonight - thanks very much for your reply, Isha. >> >> I also feel I need to look more closely in nifi.properties, at values I >> have set for keys nifi.security.identity.mapping.[value, transform, >> pattern].CN1 >> >> I noticed some odd behavior and suspect it is a reflection of an issue I >> have not set properly in my configuration: >> The first time I started my 2.0 instance with my Initial Admin Identity >> defined as shown, the UI in my browser actually presented me with a list >> (of one) Personal cert to select from - the cert for admin2. I was in a >> happy place: *finally*, nifi and the browser appeared to be in synch for >> the Subject name in the cert. >> >> I selected this cert, but then was crushed by the rejection mentioned >> above: >> Unable to view the user interface. Contact the system administrator. >> Insufficient Permissions home >> >> I restarted nifi so I could "tail -f" nifi-app.log. >> After restart, I once again tried to hit my NiFi URL. >> This time though, the browser failed to present the admin2 cert for >> selection. Shouldn't it have still presented that to me in the browser fro >> my selection? >> Do you have any thoughts why this behavior is occurring? >> >> Would you say it is it advisable to manually create by hand an >> authorizations.xml file should I continue to experience Insufficient >> Permissions problems? I recall reading that users.xml and >> authorizations.xml - if absent at initial startup - should be created by >> nifi from info in authorizers.xml. But this Insufficient Permissions makes >> me suspect something is missing from authorizations. >> >> Jim >> >> On Wed, Apr 24, 2024 at 5:33 AM Isha Lamboo < >> isha.lam...@virtualsciences.nl> wrote: >> >>> Hi James, >>> >>> >>> >>> Have you changed these settings in authorizers.xml since you first >>> started NiFi? If so, you may need to delete users.xml and >>> authorizations.xml. >>> >>> A new admin user will not
Re: Insufficient permissions on initial start up (NiFi 2.0)
I still cannot access my own NiFi 2.0 instance. I continue to get this rejection: Insufficient Permissions - home Unable to view the user interface. Contact the system administrator. The canvas flashes for an instant when I try to hit my secure URL, but is immediately replaced with this rejection message. There is no error or warning in nifi-app.log Has anyone experienced a similar problem? Here is my authorizers.xml: file-user-group-provider org.apache.nifi.authorization.FileUserGroupProvider /opt/nifi/config_resources/users.xml C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 file-access-policy-provider org.apache.nifi.authorization.FileAccessPolicyProvider file-user-group-provider /opt/nifi/config_resources/authorizations.xml C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 managed-authorizer org.apache.nifi.authorization.StandardManagedAuthorizer file-access-policy-provider Here is my authorizations.xml (nifi creates at first startup): Here is my users.xml (nifi creates at first startup): On Wed, Apr 24, 2024 at 8:21 AM James McMahon wrote: > I'll review this closely once again when I get back to this system tonight > - thanks very much for your reply, Isha. > > I also feel I need to look more closely in nifi.properties, at values I > have set for keys nifi.security.identity.mapping.[value, transform, > pattern].CN1 > > I noticed some odd behavior and suspect it is a reflection of an issue I > have not set properly in my configuration: > The first time I started my 2.0 instance with my Initial Admin Identity > defined as shown, the UI in my browser actually presented me with a list > (of one) Personal cert to select from - the cert for admin2. I was in a > happy place: *finally*, nifi and the browser appeared to be in synch for > the Subject name in the cert. > > I selected this cert, but then was crushed by the rejection mentioned > above: > Unable to view the user interface. Contact the system administrator. > Insufficient Permissions home > > I restarted nifi so I could "tail -f" nifi-app.log. > After restart, I once again tried to hit my NiFi URL. > This time though, the browser failed to present the admin2 cert for > selection. Shouldn't it have still presented that to me in the browser fro > my selection? > Do you have any thoughts why this behavior is occurring? > > Would you say it is it advisable to manually create by hand an > authorizations.xml file should I continue to experience Insufficient > Permissions problems? I recall reading that users.xml and > authorizations.xml - if absent at initial startup - should be created by > nifi from info in authorizers.xml. But this Insufficient Permissions makes > me suspect something is missing from authorizations. > > Jim > > On Wed, Apr 24, 2024 at 5:33 AM Isha Lamboo < > isha.lam...@virtualsciences.nl> wrote: > >> Hi James, >> >> >> >> Have you changed these settings in authorizers.xml since you first >> started NiFi? If so, you may need to delete users.xml and >> authorizations.xml. >> >> A new admin user will not be created if those files already exist. >> >> >> >> Otherwise, the trickiest part is usually that the user DN needs to match * >> *exactly** with that specified. Capitals and whitespace matter. Since >> you are getting insufficient permissions instead of unknown user, I don’t >> think that’s your problem here. Still, it may be worth checking for a >> mismatch in the initial admin identity vs initial user identity vs >> certificate. >> >> >> >> Regards, >> >> >> >> Isha >> >> >> >> *Van:* James McMahon >> *Verzonden:* woensdag 24 april 2024 02:14 >> *Aan:* users >> *Onderwerp:* Insufficient permissions on initial start up (NiFi 2.0) >> >> >> >> I am trying to start my new NiFi 2.0 installation. I have a user admin2 >> that has a cert. The nifi server also has a cert. Both are signed by the >> same CA. >> >> >> >> At start up in my browser I am denied due to insufficient privileges: >> >> >> >> Unable to view the user interface. Contact the system administrator. >> >> Insufficient Permissions home >> >> >> >> >> >> My authorizors.xml has been configured as follows: >> >> >> >> file-user-group-provider >> org.apache.nifi.authorization.FileUserGroupProvider >> /opt/nifi/config_resources/users.xml >> >> C = US, ST = Virginia, L >> = Reston, O = C4 Rampart, OU
Re: Insufficient permissions on initial start up (NiFi 2.0)
I'll review this closely once again when I get back to this system tonight - thanks very much for your reply, Isha. I also feel I need to look more closely in nifi.properties, at values I have set for keys nifi.security.identity.mapping.[value, transform, pattern].CN1 I noticed some odd behavior and suspect it is a reflection of an issue I have not set properly in my configuration: The first time I started my 2.0 instance with my Initial Admin Identity defined as shown, the UI in my browser actually presented me with a list (of one) Personal cert to select from - the cert for admin2. I was in a happy place: *finally*, nifi and the browser appeared to be in synch for the Subject name in the cert. I selected this cert, but then was crushed by the rejection mentioned above: Unable to view the user interface. Contact the system administrator. Insufficient Permissions home I restarted nifi so I could "tail -f" nifi-app.log. After restart, I once again tried to hit my NiFi URL. This time though, the browser failed to present the admin2 cert for selection. Shouldn't it have still presented that to me in the browser fro my selection? Do you have any thoughts why this behavior is occurring? Would you say it is it advisable to manually create by hand an authorizations.xml file should I continue to experience Insufficient Permissions problems? I recall reading that users.xml and authorizations.xml - if absent at initial startup - should be created by nifi from info in authorizers.xml. But this Insufficient Permissions makes me suspect something is missing from authorizations. Jim On Wed, Apr 24, 2024 at 5:33 AM Isha Lamboo wrote: > Hi James, > > > > Have you changed these settings in authorizers.xml since you first started > NiFi? If so, you may need to delete users.xml and authorizations.xml. > > A new admin user will not be created if those files already exist. > > > > Otherwise, the trickiest part is usually that the user DN needs to match * > *exactly** with that specified. Capitals and whitespace matter. Since you > are getting insufficient permissions instead of unknown user, I don’t think > that’s your problem here. Still, it may be worth checking for a mismatch in > the initial admin identity vs initial user identity vs certificate. > > > > Regards, > > > > Isha > > > > *Van:* James McMahon > *Verzonden:* woensdag 24 april 2024 02:14 > *Aan:* users > *Onderwerp:* Insufficient permissions on initial start up (NiFi 2.0) > > > > I am trying to start my new NiFi 2.0 installation. I have a user admin2 > that has a cert. The nifi server also has a cert. Both are signed by the > same CA. > > > > At start up in my browser I am denied due to insufficient privileges: > > > > Unable to view the user interface. Contact the system administrator. > > Insufficient Permissions home > > > > > > My authorizors.xml has been configured as follows: > > > > file-user-group-provider > org.apache.nifi.authorization.FileUserGroupProvider > /opt/nifi/config_resources/users.xml > > C = US, ST = Virginia, L > = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 > > > file-access-policy-provider > > org.apache.nifi.authorization.FileAccessPolicyProvider > file-user-group-provider > /opt/nifi/config_resources/authorizations.xml > C = US, ST = Virginia, L = > Reston, O = C4 Rampart, OU = NIFI, CN = admin2 > > > > > managed-authorizer > > org.apache.nifi.authorization.StandardManagedAuthorizer > file-access-policy-provider > > > > > > I read that at start up, authorizations.xml and users.xml would be created > by NiFi - those files are not to be hand jammed. > > > > So how do I actually get in with my admin2 user? > > What have I overlooked on this magical mystery tour? > > > > >
RE: Insufficient permissions on initial start up (NiFi 2.0)
Hi James, Have you changed these settings in authorizers.xml since you first started NiFi? If so, you may need to delete users.xml and authorizations.xml. A new admin user will not be created if those files already exist. Otherwise, the trickiest part is usually that the user DN needs to match *exactly* with that specified. Capitals and whitespace matter. Since you are getting insufficient permissions instead of unknown user, I don’t think that’s your problem here. Still, it may be worth checking for a mismatch in the initial admin identity vs initial user identity vs certificate. Regards, Isha Van: James McMahon Verzonden: woensdag 24 april 2024 02:14 Aan: users Onderwerp: Insufficient permissions on initial start up (NiFi 2.0) I am trying to start my new NiFi 2.0 installation. I have a user admin2 that has a cert. The nifi server also has a cert. Both are signed by the same CA. At start up in my browser I am denied due to insufficient privileges: Unable to view the user interface. Contact the system administrator. Insufficient Permissions home My authorizors.xml has been configured as follows: file-user-group-provider org.apache.nifi.authorization.FileUserGroupProvider /opt/nifi/config_resources/users.xml C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 file-access-policy-provider org.apache.nifi.authorization.FileAccessPolicyProvider file-user-group-provider /opt/nifi/config_resources/authorizations.xml C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2 managed-authorizer org.apache.nifi.authorization.StandardManagedAuthorizer file-access-policy-provider I read that at start up, authorizations.xml and users.xml would be created by NiFi - those files are not to be hand jammed. So how do I actually get in with my admin2 user? What have I overlooked on this magical mystery tour?
