question Re: Authorization issue between NiFi and NiFi Registry in Support Questions

Authorization issue between NiFi and NiFi Registry

pnac03 — Tue, 06 Jan 2026 06:19:07 GMT

I am trying to connect between NiFi and NiFi Registry. I'm able to authenticate with Registry from NiFi but I'm unable to see the buckets, not even the public ones. I've configured a SSL Context on NiFi that references a truststore containing Registry's Truststore and Keystore. I've imported NiFi's node certificates into the truststore on the registry's side. I've given the 'proxy and manage user bucket' permissions to the Node's identity in the Registry UI and Read Write and Execute permission to the same user on the Buckets. But I'm still unable to see the buckets on NiFi's UI. The API Responses also indicate that NiFi only has read permissions to the buckets. This is as if there is some anomaly during login..

Note:
1) I'm using a Clustered NiFi Setup. I have verified that my node identity is 'CN=node-0-nifikop'.
2) Both NiFi Cluster (NiFiKop) and the NiFi Registry (Helm Release) are running inside a Kubernetes Cluster

Error Samples:

The Error on NiFi UI: Error.jpeg
Registry Bucket Policies: Bucket Policies.jpeg
Registry User Permissions: Registry User Permissions.jpeg

The following is the Truststore referenced in NiFi's SSL Contexts

====================================== NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED ====================================== Keystore type: PKCS12 Keystore provider: SUN Your keystore contains 4 entries Alias name: ca-cert Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: O=3SCDemo, CN=3SCDemo-CA Issuer: O=3SCDemo, CN=3SCDemo-CA Serial number: 1745e28f179548d468a6ece0d0d497be8b15d74f Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ +... ] ] #2: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen: no limit ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #4: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ +... ] ] ******************************************* ******************************************* Alias name: nifi-ca Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: CN=nifikop-ca.dev.cluster.local Issuer: CN=nifikop-ca.dev.cluster.local Serial number: Valid from: Mon Dec 29 07:08:21 UTC 2025 until: Sun Mar 29 07:08:21 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen: no limit ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ .c.. ] ] ******************************************* ******************************************* Alias name: nifi-prod Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: CN=node-0-nifikop Issuer: CN=nifikop-ca.dev.cluster.local Serial number: Valid from: Mon Dec 29 07:08:26 UTC 2025 until: Sun Mar 29 07:08:26 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 4096-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ .c.. ] ] #2: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen: undefined ] #3: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ clientAuth serverAuth ] #4: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: nifikop-headless.dev.svc.cluster.local DNSName: nifikop-0-node.nifikop-headless.dev.svc.cluster.local DNSName: nifikop-headless.dev.svc DNSName: nifikop-0-node.nifikop-headless.dev.svc DNSName: nifikop-headless.dev DNSName: nifikop-0-node.nifikop-headless.dev DNSName: nifikop-headless DNSName: nifikop-0-node.nifikop-headless DNSName: nifikop-0-node DNSName: adinifiapp.com URIName: spiffe://nifikop/ns/dev/nifiuser/node-0-nifikop ] ******************************************* ******************************************* Alias name: nifi-reg-keystore-import Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: O=3SCDemo, CN=nifi-registry Issuer: O=3SCDemo, CN=3SCDemo-CA Serial number: Valid from: Sat Dec 20 19:51:52 UTC 2025 until: Sun Dec 20 19:51:52 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ +... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:false PathLen: undefined ] #3: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] #4: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment ] #5: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: nifi-registry DNSName: nifi-registry.dev DNSName: nifi-registry.dev.svc DNSName: nifi-registry.dev.svc.cluster.local DNSName: localhost IPAddress: 127.0.0.1 ] #6: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ .... ] ] ******************************************* ******************************************* ====================================== NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED ======================================

The following is the truststore of NiFi Registry

