Created 01-05-2026 10:19 PM
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/bucke...
{
"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.
Created 01-06-2026 05:55 AM
@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
Created 01-06-2026 10:55 AM
@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).
Created 01-07-2026 06:43 AM
@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.
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
Created 01-08-2026 02:44 AM
@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