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 <jsmcmah...@gmail.com> 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 <matt.c.gil...@gmail.com> > 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 <jsmcmah...@gmail.com> >> 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 <matt.c.gil...@gmail.com> >>> 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 <jsmcmah...@gmail.com> >>>> 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: >>>>> >>>>> <authorizers> >>>>> <userGroupProvider> >>>>> <identifier>file-user-group-provider</identifier> >>>>> >>>>> <class>org.apache.nifi.authorization.FileUserGroupProvider</class> >>>>> <property name="Users >>>>> File">/opt/nifi/config_resources/users.xml</property> >>>>> <property name="Legacy Authorized Users File"></property> >>>>> <property name="Initial User Identity 1">C = US, ST = >>>>> Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2</property> >>>>> </userGroupProvider> >>>>> <accessPolicyProvider> >>>>> <identifier>file-access-policy-provider</identifier> >>>>> >>>>> <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class> >>>>> <property name="User Group >>>>> Provider">file-user-group-provider</property> >>>>> <property name="Authorizations >>>>> File">/opt/nifi/config_resources/authorizations.xml</property> >>>>> <property name="Initial Admin Identity">C = US, ST = Virginia, >>>>> L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2</property> >>>>> <property name="Legacy Authorized Users File"></property> >>>>> <property name="Node Identity 1"></property> >>>>> </accessPolicyProvider> >>>>> <authorizer> >>>>> <identifier>managed-authorizer</identifier> >>>>> >>>>> <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class> >>>>> <property name="Access Policy >>>>> Provider">file-access-policy-provider</property> >>>>> </authorizer> >>>>> </authorizers> >>>>> >>>>> >>>>> Here is my authorizations.xml (nifi creates at first startup): >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >>>>> <authorizations> >>>>> <policies> >>>>> <policy identifier="f99bccd1-a30e-3e4a-98a2-dbc708edc67f" >>>>> resource="/flow" action="R"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="ae1ef91b-11d8-38a4-9d8a-33e7ee25d65e" >>>>> resource="/data/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" >>>>> action="R"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="818d3b60-f65b-3d67-960e-f7e7aea0f6cc" >>>>> resource="/data/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" >>>>> action="W"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="6e49aea6-93bd-3a2a-a0d6-b5afb4581b4f" >>>>> resource="/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" >>>>> action="R"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="3755b3ac-380b-3c02-83a6-10c3870f377a" >>>>> resource="/process-groups/ca7090bc-018e-1000-6a92-e199f7d9e48e" >>>>> action="W"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="b8775bd4-704a-34c6-987b-84f2daf7a515" >>>>> resource="/restricted-components" action="W"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="627410be-1717-35b4-a06f-e9362b89e0b7" >>>>> resource="/tenants" action="R"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="15e4e0bd-cb28-34fd-8587-f8d15162cba5" >>>>> resource="/tenants" action="W"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="ff96062a-fa99-36dc-9942-0f6442ae7212" >>>>> resource="/policies" action="R"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="ad99ea98-3af6-3561-ae27-5bf09e1d969d" >>>>> resource="/policies" action="W"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="2e1015cb-0fed-3005-8e0d-722311f21a03" >>>>> resource="/controller" action="R"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> <policy identifier="c6322e6c-4cc1-3bcc-91b3-2ed2111674cf" >>>>> resource="/controller" action="W"> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834"/> >>>>> </policy> >>>>> </policies> >>>>> </authorizations> >>>>> >>>>> >>>>> >>>>> Here is my users.xml (nifi creates at first startup): >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> >>>>> <tenants> >>>>> <groups/> >>>>> <users> >>>>> <user identifier="03e0564a-4cad-3d24-bf64-3f09d78a5834" >>>>> identity="C = US, ST = Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN >>>>> = admin2"/> >>>>> </users> >>>>> </tenants> >>>>> >>>>> >>>>> On Wed, Apr 24, 2024 at 8:21 AM James McMahon <jsmcmah...@gmail.com> >>>>> 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 <jsmcmah...@gmail.com> >>>>>>> *Verzonden:* woensdag 24 april 2024 02:14 >>>>>>> *Aan:* users <users@nifi.apache.org> >>>>>>> *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: >>>>>>> >>>>>>> <authorizers> >>>>>>> <userGroupProvider> >>>>>>> <identifier>file-user-group-provider</identifier> >>>>>>> >>>>>>> <class>org.apache.nifi.authorization.FileUserGroupProvider</class> >>>>>>> <property name="Users >>>>>>> File">/opt/nifi/config_resources/users.xml</property> >>>>>>> <property name="Legacy Authorized Users File"></property> >>>>>>> <property name="Initial User Identity 1">C = US, ST = >>>>>>> Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2</property> >>>>>>> </userGroupProvider> >>>>>>> <accessPolicyProvider> >>>>>>> <identifier>file-access-policy-provider</identifier> >>>>>>> >>>>>>> <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class> >>>>>>> <property name="User Group >>>>>>> Provider">file-user-group-provider</property> >>>>>>> <property name="Authorizations >>>>>>> File">/opt/nifi/config_resources/authorizations.xml</property> >>>>>>> <property name="Initial Admin Identity">C = US, ST = >>>>>>> Virginia, L = Reston, O = C4 Rampart, OU = NIFI, CN = admin2</property> >>>>>>> <property name="Legacy Authorized Users File"></property> >>>>>>> <property name="Node Identity 1"></property> >>>>>>> </accessPolicyProvider> >>>>>>> <authorizer> >>>>>>> <identifier>managed-authorizer</identifier> >>>>>>> >>>>>>> <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class> >>>>>>> <property name="Access Policy >>>>>>> Provider">file-access-policy-provider</property> >>>>>>> </authorizer> >>>>>>> </authorizers> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>
