anchor.diff:  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
   ----------------------
  -NOTE: This section is incomplete.
  +
  +NiFi provides several different configuration options for security purposes. The most important properties are those under the
  +"security properties" heading in the _nifi.properties_ file. In order to run securely, the following properties must be set:
  +
  +[options="header,footer"]
  +|==================================================================================================================================================
  +| Property Name | Description
  +|`nifi.security.keystore` | Filename of the Keystore that contains the server's private key.
  +|`nifi.security.keystoreType` | The type of Keystore. Must be either `PKCS12` or `JKS`.
  +|`nifi.security.keystorePasswd` | The password for the Keystore.
  +|`nifi.security.keyPasswd` | The password for the certificate in the Keystore. If not set, the value of `nifi.security.keystorePasswd` will be used.
  +|`nifi.security.truststore` | Filename of the Truststore that will be used to authorize those connecting to NiFi. If not set, all who 
  +                            attempt to connect will be provided access as the 'Anonymous' user.
  +|`nifi.security.truststoreType` | The type of the Truststore. Must be either `PKCS12` or `JKS`.
  +|`nifi.security.truststorePasswd` | The password for the Truststore.
  +|`nifi.security.needClientAuth` | Specifies whether or not connecting clients must authenticate themselves. If the Truststore properties are not set, 
  +                                this must be `false`. Otherwise, a value of `true` indicates that users will be authenticated and must have 
  +                                certificates that are trusted by the Truststore loaded into their web browsers. A value of `false` indicates
  +                                that all users should be given access as the 'Anonymous' user.  
  +|==================================================================================================================================================
  +
  +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. This allows admins to configure the application to run only on specific network interfaces. If it is desired that the HTTPS interface
  +be accessible from all network interfaces, a value of `0.0.0.0` should be used.
  +
  +It is important when enabling HTTPS that the `nifi.web.http.port` property be unset. If both properties are configured, users will be able to
  +connect over either HTTPS or HTTP. This can be useful in order to connect over HTTP when accessing the system over a local network and require
  +HTTPS for all other network interfaces. However, it is usually desirable to secure all network interfaces, so this property is most often unset.
  +
  +Now that the User Interface has been secured, we can easily secure Site-to-Site connections and inner-cluster communications, as well. This is
  +accomplished by setting the `nifi.remote.input.secure` and `nifi.cluster.protocol.is.secure` properties, respectively, to `true`.
   
   
   Controlling Levels of Access
   ----------------------------
   
   Once NiFi is configured to run securely as discussed in the previous section, it is necessary
  -to manually designate an ADMIN user in the _authorized-users.xml_ file, which is located in the
  -root installation's conf directory. After this ADMIN user has been added, s/he may grant access
  +to configure who will have access to the system and what types of access those people will have.
  +NiFi controls this through the user of an 'Authority Provider.' The Authority Provider is a pluggable
  +mechanism for providing authorizations to different users. Which Authority Provider to use is configured
  +using two properties in the _nifi.properties_ file. 
  +
  +The `nifi.authority.provider.configuration.file` property specifies the configuration file for Authority Providers. 
  +The `nifi.security.user.authority.provider` property indicates which of the configured Authority Providers should be
  +used.
  +
  +By default, the `file-provider` Authority Provider is selected and is configured to use the permissions granted in 
  +the _authorized-users.xml_ file. This is typically sufficient for instances of NiFi that are run in "standalone" mode.
  +If the NiFi instance is configured to run in a cluster, the node will typically use the `cluster-node-provider`
  +Provider and the Cluster Manager will typically use the `cluster-ncm-provider` Provider. Both of these Providers
  +have a default configuration in the _authority-providers.xml_ file but are commented out.
  +
  +When using the `cluster-node-provider` Provider, all of the authorization is provided by the Cluster Manager. In this
  +way, the configuration only has to be maintained in one place and will be consistent across the entire cluster.
  + 
  +When configuring the Cluster Manager or a standalone node, it is necessary to manually designate an ADMIN user 
  +in the _authorized-users.xml_ file, which is located in the root installation's conf directory.
  +After this ADMIN user has been added, s/he may grant access
   to other users, systems, and other instances of NiFi, through the User Interface (UI) without having to manually edit the _authorized-users.xml_
   file. If you are the administrator, you would add yourself as the ADMIN user in this file.
   
   Open the _authorized-users.xml_ file in a text editor. You will notice that it includes a template
   to guide you, with example entries that are commented out.
   
  -It is only necessary to manually add one user, the ADMIN user,
  -to this file.
  -So, at a minimum, the following example entry should be included and contain the user Distinguished Name (dn)
  +It is only necessary to manually add one user, the ADMIN user, to this file.
  +So, at a minimum, the following example entry should be included and contain the user Distinguished Name (DN)
   in place of "user dn - read only and admin":
   
   ----
  
positive.code: 
  After the _authorized-users.xml_ file has been edited and saved, restart NiFi.
  Once the application starts, the ADMIN user is
  able to access the UI at the https URL that is configured in the _nifi.properties_ file.
  
  From the UI, click on the Users icon ( image:iconUsers.png["Users", width=32] ) in the
  Management Toolbar (upper-right corner of the UI), and the User Management Page opens.
  
negative.code: The ADMIN user should be listed. Click on the pencil icon to see this user's role(s). You may edit the
  roles by selecting the appropriate checkboxes.
  
  The following roles are available in NiFi:
  
  [options="header,footer"]
  |========================================================================================================
  | Role Name | Description
  | Administrator | Administrator is able to configure thread pool sizes and user accounts
  | Data Flow Manager | Data Flow Manager is given the ability to manipulate the dataflow. S/he is able to
                        add, remove, and manipulate components on the graph; add, remove, and manipulate
                        Controller Services and Reporting Tasks; create and manage templates;
                        view statistics; and view the bulletin board.
  | Read Only | Users with Read Only access are able to view the dataflow but are unable to change anything.
  | Provenance | Users with Provenance access are able to query the Data Provenance repository and view
                 the lineage of data. Additionally, this role provides the ability to view or download
                 the content of a FlowFile from a Provenance event (assuming that the content is still
                 available in the Content Repository and that the Authority Provider also grants access).
                 This access is not provided to users with Read Only 
                 (unless the user has both Read Only and Provenance roles) because the information provided 
                 to users with this role can potentially be very sensitive in nature, as all FlowFile attributes 
                 and data are exposed. In order to Replay a Provenance event, a user is required to have both
                 the Provenance role as well as the Data Flow Manager role.
  | NiFi | The NiFi Role is intended to be assigned to machines that will interact with an instance of NiFi
           via Site-to-Site. This role provides the ability to send data to or retrieve data from Root
           Group Ports (but only those that they are given permissions to interact with - see the User Guide
           for more information on providing access to specific Ports) as well as obtain information about
           which Ports exist. Note that this role allows the client to know only about the Ports that it
           has permissions to interact with.
  | Proxy | The Proxy Role is assigned to a system in order to grant that system permission to make requests
            on behalf of a user. For instance, if an HTTP proxy service is used to gain access to the system,
            the certificate being used by that service can be given the Proxy Role.
  |========================================================================================================
  
  
  When users want access to the NiFi UI, they navigate to the configured URL and are
  prompted to request access. When someone has requested access, the ADMIN user sees a star
  on the Users icon in the Management Toolbar, alerting the ADMIN to the fact that a request is
  pending. Upon opening the User Management Page, the pending request is visible, and the ADMIN
  