====================================== NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED ====================================== Keystore type: PKCS12 Keystore provider: SUN Your keystore contains 3 entries Alias name: ca-cert Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: O=3SCDemo, CN=3SCDemo-CA Issuer: O=3SCDemo, CN=3SCDemo-CA Serial number: Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ +... ] ] #2: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen: no limit ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #4: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ +... ] ] ******************************************* ******************************************* Alias name: nifi-ca Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: CN=nifikop-ca.dev.cluster.local Issuer: CN=nifikop-ca.dev.cluster.local Serial number: Valid from: Mon Dec 29 07:08:21 UTC 2025 until: Sun Mar 29 07:08:21 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen: no limit ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: EB 16 CA 18 17 7C 14 24 E3 FC 9D E7 EE CA A6 80 .......$........ 0010: A1 63 D1 BB .c.. ] ] ******************************************* ******************************************* Alias name: nifi-prod Creation date: Jan 5, 2026 Entry type: trustedCertEntry Owner: CN=node-0-nifikop Issuer: CN=nifikop-ca.dev.cluster.local Serial number: Valid from: Mon Dec 29 07:08:26 UTC 2025 until: Sun Mar 29 07:08:26 UTC 2026 Certificate fingerprints: SHA1: SHA256: Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 4096-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ .c.. ] ] #2: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen: undefined ] #3: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ clientAuth serverAuth ] #4: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: nifikop-headless.dev.svc.cluster.local DNSName: nifikop-0-node.nifikop-headless.dev.svc.cluster.local DNSName: nifikop-headless.dev.svc DNSName: nifikop-0-node.nifikop-headless.dev.svc DNSName: nifikop-headless.dev DNSName: nifikop-0-node.nifikop-headless.dev DNSName: nifikop-headless DNSName: nifikop-0-node.nifikop-headless DNSName: nifikop-0-node DNSName: adinifiapp.com URIName: spiffe://nifikop/ns/dev/nifiuser/node-0-nifikop ] ******************************************* ******************************************* ====================================== NOTE: SENSITIVE INFORMATION HAS BEEN OBFUSCATED ======================================

This is the kind of response i get when I hit this API:
https://domain-name/context-path/nifi-api/flow/registries/9e779b09-0199-1000-ffff-ffffec7d027b/buckets

{ "buckets": [ { "id": "38257128-3406-4fe7-9a7e-967340552ca8", "bucket": { "id": "38257128-3406-4fe7-9a7e-967340552ca8", "name": "fddf", "description": "", "created": 1760507389992 }, "permissions": { "canRead": true, "canWrite": false } } ] }

Another Clarification:
If I understand this right, in case of a clustered setup, the certificate referenced in the SSL Context is proxied via the Node's Identity while NiFi presents its own identity to Registry during the mTLS Handshake. So what registry would see in case of a clustered nifi setup would be the node's identity instead of that Certificate which is referenced in NiFi's SSL Contexts. I have verified the same even from Registry using tcpdump in my setup and I do see that the incoming CN name from nifi is CN=node-0-nifikop instead of what is referenced in the SSL Context.

Re: Authorization issue between NiFi and NiFi Registry

MattWho — Tue, 06 Jan 2026 13:55:39 GMT

@pnac03

Some clarification:

The NiFi Registry Client (NifiRegistryFlowRegistryClient) will use the configured keystore and truststore in the defined SLS ContextService if configured to authenticate with the target NiFi Registry URL. This Client Auth certificate will proxy the request on behalf of the user identity displayed in the upper right corner of the NiFi UI where this NiFi Registry client is being used. If an SSL Context Service is not defined in the Registry client, the Registry client will use the keystore and truststore configured in the NiFi node's nifi.properties files. Now it is common in a Nifi cluster setup that every node has its own unique keystore. As such you would need to make sure that all the clientAuth certificates are properly authorized to proxy user requests in the target NiFi (this applies no matter which NiFi node you are logged into when making the call to NiFi-Registry since the request gets replicated by all nodes.).

That brings into question your statement below:

I have verified the same even from Registry using tcpdump in my setup and I do see that the incoming CN name from nifi is CN=node-0-nifikop instead of what is referenced in the SSL Context.

Can you share the verbose output for your PrivateKeyEntry? Does it contain only 1 PrivateKey Entry or multiple? (Must contain only one since NiFi Registry client does not provide a configuration option to specify a specific certificate by alias name.

-----
Public bucket clarification:

A public bucket allows any user to import a flow from that bucket to the Canvas of a NiFi. It does not allow any user to write (start version control) of a new dataflow or commit new version of an existing version controlled dataflow to the public bucket. Writing a new flow to a bucket will require proper write permission on the bucket regardless of whether the bucket is public or not.

-------
User Identities:
The user identities coming from the ssl context services and proxied are case sensitive "User 2" and "user 2" would be treated as to different users in both NiFi and NiFi-Registry.

The User identities are evaluated against any identity mappings that may be configured in the nifi-registry.properties file, so you'll want to take a look at these to make sure they are not manipulating the user identity string or clientAuth certificate DN.

Please help our community grow. 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

Re: Authorization issue between NiFi and NiFi Registry

pnac03 — Tue, 06 Jan 2026 18:55:47 GMT

@MattWho Thanks for the quick reply! Thanks for the clarification on the proxying.
I checked my setup and I have these three questions:

1) Do you need the verbose output from the tcpdump utility or from my NiFi Node's keystore ?
I've shared the verbose output of my NiFi Node's keystore below. It does seem that my keystore has 2 aliases (or PrivateKeyEntries) indeed, one of them carrying the certificate involved i.e. CN=node-0-nifikop

