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