@ushasri  NiFi does not provide a local provider for user authentication via username and password.  NiFI supports numerous authentication methods you can configure. - Authentication via a mutual TLS exchange:  Always enabled once NiFi is secured and the first method always attempted.  Mutual TLS is how NiFi nodes authenticate with one another, how Secured NiFi authenticates to other secured NiFis, how secured NiFi authenticates with secured NiFi-Registry, etc.... - Spnego: Kerberos authentication method that does not require users to provide a kerberos principal and password for authentication.   - Kerberos-provider: Requires user to provide username and password for authentication.  Successful authentication results in a bearer token issued to user and a corresponding NiFi side server token for the user. - Ldap-provider: Requires user to provide username and password for authentication.  Successful authentication results in a bearer token issued to user and a corresponding NiFi side server token for the user. - OpenID connect - SAML In a multi-node NiFi cluster, the authentication process and resulting bearer token is only valid for the node on which the authentication was verified.  Can't be used to authenticate with another node.  Issued bearer tokens have an expiration.  Default is 12 hours at which time the NiFi server removes the server side token.  This forces user to re-authenticate and obtain a new client bearer token.   Every action that a user performs via NiFi's UI must be both authenticated and authorized.  This mean that the user must authenticate via a certificate, bearer token, etc. with every request. The authenticated client user identity is then used to verify that the user/client is authorized to perform the requested operation or access the requested endpoint (such as loading the NiFi UI). Whenever a user authenticates within a NiFi instance, that NiFi instance will produce a log entry in the nifi-user.log with the authenticated user's user identity.  Subsequent to that is the requested endpoint that user is trying to access and result of that authorization. NOTE: Components added to the NiFi canvas by a user are not executed as that user. all components are executed by the NiFi service user.   Adding the username to a FlowFile attribute becomes challenging since the nothing in the NiFi canvas executes as that user.  Also running any kind of automation within the UI to make a rest-api call to NiFi would itself require user authentication and authorization. The question here is what are you trying to accomplish by extracting a username and adding it to a database? Guess you could create a dataflow that reads the nifi-user.log and extracts authentication related log lines, although, this would be very noisy since a single user who has obtained a bearer token for 12 hours may perform an unknown number of operations within the UI  or via rest-api calls each resulting in logging about authentication.   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@davehkd  Thank you for the awesome feedback.  Glad i could help you. It would be great if you could go through this back and forth exchange and accept all the responses I provided that helped you.  I noticed you accepted your own response.  🙂 Matt ... View more

@niclyx  I think you are diverging form the original query asked in this community question which has an accepted solution. When it comes to a mutual TLS exchange/handshake, this is not something NiFi created or has made any modification to.  There are many different resources on the web to learn about MutualTLS and how it works.  NiFi only cares that the TLS handshake was successful and if no other method of authentication was setup, it received a clientAuth certificate from which it will use the full DN as the identity for the authenticated user. I recommend starting a new community questions if you have new questions. Matt ... View more

@Manika  The single-user-provider used by NiFi out of the box does not support multiple users.  It simply sets up a single user to access the secured NiFi suing the out of the box NiFi setup.  Only the very first time NiFi is launched with this setup will the generated username and password be output in the nifi-app.log.  You can use the following command to change that username and password: $ ./bin/nifi.sh set-single-user-credentials <username> <password> This single user username and password has full access to everything, so NiFi does not expose "policies" as setting up additional users is not possible.   NiFi provides no other provider for local users.  NiFi historically has left user management as an external dependency.  In order tp support multiple users with and various level of authorization, you will need to switch to using a different authorizer and authentication method. Switching to another authentication method will require you establish an external means for user authentication.  NiFi has numerous supported methods (User certificate, LDAP, Kerberos, etc.) https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication Once you have selected the method you will use to authenticate your users that is not the "single-user-provider", you need to change your authorizer from "single-user-authorizer" to "standard-managed-authorizer": https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#standardmanagedauthorizer   If you found that any of the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@anony    Let me see if i understand correctly your use case. InvokeHTTP (number 1) --> InvokeHTTP (number 2) -->loops back on invokeHTTP (number 2) until subId is empty and then exits loop? So InvokeHTTP1 makes initial call to get ID (ID-Orig). ID-Orig is then used by the second InvokeHTTP2 which may or may not have a return with a subID. Use new SubID each time to make another InvokeHTTP2 execution until return no longer has a SubID. correct? After invokeHTTP2, extract that SubID to a FlowFile attribute (SubID) --> RouteOnAttribute (use to valdiate attribute SubID is not null) --> IF NOT null send FlowFile back to invokeHTTP and IF null have FlowFile exit loop. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@davehkd  The "Initial Admin Identity" is defined in the file-access-policy provider in the authorizers.xml. This provider is executed during startup of the application startup and creates an authorizations.xml file where it we set a pre-defined set of NiFi Resource Identifiers (NiFi policies) needed for NiFi administration by  the Initial Admin Identity and set NiFi Resource Identifiers needed by the NiFI nodes defined in "Node Identity <num>". The file-access-policy-provider has a dependency on a user-group-provider.  This dependency exists because NiFi Resource Identifiers (NiFi Policies) can't be set for any user/client identity strings that are not provided by one of the user-group-providers NiFi offers.  In your case, it appears you are using the file-user-group-provider, which means the nodes and initial admin must be added as "Initial user identity <num>" in that provider.  The file-user-group-provider is responsible for creating the users.xml. IMPORTANT: These providers will only generate a users.xml and authorizations.xml file if they do NOT already exist.  Expectation is that once created, additional users and setting of additional policies occurs from within the UI.  So configuration changes to these providers will have no impact on already existing users.xmll and authorizations.xml.  So if mistakes where made in configuration resulting in missing needed content in these files, they need to removed after making your config changes so new can be generated. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt   ... View more

@davehkd  That is an incomplete authorizers.xml and thus not valid.   Matt ... View more

@apmmahesh  I see one issue with your shared authorizers.xml configuration. The file loads the various providers from the top down, so it is VERY important that if a provider has a dependency on another provider that the provider it is dependent on is loaded first. So in your authorizers.xml has the following loading order: file-access-policy-provider --> file-user-grouo-provider --> managed-authorizer The problem here is that the file-access-policy provider is dependent on the file-user-group-provider which has not been loaded yet. so it will not set default policies correctly when generating the authorizations.xml file. Move the file-access-policy-provider between fie-user-group-provider (top of authorizers.xml) and managed-authorizer (bottom of authorizers.xml).   Second issue is that you have properties "Initial Admin Identity 1" and "Initial Admin Identity 2"  properties in your file-access-policy-provider.  These are not real properties. You can only specify one "Initial Admin Identity" in the file-access-policy-provider.  These unexpected property names would just be ignored. Third issue is that you need to not only specify your "Initial Admin Identity" in the file-access-policy-provider, but also need to make sure that the same user identity string is being defined in the "file-user-group-provider as another "initial User Identity <num>".  NiFi can't seed policies for a user Identity it does know about. Also keep in mind that changes to authorizers.xml file-access-policy-provider and file-access-policy-provider configuration will not result in modification of existing users.xml and authorizations.xml files.  You'll need to remove these so that new are created on startup of NiFi.   Now if you can already login with your "CN=Admin, OU=NiFi" certificate and at time of that setup the users.xml and authorizations.xml was created correctly, you can use this admin user to access "users" from global menu in NiFi and add your additional user "xyz123" and then set policies you want user xyz123 to have.   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more