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



Reply via email to