Bryan and James,
Thanks for your advice. NiFi is wonderful technology, but it's greater
still by reason of our community, in particular, experts like you.
I will write up whatever decision we reach including our experience.
Just yesterday, I sweated through getting the Java Flight Recorder (JFR)
underneath NiFi and wiring up Java Mission Control (JMC) to perform
remote analysis--and succeeded. I'll be writing that up too.
Russ
On 12/21/2016 06:52 PM, James Wing wrote:
Russell,
I would not recommend the Legacy Authorized Users approach in 1.x. It does
work, but the authorizations model in 1.x is bigger than it was in 0.x, and
the simple conversion will not provide all that you need. I recommend
using the Initial Admin Identity, then configuring groups and users either
manually or with an API client.
That might make a good blog article...
James
On Tue, Dec 20, 2016 at 3:19 PM, Russell Bateman <r...@windofkeltia.com>
wrote:
Thanks, Bryan. I will try this again. Meanwhile, I've been studying our
0.x LDAP twists and I am starting to feel sure I can replicate them in 1.x.
Both avenues will be useful to us. (But, I really liked nifi-toolkit and
your tutorial.)
Best,
Russ
On 12/20/2016 03:41 PM, Bryan Bende wrote:
Russell,
To verify the conversion of the legacy authorized users file, I just did
the following...
1) Took a fresh build off master (1.2-SNAPSHOT)
2) Created an authorized-users.xml with the following content as a test:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<users>
<user dn="user1" group="group1">
<role name="ROLE_MONITOR"/>
</user>
<user dn="user2">
<role name="ROLE_PROVENANCE"/>
</user>
<user dn="user3">
<role name="ROLE_DFM"/>
</user>
<user dn="user4">
<role name="ROLE_ADMIN"/>
</user>
<user dn="user5">
<role name="ROLE_PROXY"/>
</user>
<user dn="user6">
<role name="ROLE_NIFI"/>
</user>
</users>
3) Configured authorizers.xml as follows:
<authorizer>
<identifier>file-provider</identifier>
<class>org.apache.nifi.authorization.FileAuthorizer</class>
<property name="Authorizations
File">./conf/authorizations.xml</property>
<property name="Users File">./conf/users.xml</property>
<property name="Initial Admin Identity"></property>
<property name="Legacy Authorized Users File">
*/path/to/authorized-users.xml*</property>
</authorizer>
4) Set the necessary TLS/SSL properties in nifi.properties
5) Started up successfully
6) users.xml got created and had this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tenants>
<groups>
<group identifier="513772ee-5301-3ad9-b4dc-374b2d34d0e9"
name="group1">
<user identifier="24c9e15e-52af-347c-a25b-757e7bee1f9d"/>
</group>
</groups>
<users>
<user identifier="24c9e15e-52af-347c-a25b-757e7bee1f9d"
identity="user1"/>
<user identifier="7e58d63b-6019-3ceb-95a1-c487989a3720"
identity="user2"/>
<user identifier="92877af7-0a45-3d6a-aed7-fe81e1236b78"
identity="user3"/>
<user identifier="3f02ebe3-d792-3b09-9e3d-8ccfde2f3bc6"
identity="user4"/>
<user identifier="0a791842-f52a-3acf-bb3a-783378c066b8"
identity="user5"/>
<user identifier="affec3b6-4cf9-3492-b77a-8114c86fc093"
identity="user6"/>
</users>
</tenants>
7) authorizations.xml got created and had a bunch of policies for theses
users, not going to paste it because it was a bit long.
Now at this point I don't have a real certificate for any of these fakes
users 1-6, but in a real migration those users would be in your LDAP or
you
would have a client certificate for one of them.
One thing to keep in mind is that the legacy migration only runs when
there
are no other users or policies defined, it is meant to be a one time
initial start up task. So if you ever get into a weird state and want to
try it again, you will need to delete users.xml and authorizations.xml
from
your conf directory to get back to a clean state.
Thanks,
Bryan
On Tue, Dec 20, 2016 at 5:10 PM, Russell Bateman <r...@windofkeltia.com>
wrote:
Bryan,
As I'm new to setting this up (why I'm tackling this at all), I initially
looked toJames Wing's tutorial <http://www.batchiq.com/nifi-c
onfiguring-ssl-auth.html>. At the end of that, I had a file,
/authorized-users.xml/, which I wanted to provide via this "legacy"
interface to NiFi 1.1.0. The Administration Guide told me how to do that
and I did it, or so I thought. In the end, NiFi would not come up
complaining about a missing /users.xml/, when I provided an empty one
(with
<users />) that this was wrong too.
I am happy it works in this new way, after following your tutorial, but
what we've really got is complicated, it uses LDAP, and we might want to
take the "legacy" solution route to soften the impact on our /rpm/ and
Ansible work by falling back on what we've already got.
Sorting out that nightmare was going to be a subsequent step after
getting
James Wing's tutorial working in NiFi 1.1.0 since it's written for NiFi
0.x, producing 0.x artifacts that I could use in 1.1.0, but without the
added LDAP complication that's present in our present, shipping 0.7.1
artifacts.
Does this make sense? I was trying to take a couple of paths in parallel
to get ready for switching from 0.x to 1.x.
Let's not waste your time. If there's value in my taking the output from
James Wing's tutorial and trying to make it work in NiFi 1.x, and
reporting
what's not working to you guys, I'll do it. Otherwise, I was just going
to
move on. Ultimately though, we will have to tackle getting our LDAP
solution rewritten for NiFi 1.x. If the legacy way of using 0.x artifacts
had worked right off, we'd probably have resorted to that. We (my
colleague, who originally injected our LDAP solution and I) will probably
at least try that way again in a few weeks before starting over from
scratch to shoehorn our LDAP stuff into NiFi 1.x.
(I've probably repeated myself here, sorry.)
Thanks for your help.
Russ
On 12/20/2016 01:32 PM, Bryan Bende wrote:
For the 0.x instance, can you elaborate on "it was not working"?
You should be able to point set "Legacy Authorized Users File" in
authorizers.xml to point to your old file, and leave the Initial Admin
blank.
On Tue, Dec 20, 2016 at 2:17 PM, Russell Bateman <r...@windofkeltia.com
wrote:
Just getting time to return to this...
Bryan
First, I was trying to follow the admin guide for converting an
existing
0.x instance. It was not working.
Second, however, I walked your tutorial successfully and created a
secure
instance of NiFi (I'm not, at this moment, interested in creating a
cluster). I'm at least as interested in doing a native 1.x instance as
converting an old 0.x instance.
Thanks,
Russ
On 12/16/2016 04:05 PM, Bryan Bende wrote:
Russell,
If you are starting with an existing 1.x installation then this post
has a
tutorial that should cover all the steps to secure the installation:
http://bryanbende.com/development/2016/08/17/apache-nifi-1-
0-0-authorization-and-multi-tenancy
The short version is you should not have to create users.xml or
authorizations.xml, NiFi will do that for you the first time it starts
secured based on your authorizers.xml.
If you are converting an existing 0.x instance there is a way to auto
convert that through a property in authorizers.xml, and it should be
explained in the admin guide as well.
Hope that helps.
-Bryan
On Fri, Dec 16, 2016 at 5:21 PM Russell Bateman <
r...@windofkeltia.com>
wrote:
I'm working on securing NiFi 1.1.0 with SSL. As I'm following a
tutorial
[1] written for 0.x, I'm attempting to use the legacy option in
/conf/authorizers.//xml/:
<authorizer>
<identifier>file-provider</identifier>
<class>org.apache.nifi.authorization.FileAuthorizer</class>
<property name="Authorizations
File">./conf/authorizations.xml</property>
<property name="Users File">./conf/users.xml</property>
<property name="Initial Admin Identity"></property>
* <property name="Legacy Authorized Users
File">./conf/authorized-users.xml</property>*
<!-- Provide the identity (typically a DN) of each node
when
clustered, see above description of Node Identity.
<property name="Node Identity 1"></property>
<property name="Node Identity 2"></property>
-->
</authorizer>
I fixed complaints of missing /users.xml/ already by supplying
/conf/users.xml/, no default for which exists:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<users/>
It would appear that this is insufficient (/logs/nifi-app.log/):
org.springframework.beans.factory.BeanCreationException: Error
creating
bean with name 'niFiWebApiSecurityConfiguration': Injection of
autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not
autowire method: public void
org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setX509A
uthenticationProvider(org.apache.nifi.web.security.x509.
X509AuthenticationProvider);
nested exception is
org.springframework.beans.factory.BeanCreationException: Error
creating
bean with name 'x509AuthenticationProvider' defined in class path
resource [nifi-web-security-context.xml]: Cannot resolve reference
to
bean 'authorizer' while setting constructor argument; nested
exception
is org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'authorizer': FactoryBean threw exception on
object creation; nested exception is
org.apache.nifi.authorization.exception.AuthorizerCreationException:
javax.xml.bind.UnmarshalException
- with linked exception:
*[org.xml.sax.SAXParseException; systemId:
file:/home/russ/dev/nifi/secure-nifi/nifi-1.1.0/./conf/users.xml;
lineNumber: 2; columnNumber: 9; cvc-elt.1: Cannot find the
declaration
of element 'users'.]*
I'm defining users by means of a 0.x /authorized-users.xml/ file, not
the /users.xml/ file. There are no examples I can find of /users.xml/
and /authorizations.xml/, empty or otherwise, to compare with
existing,
functioning NiFi 0.x installations, so I can't tell if the whole
legacy
option just doesn't work anyway or if it's just that I've got stuff
wrong still.
Grateful for comments or samples of working /users.xml/ and
/authoriz//ations.xml/.
[1] http://www.batchiq.com/nifi-configuring-ssl-auth.html
--
Sent from Gmail Mobile