nifi@nifikop-0-node:/var/run/secrets/java.io/keystores/server$ keytool --list -v --keystore keystore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: ca
Creation date: Nov 24, 2025
Entry type: trustedCertEntry

Owner: CN=nifikop-ca.dev.cluster.local
Issuer: CN=nifikop-ca.dev.cluster.local
Serial number: f6b7c60ecee584faa4b5778b6667a7fb
Valid from: Mon Oct 13 21:43:39 UTC 2025 until: Sun Jan 11 21:43:39 UTC 2026
Certificate fingerprints:
SHA1: 56:05:68:C3:15:7F:82:A0:C8:90:6D:DF:BE:02:3E:10:7F:9D:C0:05
SHA256: 32:46:2C:84:04:D0:91:D9:A8:05:D3:8B:07:E2:09:1C:E3:AC:75:17:77:CB:86:EA:BE:90:9E:09:6F:77:4B:3A
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen: no limit
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
Key_CertSign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 0C A4 00 26 2F 44 ED FF BD 2C 3F 76 8F 6C FA CB ...&/D...,?v.l..
0010: 2A 48 0E A2 *H..
]
]




*******************************************
*******************************************


Alias name: certificate
Creation date: Nov 24, 2025
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=node-0-nifikop
Issuer: CN=nifikop-ca.dev.cluster.local
Serial number: b15ef24eef5835b02b5921d40726a453
Valid from: Mon Nov 24 06:29:55 UTC 2025 until: Sun Feb 22 06:29:55 UTC 2026
Certificate fingerprints:
SHA1: 80:60:7E:27:D9:8A:3D:10:C0:47:0E:72:C1:31:17:D7:7C:3E:3E:AF
SHA256: 07:25:53:5B:05:00:5F:16:E6:12:B9:44:77:D6:A6:7C:83:F8:80:F7:4A:DB:F3:F6:DF:32:F6:31:56:AC:66:FF
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 0C A4 00 26 2F 44 ED FF BD 2C 3F 76 8F 6C FA CB ...&/D...,?v.l..
0010: 2A 48 0E A2 *H..
]
]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]

#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
clientAuth
serverAuth
]

#4: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: nifikop-headless.dev.svc.cluster.local
DNSName: nifikop-0-node.nifikop-headless.dev.svc.cluster.local
DNSName: nifikop-headless.dev.svc
DNSName: nifikop-0-node.nifikop-headless.dev.svc
DNSName: nifikop-headless.dev
DNSName: nifikop-0-node.nifikop-headless.dev
DNSName: nifikop-headless
DNSName: nifikop-0-node.nifikop-headless
DNSName: nifikop-0-node
DNSName: nifi-internal.3sc.com
URIName: spiffe://nifikop/ns/dev/nifiuser/node-0-nifikop
]




*******************************************
*******************************************




Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12".

Note: My NiFi Cluster also has an Operator and this is all deployed inside a Kubernetes Cluster. Cert-manager is used to generate and manage these certificates.

2) Does the TLS Version matter in the SSL Context? Currently it's set to 'TLS' and I tried even with SSL and it hadn't worked.

3) Although I've referenced another working certificate (with clientAuth EKUs) in the SSL Context which has "O=3SCDemo, CN=nifi-registry" as the Subject Name and exactly one alias in that keystore, why is NiFi is still presenting the node's certificate referenced in nifi.properties to the registry (as I had confirmed using tcpdump). I didn't see any other CN Name except CN=node-0-nifikop).

Re: Authorization issue between NiFi and NiFi Registry

MattWho — Wed, 07 Jan 2026 14:43:20 GMT

@pnac03

1). The keystore configured in NiFi (nifi.properies and in SSL Context Service controller services) and NiFi-Registry (nifi-registry.properties) must contain only 1 PrivateKeyEntry since there is no way to control which is used when multiple exist. The verbose output you shared for your keystore shows it containing only 1 PrivateKeyEntry.

