That is correct — a cluster uses N nodes to run the same flow in parallel, while disparate nodes/clusters run different flows and communicate via SiteToSite.
Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Apr 3, 2017, at 5:47 PM, mohammed shambakey <[email protected]> wrote: > > Thanks Andy, this is very helpful. > > I can't use a cluster because (as I understood from docs), each node in the > cluster does the same task but on different set of data, while in my > scenario, each node does a completely different task. > > Regards > > On Mon, Apr 3, 2017 at 7:29 PM, Andy LoPresto <[email protected] > <mailto:[email protected]>> wrote: > I am definitely missing something from your scenario. I’m going to attempt to > clarify my understanding; please correct any mistakes I make below. > > You have multiple NiFi instances deployed, and rather than deployed in a > cluster, these are multiple “sites”. A user logs into “site-1” with their > LDAP credentials. You then want the user to retype their credentials > (where?), and have the username and password encrypted, and then securely > transmitted to “site-2” (how? as the content of a flowfile which is > transmitted via SiteToSite protocol?). Then you say you do not want the user > to have to retype their credentials. So you wish to capture the user’s > credentials when they enter them to authenticate initially and store them > somewhere (a bad idea). After this information is transmitted to “site-2”, > what is done with it? When a user logs into the UI, they log in to a specific > node. A user can log into multiple nodes in a cluster with the same > credentials, but disparate nodes can be configured with completely unique and > non-overlapping authentication mechanisms. You then have a separate node > “site-2” where the same logical entity (User 1) has a different account > “user-1” that has different policies. > > As of right now, with my current understanding of your scenario, I do not > believe this is possible, or a best practice. If you need a user to > administer the flow on two different independent NiFi instances, they should > log into each independently. If typing the password into both instances is > too high a threshold for usability, I recommend using Kerberos SSO or client > certificates to allow for easier authentication. There has also been some > exploration of external authentication systems so you could put a central SSO > solution in place and proxy those authentication results to NiFi [1] [2]. > > [1] > https://lists.apache.org/thread.html/a9cdde37ec8e987309b441376796e3dfb47f3869b9252293b6d7c44e@1444095252@%3Cdev.nifi.apache.org%3E > > <https://lists.apache.org/thread.html/a9cdde37ec8e987309b441376796e3dfb47f3869b9252293b6d7c44e@1444095252@%3Cdev.nifi.apache.org%3E> > [2] > https://lists.apache.org/thread.html/bdab51a5e941cb4eb9cefa18cef8cef5396486b613ba7c71779aa028@%3Cusers.nifi.apache.org%3E > > <https://lists.apache.org/thread.html/bdab51a5e941cb4eb9cefa18cef8cef5396486b613ba7c71779aa028@%3Cusers.nifi.apache.org%3E> > > Andy LoPresto > [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> On Apr 3, 2017, at 3:57 PM, mohammed shambakey <[email protected] >> <mailto:[email protected]>> wrote: >> >> I want to submit encrypted user's credentials between sites (there is no >> central authentication for different sites). After the user logs in to >> "site-1" (using LDAP for example), "user-1" can re-type username and >> password, so they will be encrypted, then sent through secure site-to-site >> to "site-2". I don't want the user to re-type username and password. >> Besides, "user-1" should be mapped to different account on "site-2" with >> different policies. >> >> I thought if I can extract user's information from underlying authentication >> system, encrypt them, then send them through secure site-to-site will >> automate delegating user's credentials through different sites? >> Some friends suggested using decentralized authentication and authorization >> like Hydra (https://www.ory.am/products/hydra >> <https://www.ory.am/products/hydra>), but I'm still discovering it. >> >> Regards >> >> On Mon, Apr 3, 2017 at 6:27 PM, Andy LoPresto <[email protected] >> <mailto:[email protected]>> wrote: >> Mohammed, >> >> This is not possible because the flow status is independent of the logged in >> user(s). A flow can be running or stopped with 0, 1, or n many users logged >> in simultaneously. What are you trying to accomplish with this information? >> Usually when someone is requesting the current user, they are trying to >> assume an identity for filesystem access or Kerberos keytab access to a >> remote service. >> >> >> >> Andy LoPresto >> [email protected] <mailto:[email protected]> >> [email protected] <mailto:[email protected]> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >>> On Apr 3, 2017, at 3:14 PM, mohammed shambakey <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi >>> >>> Is it possible, inside a workflow, to get the current user' logged into >>> secure NIFI (the user logged into NIFI either by LDAP or certificate)? >>> >>> Regards >>> >>> -- >>> Mohammed >> >> >> >> >> -- >> Mohammed > > > > > -- > Mohammed
signature.asc
Description: Message signed with OpenPGP using GPGMail
