Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi-registry/pull/57#discussion_r157111855
--- Diff: nifi-registry-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -14,7 +14,1303 @@
// See the License for the specific language governing permissions and
// limitations under the License.
//
-NiFi Registry System Administrator's Guide
-=================================
+Apache NiFi Registry System Administrator's Guide
+==========================================
Apache NiFi Team <[email protected]>
:homepage: http://nifi.apache.org
+
+System Requirements
+-------------------
+NiFi Registry has the following minimum system requirements:
+
+* Requires Java 8 or newer
+* Supported Operating Systems:
+** Linux
+** Unix
+** Mac OS X
+* Supported Web Browsers:
+** Google Chrome: Current & (Current - 1)
+** Mozilla FireFox: Current & (Current - 1)
+** Safari: Current & (Current - 1)
+
+**Note** Under sustained and extremely high throughput the CodeCache
settings may need to be tuned to avoid sudden performance loss. See the
<<bootstrap_properties>> section for more information.
+
+How to install and start NiFi Registry
+--------------------------------------
+
+* Linux/Unix/OS X
+** Decompress and untar into desired installation directory
+** Make any desired edits in files found under <installdir>/conf
+** From the <installdir>/bin directory, execute the following commands by
typing ./nifi-registry.sh <command>:
+*** start: starts NiFi Registry in the background
+*** stop: stops NiFi Registry that is running in the background
+*** status: provides the current status of NiFi Registry
+*** run: runs NiFi Registry in the foreground and waits for a Ctrl-C to
initiate shutdown of NiFi Registry
+*** install: installs NiFi Registry as a service that can then be
controlled via
+**** service nifi-registry start
+**** service nifi-regsitry stop
+**** service nifi-registry status
+
+
+When NiFi Registry first starts up, the following files and directories
are created:
+
+* flow_storage directory
+* work directory
+* logs directory
+* run directory
+
+See the <<system_properties>> section of this guide for more information
about NiFi Registry configuration files.
+
+
+Configuration Best Practices
+----------------------------
+
+NOTE: If you are running on Linux, consider these best practices. Typical
Linux defaults are not necessarily well tuned for the needs of an IO intensive
application like NiFi Registry. For all of these areas, your distribution's
requirements may vary. Use these sections as advice, but consult your
distribution-specific documentation for how best to achieve these
recommendations.
+
+Maximum File Handles::
+NiFi Registry will at any one time potentially have a very large number of
file handles open. Increase the limits by editing '/etc/security/limits.conf'
to add something like
+----
+* hard nofile 50000
+* soft nofile 50000
+----
+Maximum Forked Processes::
+NiFi Registry may be configured to generate a significant number of
threads. To increase the allowable number edit '/etc/security/limits.conf'
+----
+* hard nproc 10000
+* soft nproc 10000
+----
+And your distribution may require an edit to
/etc/security/limits.d/90-nproc.conf by adding
+----
+* soft nproc 10000
+----
+
+Increase the number of TCP socket ports available::
+This is particularly important if your flow will be setting up and tearing
+down a large number of sockets in small period of time.
+----
+sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"
+----
+
+Set how long sockets stay in a TIMED_WAIT state when closed::
+You don't want your sockets to sit and linger too long given that you want
to be able to quickly setup and teardown new sockets. It is a good idea to
read more about it but to adjust do something like
+----
+sudo sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait="1"
+----
+
+Tell Linux you never want NiFi to swap::
+Swapping is fantastic for some applications. It isn't good for something
like
+NiFi Registry that always wants to be running. To tell Linux you'd like
swapping off you
+can edit '/etc/sysctl.conf' to add the following line
+----
+vm.swappiness = 0
+----
+For the partitions handling the various NiFi Registry repos turn off
things like 'atime'.
+Doing so can cause a surprising bump in throughput. Edit the '/etc/fstab'
file
+and for the partition(s) of interest add the 'noatime' option.
+
+
+Security Configuration
+----------------------
+
+NiFi Registry provides several different configuration options for
security purposes. The most important properties are those under the
+"security properties" heading in the _nifi-registry.properties_ file. In
order to run securely, the following properties must be set:
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`nifi.registry.security.keystore` | Filename of the Keystore that
contains the server's private key.
+|`nifi.registry.security.keystoreType` | The type of Keystore. Must be
either `PKCS12` or `JKS`. JKS is the preferred type, PKCS12 files will be
loaded with BouncyCastle provider.
+|`nifi.registry.security.keystorePasswd` | The password for the Keystore.
+|`nifi.registry.security.keyPasswd` | The password for the certificate in
the Keystore. If not set, the value of `nifi.registry.security.keystorePasswd`
will be used.
+|`nifi.registry.security.truststore` | Filename of the Truststore that
will be used to authorize those connecting to NiFi Registry. A secured
instance with no Truststore will refuse all incoming connections.
+|`nifi.registry.security.truststoreType` | The type of the Truststore.
Must be either `PKCS12` or `JKS`. JKS is the preferred type, PKCS12 files will
be loaded with BouncyCastle provider.
+|`nifi.registry.security.truststorePasswd` | The password for the
Truststore.
+|`nifi.registry.security.needClientAuth` | Set to `true` to specify that
connecting clients must authenticate themselves. This property is used by the
NiFi Registry cluster protocol to indicate that nodes in the cluster will be
authenticated and must have certificates that are trusted by the Truststores.
+|==================================================================================================================================================
+
+Once the above properties have been configured, we can enable the User
Interface to be accessed over HTTPS instead of HTTP. This is accomplished
+by setting the `nifi.web.https.host` and `nifi.web.https.port` properties.
The `nifi.web.https.host` property indicates which hostname the server
+should run on. If it is desired that the HTTPS interface be accessible
from all network interfaces, a value of `0.0.0.0` should be used. To allow
+admins to configure the application to run only on specific network
interfaces, `nifi.registry.web.http.network.interface*` or
`nifi.registry.web.https.network.interface*` properties can be specified.
+
+NOTE: It is important when enabling HTTPS that the
`nifi.registry.web.http.port` property be unset.
+
+Similar to `nifi.registry.security.needClientAuth`, the web server can be
configured to require certificate based client authentication for users
accessing
+the User Interface. In order to do this it must be configured to not
support username/password authentication using
<<ldap_login_identity_provider>> or <<kerberos_login_identity_provider>>.
Either of these options
+will configure the web server to WANT certificate based client
authentication. This will allow it to support users with certificates and those
without
+that may be logging in with their credentials or those accessing
anonymously. If username/password authentication and anonymous access are not
configured,
+the web server will REQUIRE certificate based client authentication. See
<<user_authentication>> for more details.
+
+
+TLS Generation Toolkit
+~~~~~~~~~~~~~~~~~~~~~~
+
+In order to facilitate the secure setup of NiFi Registry, you can use the
`tls-toolkit` command line utility to automatically generate the required
keystores, truststore, and relevant configuration files.
+
+NOTE: JKS keystores and truststores are recommended for NiFi Registry.
This tool allows the specification of other keystore types on the command line
but will ignore a type of PKCS12 for use as the truststore because that format
has some compatibility issues between BouncyCastle and Oracle implementations.
+
+The `tls-toolkit` command line tool has two primary modes of operation:
+
+1. Standalone -- generates the certificate authority, keystores,
truststores, and nifi-registry.properties files in one command.
+2. Client/Server mode -- uses a Certificate Authority Server that accepts
Certificate Signing Requests from clients, signs them, and sends the resulting
certificates back. Both client and server validate the otherâs identity
through a shared secret.
+
+Standalone
+^^^^^^^^^^
+Standalone mode is invoked by running `./bin/tls-toolkit.sh standalone -h`
which prints the usage information along with descriptions of options that can
be specified.
+
+You can use the following command line options with the `tls-toolkit` in
standalone mode:
+
+* `-a`,`--keyAlgorithm <arg>` Algorithm to use for
generated keys (default: `RSA`)
+* `-B`,`--clientCertPassword <arg>` Password for client
certificate. Must either be one value or one for each client DN (auto-generate
if not specified)
+* `-c`,`--certificateAuthorityHostname <arg>` Hostname of NiFi
Certificate Authority (default: `localhost`)
+* `-C`,`--clientCertDn <arg>` Generate client
certificate suitable for use in browser with specified DN (Can be specified
multiple times)
+* `-d`,`--days <arg>` Number of days issued
certificate should be valid for (default: `1095`)
+* `-f`,`--nifiPropertiesFile <arg>` Base `nifi.properties`
file to update (Embedded file identical to the one in a default NiFi install
will be used if not specified)
+* `-g`,`--differentKeyAndKeystorePasswords` Use different generated
password for the key and the keystore
+* `-G`,`--globalPortSequence <arg>` Use sequential ports that
are calculated for all hosts according to the provided hostname expressions
(Can be specified multiple times, MUST BE SAME FROM RUN TO RUN)
+* `-h`,`--help` Print help and exit
+* `-k`,`--keySize <arg>` Number of bits for
generated keys (default: `2048`)
+* `-K`,`--keyPassword <arg>` Key password to use. Must
either be one value or one for each host (auto-generate if not specified)
+* `-n`,`--hostnames <arg>` Comma separated list of
hostnames
+* `--nifiDnPrefix <arg>` String to prepend to
hostname(s) when determining DN (default: `CN=`)
+* `--nifiDnSuffix <arg>` String to append to
hostname(s) when determining DN (default: `, OU=NIFI`)
+* `-o`,`--outputDirectory <arg>` The directory to output
keystores, truststore, config files (default: `../bin`)
+* `-O`,`--isOverwrite` Overwrite existing host
output
+* `-P`,`--trustStorePassword <arg>` Keystore password to use.
Must either be one value or one for each host (auto-generate if not specified)
+* `-s`,`--signingAlgorithm <arg>` Algorithm to use for
signing certificates (default: `SHA256WITHRSA`)
+* `-S`,`--keyStorePassword <arg>` Keystore password to use.
Must either be one value or one for each host (auto-generate if not specified)
+* `--subjectAlternativeNames <arg>` Comma-separated list of
domains to use as Subject Alternative Names in the certificate
+* `-T`,`--keyStoreType <arg>` The type of keystores to
generate (default: `jks`)
+
+
+Hostname Patterns:
+
+* Square brackets can be used in order to easily specify a range of
hostnames. Example: `[01-20]`
+* Parentheses can be used in order to specify that more than one NiFi
instance will run on the given host(s). Example: `(5)`
+
+Examples:
+
+Create 4 sets of keystore, truststore, nifi.properties for localhost along
with a client certificate with the given DN:
+----
+bin/tls-toolkit.sh standalone -n 'localhost(4)' -C 'CN=username,OU=NIFI'
+----
+
+Create keystore, truststore, nifi.properties for 10 NiFi hostnames in each
of 4 subdomains:
+----
+bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain'
+----
+
+Create 2 sets of keystore, truststore, nifi.properties for 10 NiFi
hostnames in each of 4 subdomains along with a client certificate with the
given DN:
+----
+bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain(2)' -C
'CN=username,OU=NIFI'
+----
+
+
+Client/Server
+^^^^^^^^^^^^^
+Client/Server mode relies on a long-running Certificate Authority (CA) to
issue certificates. The CA can be stopped when youâre not bringing nodes
online.
+
+
+===== Server
+
+The CA server is invoked by running `./bin/tls-toolkit.sh server -h` which
prints the usage information along with descriptions of options that can be
specified.
+
+You can use the following command line options with the `tls-toolkit` in
server mode:
+
+* `-a`,`--keyAlgorithm <arg>` Algorithm to use for
generated keys (default: `RSA`)
+* `--configJsonIn <arg>` The place to read
configuration info from (defaults to the value of configJson), implies
useConfigJson if set (default: `configJson` value)
+* `-d`,`--days <arg>` Number of days issued
certificate should be valid for (default: `1095`)
+* `-D`,`--dn <arg>` The dn to use for the CA
certificate (default: `CN=YOUR_CA_HOSTNAME,OU=NIFI`)
+* `-f`,`--configJson <arg>` The place to write
configuration info (default: `config.json`)
+* `-F`,`--useConfigJson` Flag specifying that all
configuration is read from `configJson` to facilitate automated use (otherwise
`configJson` will only be written to)
+* `-g`,`--differentKeyAndKeystorePasswords` Use different generated
password for the key and the keystore
+* `-h`,`--help` Print help and exit
+* `-k`,`--keySize <arg>` Number of bits for
generated keys (default: `2048`)
+* `-p`,`--PORT <arg>` The port for the
Certificate Authority to listen on (default: `8443`)
+* `-s`,`--signingAlgorithm <arg>` Algorithm to use for
signing certificates (default: `SHA256WITHRSA`)
+* `-T`,`--keyStoreType <arg>` The type of keystores to
generate (default: `jks`)
+* `-t`,`--token <arg>` The token to use to
prevent MITM (required and must be same as one used by clients)
+
+===== Client
+
+The client can be used to request new Certificates from the CA. The client
utility generates a keypair and Certificate Signing Request (CSR) and sends the
CSR to the Certificate Authority. The client is invoked by running
`./bin/tls-toolkit.sh client -h` which prints the usage information along with
descriptions of options that can be specified.
+
+You can use the following command line options with the `tls-toolkit` in
client mode:
+
+* `-a`,`--keyAlgorithm <arg>` Algorithm to use for
generated keys (default: `RSA`)
+* `-c`,`--certificateAuthorityHostname <arg>` Hostname of NiFi
Certificate Authority (default: `localhost`)
+* `-C`,`--certificateDirectory <arg>` The directory to write the
CA certificate (default: `.`)
+* `--configJsonIn <arg>` The place to read
configuration info from, implies `useConfigJson` if set (default: `configJson`
value)
+* `-D`,`--dn <arg>` The DN to use for the
client certificate (default: `CN=<localhost name>,OU=NIFI`) (this is
auto-populated by the tool)
+* `-f`,`--configJson <arg>` The place to write
configuration info (default: `config.json`)
+* `-F`,`--useConfigJson` Flag specifying that all
configuration is read from `configJson` to facilitate automated use (otherwise
`configJson` will only be written to)
+* `-g`,`--differentKeyAndKeystorePasswords` Use different generated
password for the key and the keystore
+* `-h`,`--help` Print help and exit
+* `-k`,`--keySize <arg>` Number of bits for
generated keys (default: `2048`)
+* `-p`,`--PORT <arg>` The port to use to
communicate with the Certificate Authority (default: `8443`)
+* `--subjectAlternativeNames <arg>` Comma-separated list of
domains to use as Subject Alternative Names in the certificate
+* `-T`,`--keyStoreType <arg>` The type of keystores to
generate (default: `jks`)
+* `-t`,`--token <arg>` The token to use to
prevent MITM (required and must be same as one used by CA)
+
+After running the client you will have the CAâs certificate, a keystore,
a truststore, and a `config.json` with information about them as well as their
passwords.
+
+For a client certificate that can be easily imported into the browser,
specify: `-T PKCS12`
+
+[[user_authentication]]
+User Authentication
+-------------------
+
+NiFi Registry supports user authentication via client certificates, via
username/password, via Apache Knox, or via OpenId Connect
(http://openid.net/connect).
+
+Username/password authentication is performed by a 'Login Identity
Provider'. The Login Identity Provider is a pluggable mechanism for
+authenticating users via their username/password. Which Login Identity
Provider to use is configured in the _nifi-registry.properties_ file.
+Currently NiFi offers username/password with Login Identity Providers
options for LDAP and Kerberos.
+
+The `nifi.registry.security.login.identity.provider.configuration.file`
property specifies the configuration file for Login Identity Providers.
+The `nifi.registry.security.identity.provider` property indicates which of
the configured Login Identity Provider should be
+used. By default, this property is not configured meaning that
username/password must be explicitly enabled.
+
+During OpenId Connect authentication, NiFi Registry will redirect users to
login with the Provider before returning to NiFi Registry. NiFi Registry will
then call the Provider to obtain the user identity.
+
+During Apache Knox authentication, NiFi Registry will redirect users to
login with Apache Knox before returning to NiFi Registry. NiFi Registry will
verify the Apache Knox
+token during authentication.
+
+NOTE: NiFi Registry can only be configured for username/password, OpenId
Connect, or Apache Knox at a given time. It does not support running each of
+these concurrently. NiFi Registrywill require client certificates for
authenticating users over HTTPS if none of these are configured.
+
+A secured instance of NiFi Registry cannot be accessed anonymously unless
configured to use an LDAP or Kerberos Login Identity Provider, which in turn
must be configured to explicitly allow anonymous access. Anonymous access is
not currently possible by the default FileAuthorizer (see
<<authorizer-configuration>>), but is a future effort
(https://issues.apache.org/jira/browse/NIFI-2730[NIFI-2730]).
+
+NOTE: NiFi Registry does not perform user authentication over HTTP. Using
HTTP, all users will be granted all roles.
+
+[[ldap_login_identity_provider]]
+Lightweight Directory Access Protocol (LDAP)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Below is an example and description of configuring a Login Identity
Provider that integrates with a Directory Server to authenticate users.
+
+----
+<provider>
+ <identifier>ldap-provider</identifier>
+ <class>org.apache.nifi.ldap.LdapProvider</class>
+ <property name="Authentication Strategy">START_TLS</property>
+
+ <property name="Manager DN"></property>
+ <property name="Manager Password"></property>
+
+ <property name="TLS - Keystore"></property>
+ <property name="TLS - Keystore Password"></property>
+ <property name="TLS - Keystore Type"></property>
+ <property name="TLS - Truststore"></property>
+ <property name="TLS - Truststore Password"></property>
+ <property name="TLS - Truststore Type"></property>
+ <property name="TLS - Client Auth"></property>
+ <property name="TLS - Protocol"></property>
+ <property name="TLS - Shutdown Gracefully"></property>
+
+ <property name="Referral Strategy">FOLLOW</property>
+ <property name="Connect Timeout">10 secs</property>
+ <property name="Read Timeout">10 secs</property>
+
+ <property name="Url"></property>
+ <property name="User Search Base"></property>
+ <property name="User Search Filter"></property>
+
+ <property name="Identity Strategy">USE_DN</property>
+ <property name="Authentication Expiration">12 hours</property>
+</provider>
+----
+
+With this configuration, username/password authentication can be enabled
by referencing this provider in _nifi-registry.properties_.
+
+----
+nifi.registry.security.identity.provider=ldap-provider
+----
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`Authentication Strategy` | How the connection to the LDAP server is
authenticated. Possible values are ANONYMOUS, SIMPLE, LDAPS, or START_TLS.
+|`Manager DN` | The DN of the manager that is used to bind to the LDAP
server to search for users.
+|`Manager Password` | The password of the manager that is used to bind to
the LDAP server to search for users.
+|`TLS - Keystore` | Path to the Keystore that is used when connecting to
LDAP using LDAPS or START_TLS.
+|`TLS - Keystore Password` | Password for the Keystore that is used when
connecting to LDAP using LDAPS or START_TLS.
+|`TLS - Keystore Type` | Type of the Keystore that is used when connecting
to LDAP using LDAPS or START_TLS (i.e. JKS or PKCS12).
+|`TLS - Truststore` | Path to the Truststore that is used when connecting
to LDAP using LDAPS or START_TLS.
+|`TLS - Truststore Password` | Password for the Truststore that is used
when connecting to LDAP using LDAPS or START_TLS.
+|`TLS - Truststore Type` | Type of the Truststore that is used when
connecting to LDAP using LDAPS or START_TLS (i.e. JKS or PKCS12).
+|`TLS - Client Auth` | Client authentication policy when connecting to
LDAP using LDAPS or START_TLS. Possible values are REQUIRED, WANT, NONE.
+|`TLS - Protocol` | Protocol to use when connecting to LDAP using LDAPS or
START_TLS. (i.e. TLS, TLSv1.1, TLSv1.2, etc).
+|`TLS - Shutdown Gracefully` | Specifies whether the TLS should be shut
down gracefully before the target context is closed. Defaults to false.
+|`Referral Strategy` | Strategy for handling referrals. Possible values
are FOLLOW, IGNORE, THROW.
+|`Connect Timeout` | Duration of connect timeout. (i.e. 10 secs).
+|`Read Timeout` | Duration of read timeout. (i.e. 10 secs).
+|`Url` | Space-separated list of URLs of the LDAP servers (i.e.
ldap://<hostname>:<port>).
+|`User Search Base` | Base DN for searching for users (i.e.
CN=Users,DC=example,DC=com).
+|`User Search Filter` | Filter for searching for users against the 'User
Search Base'. (i.e. sAMAccountName={0}). The user specified name is inserted
into '{0}'.
+|`Identity Strategy` | Strategy to identify users. Possible values are
USE_DN and USE_USERNAME. The default functionality if this property is missing
is USE_DN in order to retain backward
+compatibility. USE_DN will use the full DN of the user entry if possible.
USE_USERNAME will use the username the user logged in with.
+|`Authentication Expiration` | The duration of how long the user
authentication is valid for. If the user never logs out, they will be required
to log back in following this duration.
+|==================================================================================================================================================
+
+[[kerberos_login_identity_provider]]
+Kerberos
+~~~~~~~~
+
+Below is an example and description of configuring a Login Identity
Provider that integrates with a Kerberos Key Distribution Center (KDC) to
authenticate users.
+
+----
+<provider>
+ <identifier>kerberos-provider</identifier>
+ <class>org.apache.nifi.kerberos.KerberosProvider</class>
+ <property name="Default Realm">NIFI.APACHE.ORG</property>
+ <property name="Kerberos Config File">/etc/krb5.conf</property>
+ <property name="Authentication Expiration">12 hours</property>
+</provider>
+----
+
+With this configuration, username/password authentication can be enabled
by referencing this provider in _nifi-registry.properties_.
+
+----
+nifi.registry.security.user.identity.provider=kerberos-provider
+----
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`Default Realm` | Default realm to provide when user enters incomplete
user principal (i.e. NIFI.APACHE.ORG).
+|`Kerberos Config File` | Absolute path to Kerberos client configuration
file.
+|`Authentication Expiration`| The duration of how long the user
authentication is valid for. If the user never logs out, they will be required
to log back in following this duration.
+|==================================================================================================================================================
+
+See also <<kerberos_service>> to allow single sign-on access via client
Kerberos tickets.
+
+[[openid_connect]]
+OpenId Connect
+~~~~~~~~~~~~~~
+
+To enable authentication via OpenId Connect the following properties must
be configured in _nifi-registry.properties_.
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`nifi.security.user.oidc.discovery.url` | The discovery URL for the
desired OpenId Connect Provider
(http://openid.net/specs/openid-connect-discovery-1_0.html).
+|`nifi.security.user.oidc.connect.timeout` | Connect timeout when
communicating with the OpenId Connect Provider.
+|`nifi.security.user.oidc.read.timeout` | Read timeout when communicating
with the OpenId Connect Provider.
+|`nifi.security.user.oidc.client.id` | The client id for NiFi after
registration with the OpenId Connect Provider.
+|`nifi.security.user.oidc.client.secret` | The client secret for NiFi
after registration with the OpenId Connect Provider.
+|`nifi.security.user.oidc.preferred.jwsalgorithm` | The preferred
algorithm for for validating identity tokens. If this value is blank, it will
default to 'RS256' which is required to be supported
+by the OpenId Connect Provider according to the specification. If this
value is 'HS256', 'HS384', or 'HS512', NiFi will attempt to validate HMAC
protected tokens using the specified client secret.
+If this value is 'none', NiFi will attempt to validate unsecured/plain
tokens. Other values for this algorithm will attempt to parse as an RSA or EC
algorithm to be used in conjunction with the
+JSON Web Key (JWK) provided through the jwks_uri in the metadata found at
the discovery URL.
+|==================================================================================================================================================
+
+[[apache_knox]]
+Apache Knox
+~~~~~~~~~~~
+
+To enable authentication via Apache Knox the following properties must be
configured in nifi-registry.properties.
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`nifi.security.user.knox.url` | The URL for the Apache Knox log in page.
+|`nifi.security.user.knox.publicKey` | The path to the Apache Knox public
key that will be used to verify the signatures of the authentication tokens in
the HTTP Cookie.
+|`nifi.security.user.knox.cookieName` | The name of the HTTP Cookie that
Apache Knox will generate after successful log in.
+|`nifi.security.user.knox.audiences` | Optional. A comma separate listed
of allowed audiences. If set, the audience in the token must be present in
+this listing. The audience that is populated in the token can be
configured in Knox.
+|==================================================================================================================================================
+
+[[multi-tenant-authorization]]
+Multi-Tenant Authorization
--- End diff --
I think this section needs to be updated to refer to the the registry
model.
---