2) TLS will negotiate the highest mutually supported version between client and server in the mTLS exchange.

3) You did not share the verbose output for the keystore used in the SSL Context Service you configured your NiFiFlowRegistry client to use. Would also need to see the nifi-registry.properties file to inspect all the identity mapping properties set to see how the DNs might be manipulated.

Thank you,
Matt

Re: Authorization issue between NiFi and NiFi Registry

pnac03 — Thu, 08 Jan 2026 10:44:40 GMT

@MattWho Thanks for the clarifications.

Here's the verbose output of the keystore used in the SSL Context Service for my NiFiFlowRegistryClient

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: nifi-registry
Creation date: Dec 20, 2025
Entry type: PrivateKeyEntry
Certificate chain length: 2

Certificate[1]:

Owner: O=3SCDemo, CN=nifi-registry
Issuer: O=3SCDemo, CN=3SCDemo-CA
Serial number: 
Valid from: Sat Dec 20 19:51:52 UTC 2025 until: Sun Dec 20 19:51:52 UTC 2026
Certificate fingerprints:
 SHA1: SHA256: 
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions: 
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
                                       +...
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:false
  PathLen: undefined
]
#3: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
  serverAuth
  clientAuth
]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
  DNSName: nifi-registry
  DNSName: nifi-registry.dev
  DNSName: nifi-registry.dev.svc
  DNSName: nifi-registry.dev.svc.cluster.local
  DNSName: localhost
  IPAddress: 127.0.0.1
]
#6: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
                                       ....
]
]

Certificate[2]:

Owner: O=3SCDemo, CN=3SCDemo-CA
Issuer: O=3SCDemo, CN=3SCDemo-CA
Serial number: 
Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026
Certificate fingerprints:
 SHA1: SHA256: 
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions: 
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
                                        +...
]
]
#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen: no limit
]
#3: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]
#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
                                    +...
]
]

*******************************************
*******************************************

Please find the nifi-registry.properties file:

# web properties #
nifi.registry.web.war.directory=./lib
nifi.registry.web.http.host=
nifi.registry.web.http.port=
nifi.registry.web.https.host=nifi-registry-0
nifi.registry.web.https.port=18443
nifi.registry.web.https.network.interface.default=
nifi.registry.web.https.application.protocols=h2 http/1.1
nifi.registry.web.jetty.working.directory=./work/jetty
nifi.registry.web.jetty.threads=200
nifi.registry.web.should.send.server.version=true

# security properties #
nifi.registry.security.keystore=/opt/certs/nifi-registry-keystore.jks
nifi.registry.security.keystoreType=JKS
nifi.registry.security.keystorePasswd=newps
nifi.registry.security.keyPasswd=newps
nifi.registry.security.truststore=/opt/certs/nifi-registry-truststore.jks

nifi.registry.security.truststoreType=JKS
nifi.registry.security.truststorePasswd=newps
nifi.registry.security.needClientAuth=false
nifi.registry.security.authorizers.configuration.file=./conf/authorizers.xml
nifi.registry.security.authorizer=managed-authorizer
nifi.registry.security.identity.providers.configuration.file=./conf/identity-providers.xml
nifi.registry.security.identity.provider=ldap-identity-provider

# providers properties #
nifi.registry.providers.configuration.file=./conf/providers.xml

# registry alias properties #
nifi.registry.registry.alias.configuration.file=./conf/registry-aliases.xml

# extensions working dir #
nifi.registry.extensions.working.directory=./work/extensions

# legacy database properties, used to migrate data from original DB to new DB below
# NOTE: Users upgrading from 0.1.0 should leave these populated, but new installs after 0.1.0 should leave these empty
nifi.registry.db.directory=
nifi.registry.db.url.append=

# database properties
nifi.registry.db.url=jdbc:h2:./database/nifi-registry-primary;AUTOCOMMIT=OFF;DB_CLOSE_ON_EXIT=FALSE;LOCK_MODE=3;LOCK_TIMEOUT=25000;WRITE_DELAY=0;AUTO_SERVER=FALSE
nifi.registry.db.driver.class=org.h2.Driver
nifi.registry.db.driver.directory=
nifi.registry.db.username=nifireg
nifi.registry.db.password=nifireg
nifi.registry.db.maxConnections=5
nifi.registry.db.sql.debug=false

