Many thanks Bryan. This is very helpful Regards
On Mon, Apr 3, 2017 at 1:13 PM, Bryan Bende <[email protected]> wrote: > Hi Mohammed, > > I just responded on the comments on the blog, but I'll copy it here as > well and try to answer the additional question... > > 1) The toolkit defaults to using OU=NIFI when generating the > certificates for the hosts/servers, and you are correct that I > probably should have passed in 'CN=bbende, OU=NIFI' for the client > certificate to be consistent. In reality the OU does not have any > meaning in this case, as long as all the certificates (servers + > client) are signed by the same certificate authority, which they are. > > 2) The toolkit generates a certificate authority (CA) which is stored > in nifi-cert.pem and nifi-key.key. The CA is used to sign the other > certificates for the servers and any client certificates. The > truststore then has the public key of the CA which is saying to trust > anything that was signed by this CA. > > So to add a new node, you would run the tls command again with the new > hostname, but it has to be done from the same location where you ran > it before because you want it to use the existing nifi-cert.pem and > nifi-cert.key, so that the certificate of the new node is signed by > the same CA as the other nodes. > > ./bin/tls-toolkit.sh standalone -n 'NEW_HOST_NAME' > > You won't have to update anything on the existing nodes because they > already trust the CA. > > 3) The initial admin can be an LDAP user. Most people start out with > certificates to make sure they have the initial setup working and then > add LDAP after that, but you can go with LDAP right away if you like. > > 4) Site-to-Site happens on behalf of the system, not the users of the > NiFi web UI that configured it. So in order for site1 to send data to > site2 in a secure setup, all the of the nodes from site1 need to be > represented as users in site2. That is done by creating users at site2 > with the usernames being the DNs from the certificates at site1. This > is shown in this post when creating the user for localhost. > > As far as users of the web ui... If there are different LDAPs then > these are just two different accounts and the user has one account to > login at site1 and another account to login at site2. If you want all > users to be the same across site1 and site2 then they should be > pointing at the same central LDAP. > > 5) NiFi's authorizer is a pluggable component, and NiFi provider's its > own file-based authorizer and an Apache Ranger implementation. For > cases where you don't have Apache Ranger then you would use NiFi's > default file-authorizer. Take a look at the Admin Guide section for > configuring the file-based authorizer. > https://nifi.apache.org/docs/nifi-docs/html/administration- > guide.html#multi-tenant-authorization > > Hope that helps. > > Thanks, > > Bryan > > > On Mon, Apr 3, 2017 at 12:40 PM, mohammed shambakey > <[email protected]> wrote: > > Hi > > > > I'm sorry if this is a repeated question (I posted it on this site > > "http://bryanbende.com/development/2016/08/30/apache- > nifi-1.0.0-secure-site-to-site"), > > and I added another question to it: > > > > I read this article > > "http://bryanbende.com/development/2016/08/30/apache- > nifi-1.0.0-secure-site-to-site" > > about secure NIFI site-to-site setup, and I'm sorry if the following > > questions look silly, this "security" thing is all new for me. > > > > In the part: > > > > ' In nifi-2 create a user with the DN of the certificate being used by > > nifi-1, in my case this is “CN=localhost, OU=NIFI” ' > > > > By looking at the "tls" command: > > > > ./bin/tls-toolkit.sh standalone -c ca.nifi.apache.org -C 'CN=bbende, > > OU=ApacheNiFi' -n 'localhost(2)' > > > > I can see that hostnames are specified by "localhost", but the "OU=NIFI", > > not "ApacheNiFi". Is this a typo? if not, how can I get the generated DN > for > > specified hosts? > > If I generate certificates for 2 hosts. Later, I want to add a third > host, > > should I run the "tls" command again for the 3 hosts (I assume the > generated > > truststore has the certificates for the 3 hosts)? or can I just run the > > "tls" for the third host, but how to add the certificate of the third > host > > to the other 2 hosts, and vice versa? > > The "initial-admin-identity", should it always be specified by > > "certificate", or can I setup LDAP first, and use one of the LDAP > entries as > > the "initial admin" without certificate? > > In this article, each site is considered as a user trying to access the > > workflow at the other site. If I have LDAP it "site_1", then a "user_1" > > login to "site_1" using password, then "user_1" wants to send some > request > > to "site_2" using secure site_to_site, "site_2" also has another "LDAP", > > "user_1" has another account at "site_2", and I want "site_2" to respond > to > > "user_1" request depending on "user_1" authentication and authorization, > not > > "site_1" certificate. "user_1" does not want to login to each site, > "user_1" > > wants to login to only to "site_1", then "user_1" accounts at "site_1" > and > > "site_2" should be mapped to each other (I think the account mapping in > NIFI > > docs talks only about mapping on the same site, not through different > > sites). I wonder what is the best way to implement the previous scenario? > > "site_1" can authenticate "user_1" using LDAP, but can "site_1" extract > > "user_1" credentials from "LDAP" and pass them through secure > site-to-site > > to "site_2", then "site_2" authenticates "user_1" using its own "LDAP"? > > According to Bryan's article > > "http://bryanbende.com/development/2016/08/22/apache- > nifi-1.0.0-using-the-apache-ranger-authorizer", > > authorization can be done by "Apache ranger", but as I understood, > "Apache > > ranger" works only on hadoop ecosystem. I wonder if you can suggest other > > open source central security tools like apache ranger that can work with > > NIFI site-to-site and not limited to hadoop ecosystem? > > > > > > Sorry for the many questions. > > > > Regards > > > > -- > > Mohammed > -- Mohammed
