Skip to main content
Lorenzo
Lorenzo
Gold ⭐️
May 8, 2024
Solved

NiFi Rest API via Kerberos token

Hi everyone, I'm trying to use rest api in a cloudera cluster with ssl and kerberos. I am testing the use of the same by authenticating with a bearer token to gain access to the resource. Below is what is used and working:

  1. curl 'https://nifi-node:8443/nifi-api/access/token' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' --data 'username=myuserad&password=mypasswordad' --compressed --cacert /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts.pem
  2. curl -H 'Authorization: Bearer token generated 'Content-Type: application/json' -XPUT -d '{"id":"****","state":"RUNNING"}' https://nifi-node/nifi-api/flow/process-groups/****--cacert /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts.pem

To avoid entering the password in clear text as in curl N.1 I am testing the token generation via Kerberos:

curl -X POST --negotiate -u : https://nifi-node:8443/nifi-api/access/kerberos --cacert /var/lib/cloudera-scm-agent/agent-cert/cm-auto-global_cacerts .pem

Using this mode the token is correctly generated but when I try to execute API N.2 I receive the following error:

o.a.n.w.a.c.AccessDeniedExceptionMapper identity[myaduser], groups[] does not have permission to access the requested resource. Unable to view the user interface. Returning Forbidden response.

Do you have any advice?

Lorenzo
LorenzoAnswer
Gold ⭐️
May 27, 2024

@MattWho 

To authenticate to the web ui in NiFi i use the ldap credentials (myuser). For Kerberos authentication via shell I use myuser@REALM. After setting the following parameters in nifi:

nifi.security.identity.mapping.pattern.kerb=^(.*?)(?:@.*?)$
nifi.security.identity.mapping.value.kerb=$1
nifi.security.identity.mapping.transform.kerb=NONE

Now the token via kerberos works and I no longer get permission errors.

Thanks!

Lorenzo

 
View in thread

4 replies

RAGHUY
Gold ⭐️
RAGHUY
Gold ⭐️
May 9, 2024

@Lorenzo 

The error message "identity[myaduser], groups[] does not have permission to access the requested resource" indicates that while Kerberos authentication is successful, your user myaduser lacks the necessary permissions to access the specific NiFi flow you're targeting in API call N.2.

1. Verify User Permissions in NiFi:

Access the NiFi UI and navigate to the specific flow you're trying to modify.
Go to the "Policies" tab.
Ensure "myaduser" has the appropriate read/write permissions on the flow or specific process group. You might need to add the user to a group with the required permissions.

2. Check Ranger Policies (if applicable):

If you're using Apache Ranger for authorization in your Cloudera cluster, there might be Ranger policies restricting access to the NiFi flow.
Review Ranger policies for NiFi resources.
Verify if any policies specifically deny access to the flow or process group for "myaduser" or its groups.

3. Kerberos Service Principal Configuration:

Double-check the Kerberos service principal configured for NiFi.
Ensure the service principal used for authentication has the necessary permissions in Ranger or NiFi authorization policies.

4. Testing with a More Privileged User:

Try using a user with known administrative privileges in NiFi to perform the API call N.2.
If the call succeeds with the privileged user, it confirms the issue lies with "myaduser" permissions.

Translate
    VidyaSargur
    Community Manager
    VidyaSargur
    Community Manager
    May 20, 2024

    @Lorenzo, Did the response assist in resolving your query? If it did, kindly mark the relevant reply as the solution, as it will aid others in locating the answer more easily in the future.

    Translate
    Regards, Vidya Sargur, Community Manager Was your question answered? Make sure to mark the answer as the accepted solution. If you find a reply useful, say thanks by clicking on the thumbs up button.
    MattWho
    Titanium ⭐️⭐️⭐️
    MattWho
    Titanium ⭐️⭐️⭐️
    May 20, 2024

    @Lorenzo 

    Based on log output shared the Spnego based authentication was successful and you have an authorization problem for your Spnego authenticated user.

    NiFi Authorization is case sensitive, so the user identity returned via kerberos-provider login provider is likely not the exact same user identity string returned via Spnego based kerberos authentication. 

    "myuserad" is a different user identity then "myaduser" and different user identity then "MyAduser" and different user identity then "myaduser@domain.com" and .etc...

    NiFi provides identity mapping properties which can be used to manipulate the user identity returned by different user authentication methods before the final manipulated user identity is passed over the the NiFi authorizer to check for proper authorization(s).  These are added to the nifi.properties file:

    NOTE: keep in mind that mapping patterns are checked against the user identity output during authentication in an alpha-numeric order.  First pattern (regex) to match has its value and transform applied at which time not additional mapping patterns will get evaluated.  So as your pattern regular expressions get more generic the farther down the alpha-numeric list they need to be.

    Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

    Thank you,
    Matt

    Translate
      Lorenzo
      LorenzoAuthorAnswer
      Gold ⭐️
      May 27, 2024

      @MattWho 

      To authenticate to the web ui in NiFi i use the ldap credentials (myuser). For Kerberos authentication via shell I use myuser@REALM. After setting the following parameters in nifi:

      nifi.security.identity.mapping.pattern.kerb=^(.*?)(?:@.*?)$
      nifi.security.identity.mapping.value.kerb=$1
      nifi.security.identity.mapping.transform.kerb=NONE

      Now the token via kerberos works and I no longer get permission errors.

      Thanks!

      Lorenzo

       
      Translate
        Terms & ConditionsAccessibility statement