# extension directories #
# Each property beginning with "nifi.registry.extension.dir." will be treated as location for an extension,
# and a class loader will be created for each location, with the system class loader as the parent
#
#nifi.registry.extension.dir.1=/path/to/extension1
#nifi.registry.extension.dir.2=/path/to/extension2
nifi.registry.extension.dir.aws=./ext/aws/lib

# Identity Mapping Properties #
# These properties allow normalizing user identities such that identities coming from different identity providers
# (certificates, LDAP, Kerberos) can be treated the same internally in NiFi. The following example demonstrates normalizing
# DNs from certificates and principals from Kerberos into a common identity string:

#
# nifi.registry.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$
# nifi.registry.security.identity.mapping.value.dn=$1@$2
# nifi.registry.security.identity.mapping.transform.dn=NONE
# nifi.registry.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
# nifi.registry.security.identity.mapping.value.kerb=$1@$2
# nifi.registry.security.identity.mapping.transform.kerb=UPPER

# Group Mapping Properties #
# These properties allow normalizing group names coming from external sources like LDAP. The following example
# lowercases any group name.
#
# nifi.registry.security.group.mapping.pattern.anygroup=^(.*)$
# nifi.registry.security.group.mapping.value.anygroup=$1
# nifi.registry.security.group.mapping.transform.anygroup=LOWER

# kerberos properties #
nifi.registry.kerberos.krb5.file=
nifi.registry.kerberos.spnego.principal=
nifi.registry.kerberos.spnego.keytab.location=
nifi.registry.kerberos.spnego.authentication.expiration=12 hours

# OIDC #

nifi.registry.security.user.oidc.discovery.url=
nifi.registry.security.user.oidc.connect.timeout=
nifi.registry.security.user.oidc.read.timeout=
nifi.registry.security.user.oidc.client.id=
nifi.registry.security.user.oidc.client.secret=
nifi.registry.security.user.oidc.preferred.jwsalgorithm=
nifi.registry.security.user.oidc.additional.scopes=${nifi.registry.security.user.oidc.additional.scopes}
nifi.registry.security.user.oidc.claim.identifying.user=${nifi.registry.security.user.oidc.claim.identifying.user}
nifi.registry.security.user.oidc.claim.groups=groups

# revision management #
# This feature should remain disabled until a future NiFi release that supports the revision API changes
nifi.registry.revisions.enabled=false

Re: Authorization issue between NiFi and NiFi Registry

pnac03 — Tue, 20 Jan 2026 09:06:09 GMT

@MattWho Were you able to check the outputs from my last reply? Tried other methods, still no luck..

Re: Authorization issue between NiFi and NiFi Registry

MattWho — Tue, 20 Jan 2026 13:42:21 GMT

@pnac03

Based on your nifi-registry.properties file, there is no user identity manipulation happening. This means that the full DistinquishedName (DN) presented by NiFi in the MutualTLS exchange with NiFi-Registry will be the user identity for the registry client connecting to your NiFi-Registry. That means that the full DN needs to be authorized in NiFi-Registry properly. That DN needs to be authorized for the following Special Privileges:

"Can manage buckets" - Read
"Can proxy user requests" - Read, Write, and Delete

From the keystore you shared fro your SSL Context Service, we can see it properly contains only one PrivateKeyEntry and the DN for that clientAuth privateKey is:

O=3SCDemo, CN=nifi-registry

So the above (case sensitive) MUST exist as a user in your NiFi-Registry and have granted to it the above special Privileges mentioned.

Also, the user identity of the user logged into NiFi (as displayed in upper right corner - case sensitive) when attempting start version control on a process group in NiFi will need to exist as a user in your NiFi-Registry and be authorized properly directly on the bucket in which you want to version control the process group (this is different then the Special Privileges section in NiFi-Registry).

Read Bucket - Allows user to see version controlled flows in the bucket.
Write Bucket - Allows user to commit new version controlled flows to the bucket
Delete Bucket - allows user to delete a bucket.

Please help our community grow. 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

Re: Authorization issue between NiFi and NiFi Registry

pnac03 — Sat, 14 Feb 2026 21:10:27 GMT

Thanks @MattWho

Probably as a result of a nifikop-operator based, LDAP-Authenticated, Clustered Nifi setup, I had to give permissions to both the DN you mentioned and my nifi user (as visible on the top right corner of my nifi UI).

Effective Permissions:
- Can Proxy User Requests and Can Manage Buckets to both the Users
- Read, Write and Delete (if required) access to my buckets

Now I'm able to list and interact with my buckets from my nifi UI!