Member since
05-19-2025
3
Posts
0
Kudos Received
0
Solutions
01-02-2026
12:32 PM
Environment: NiFi Registry: [2.4.0] Deployment: Kubernetes, Helm, Zarf Authentication: OIDC via Keycloak Client: Golang automation job running in the cluster Goal: I am running a Golang job in Kubernetes to perform initial configuration of the NiFi Registry (creating buckets/flows). The job fetches an Access Token from Keycloak and sends it in the Authorization: Bearer header to the Registry API endpoint: GET /nifi-registry-api/access. Issue: The request fails with a 401, and the NiFi Registry logs show an IllegalArgumentException indicating an algorithm mismatch in the JWT signature validation The logs related to this request are attached.Analysis of these logs The Access Token issued by Keycloak is signed using RS256 (asymmetric RSA), which requires a public key to verify. However, the stack trace explicitly shows an IllegalArgumentException stating that the validation logic cannot handle asymmetric algorithms. It seems that the Registry's JwtIdentityProvider is attempting to validate the incoming token using HMAC. We don't see this mismatch with NiFi itself, only the NiFi registry. We are able to do configuration and setup on the NiFi application, but when trying to access NiFi Registry with a token from keycloak, we see this token error. Is there a way to configure the registry to accept RS256 tokens? Is there an alternative approach to making requests against the NiFi Registry using some sort of service account? We need to have the NiFi Registry configured with keycloak, but we also need this configuration job to run at deployment time to do setup. We won't have users created through the UI yet that we can leverage. I can also post the decoded token contents if that helps, but it seems like it's an issue with the actual token signing algorithms and not the content of the token. At least that's my assumption.
... View more
Labels:
- Labels:
-
Apache NiFi
-
NiFi Registry
05-23-2025
12:58 PM
Thanks. I don't fully understand the differences between the policies you can modify by right clicking on the canvas and selecting "Manage Access Policies" and the policies you can modify by selecting the dropdown on the top right and selecting "Policies". In either case, the right click and "Manage Access Policies" approach worked.
... View more
05-20-2025
03:22 PM
I'm encountering persistent issues setting up NiFi 2.4.0 on Kubernetes (deployed via a Helm chart, celtic) with OIDC authentication (Keycloak) for an initial admin user. My goal is to have a specific OIDC user (e.g., 'nifi-admin') fully permissioned to manage flows and processors upon deployment. When I first start up the pod, the users and authorizations file look like the following. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
<policies>
<policy identifier="f99bccd1-a30e-3e4a-98a2-dbc708edc67f" resource="/flow" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="b8775bd4-704a-34c6-987b-84f2daf7a515" resource="/restricted-components" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="627410be-1717-35b4-a06f-e9362b89e0b7" resource="/tenants" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="15e4e0bd-cb28-34fd-8587-f8d15162cba5" resource="/tenants" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ff96062a-fa99-36dc-9942-0f6442ae7212" resource="/policies" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ad99ea98-3af6-3561-ae27-5bf09e1d969d" resource="/policies" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="2e1015cb-0fed-3005-8e0d-722311f21a03" resource="/controller" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="c6322e6c-4cc1-3bcc-91b3-2ed2111674cf" resource="/controller" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="287edf48-da72-359b-8f61-da5d4c45a270" resource="/proxy" action="W">
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
</policies>
</authorizations> It appears I can't interact with the flows and process groups with these policies and permissions. Everything is grayed out However, when I delete the users and authorizations file and restart the statefulset, I am now able to interact with the necessary parts. The new authorizations file looks like the following <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<authorizations>
<policies>
<policy identifier="f99bccd1-a30e-3e4a-98a2-dbc708edc67f" resource="/flow" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ad087445-b630-3030-a326-5e39fdf95337" resource="/data/process-groups/efc2e3d9-0196-1000-3993-94c802173dfb" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="6d417de5-4472-3162-9d67-7aa6068e8b41" resource="/data/process-groups/efc2e3d9-0196-1000-3993-94c802173dfb" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="5218517d-c8f8-39c6-98ff-66acaa37a590" resource="/process-groups/efc2e3d9-0196-1000-3993-94c802173dfb" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="206d7cf3-de24-35f7-ab5b-129a65139f23" resource="/process-groups/efc2e3d9-0196-1000-3993-94c802173dfb" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="b8775bd4-704a-34c6-987b-84f2daf7a515" resource="/restricted-components" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="627410be-1717-35b4-a06f-e9362b89e0b7" resource="/tenants" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="15e4e0bd-cb28-34fd-8587-f8d15162cba5" resource="/tenants" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ff96062a-fa99-36dc-9942-0f6442ae7212" resource="/policies" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ad99ea98-3af6-3561-ae27-5bf09e1d969d" resource="/policies" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="2e1015cb-0fed-3005-8e0d-722311f21a03" resource="/controller" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="c6322e6c-4cc1-3bcc-91b3-2ed2111674cf" resource="/controller" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="287edf48-da72-359b-8f61-da5d4c45a270" resource="/proxy" action="W">
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
</policies>
</authorizations> I tried rectifying this by adding an init container that will essentially populate the files with what they need at startup. The following authorizations file is hardcoded and added to the specific path within the pod. <authorizations>
<policies>
<policy identifier="f99bccd1-a30e-3e4a-98a2-dbc708edc67f" resource="/flow" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="d70f87b2-11d4-30f9-9671-5473a18d857a" resource="/data/process-groups/root" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="f5b1762c-6f99-3037-8726-fdbff8366549" resource="/data/process-groups/root" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="a2e73784-9fa0-3934-85d1-334aff29bc59" resource="/process-groups/root" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="67277589-3a48-3d30-9996-a4dd2621dbf2" resource="/process-groups/root" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="b8775bd4-704a-34c6-987b-84f2daf7a515" resource="/restricted-components" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="627410be-1717-35b4-a06f-e9362b89e0b7" resource="/tenants" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="15e4e0bd-cb28-34fd-8587-f8d15162cba5" resource="/tenants" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ff96062a-fa99-36dc-9942-0f6442ae7212" resource="/policies" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="ad99ea98-3af6-3561-ae27-5bf09e1d969d" resource="/policies" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="2e1015cb-0fed-3005-8e0d-722311f21a03" resource="/controller" action="R">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
<policy identifier="c6322e6c-4cc1-3bcc-91b3-2ed2111674cf" resource="/controller" action="W">
<user identifier="0482ca97-7afc-3d5a-8a3f-21803898bde0"/>
</policy>
<policy identifier="287edf48-da72-359b-8f61-da5d4c45a270" resource="/proxy" action="W">
<user identifier="d0e7bf59-f2a1-3b70-a8bb-fb51bcdca184"/>
</policy>
</policies>
</authorizations> Unfortunately, this is still not giving me the necessary permissions. Everything is grayed out. Why aren't the proper permissions populated when I start the statefulset? Why does it seem to fix this when I remove the files and restart it? And why doesn't my init container approach work? Idk if that is related to the "root" I am specifying after process groups. Another thing maybe worth mentioning is my authorizers.xml having this access provider <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">./auth-conf/authorizations.xml</property>
<property name="Initial Admin Identity">nifi-admin</property>
<property name="Node Group"/>
<property name="Node Identity 0">CN=nifi-0.nifi-headless.nifi.svc.nifi.uds.dev, OU=NIFI</property>
</accessPolicyProvider>
... View more
Labels:
- Labels:
-
Apache NiFi