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?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>

Reply via email to