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
