Aw: Re: User Authentication with username and password

Sat, 19 Mar 2016 08:34:08 -0700

Hello everybody,
 
Iwas very busy - sorry for responding so late.
 
Thanks for all the feedback. I will probably go the LDAP way. I was looking for something quick and dirty, but I see that the architecture and implementation is not as quick as dirty and it's better that you take your time to implement it well.
 
As soon as I have half a day or so, I will try to tackle that. I like Nifi very much and see great potential for the company I work for. From a company perspective of course I will have to have some security in place before I can go into production with the tool.
 
I will of course let you know of my findings once I am at it.
 
Rgds,
 
Uwe
 
Gesendet: Freitag, 11. März 2016 um 08:43 Uhr
Von: "Conrad Crampton" <[email protected]>
An: "[email protected]" <[email protected]>
Betreff: Re: User Authentication with username and password
Hi,
In case you missed this in an earlier thread, Matt Clarke [1] provided some very easy steps to create certificates for cluster SSL to work. I’m sure it would be easy to extend to create individual user certs. I’m sure this would be a pain for many users in which case I would recommend the LDAP way (again, very easy to set up following the docs).
Regards
Conrad
 
 
 
From: Aldrin Piri <[email protected]>
Reply-To: "[email protected]" <[email protected]>
Date: Friday, 11 March 2016 at 04:14
To: "[email protected]" <[email protected]>
Subject: Re: User Authentication with username and password
 
Uwe,
 
Definitely been a frequently requested item by the community and as Andy pointed out, it is quite nuanced in getting just right in a way that manages to get as close to that delicate balance between usability and security short of the computer encased in concrete on the bottom of the ocean floor.
 
I think James has a good start in providing a basis of implementation for extending and drawing from the expertise of the entirety of the community we should be able to find an implementation that checks all the right boxes.  The parts are there in some forms looking at the work that was performed to integrate LDAP and Active Directory.  While the user facing portions have very similar constructs, the heart of the security model delegates to other systems.
 
For Uwe, and anyone that has any interest, I would suggest also checking out both the JIRA issue NIFI-1614 [1] and the associated PR [2] and provide some input on how such an implementation might look.  Please leave comments, uses, and functionality that would make sense to incorporate.  With some iterations and design we can find out how such a mechanism would work in both satisfying the design approach and principles for NiFi authentication and authorization, but doing so in a manner that treats system data and control with the utmost importance.
 
If appropriate, perhaps we could spin out a Wiki entry/feature proposal/design that folks could hash out all the constraints.  Such a model will require a fair bit of effort and consideration as NiFi has generally avoided doing too much outside the purview of dataflow and relied on already established and proven technologies.
 
Thanks for chiming in, Uwe and thanks, James, for the serendipitous PR, or extremely fast coding to meet Uwe's inquiry!
 
 
On Thu, Mar 10, 2016 at 9:40 PM, Andy LoPresto <[email protected]> wrote:
I think it is important to ensure everyone is using the same definitions here. As Matt pointed out, NiFi has capabilities for authentication (that is, determining an entity is WHO they claim to be) and authorization (determining if an entity can DO what they claim). The *AuthorizationProviders allow an authenticated user’s access to varying permissions to be determined. However, there is no current model for file-based or “simple” authentication in NiFi. As Matt stated, client authentication through certificates will allow user authentication based on the DN in the certificate, and LDAP authentication is also currently available. I am working on Kerberos authentication for 0.6.0 as well. 
 
James has provided a PR for file-based authentication but in reviewing it I found a couple issues, which are not unique to his code, that prevent me from feeling comfortable with it as a safe and production-ready solution. User credential administration is a large effort and providing a temporary solution will unfortunately often be conscripted into a production environment and weaken the overall system security of the installation. 
 
Unfortunately “simple” authentication really isn’t. 
 
 
Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
 
On Mar 10, 2016, at 1:55 PM, Matt Gilman <[email protected]> wrote:
 
When NiFi is running over HTTP everyone accesses the application as an anonymous user and has full access.
 
If you want to have individual user accounts, you'll need to first run NiFi over HTTPS. In order to do this, you'll need to obtain a server certificate for NiFi to use. These details are configured in nifi.security.* sections of the properties file. You can choose any port you'd like but typically you'll see 443 or 8443. 
 
Once this is set up, you'll have two choices for authentication.
 
The first is to issue client certificates for your users. These certificates will be loaded into your browser and will allow you to access NiFi as yourself without needing to log in with a username and password.
 
The second option is to log in with username and password where those credentials are stored in a Directory Server [1]. Currently, that is the only support username/password store. However, that is a public extension point and additional options can be added.
 
The authority-providers.xml handles authorization of authenticated users. So the DN that will appear in that file will either come from your client certificate or your LDAP entry.
 
Matt
 
 
On Thu, Mar 10, 2016 at 4:12 PM, Uwe Geercken <[email protected]> wrote:
Hello I would like to setup a simple username/password authentication. A user has to specify the userid and a password to use the nifi web ui - that's all.
 
While there is a lot of information in the documentation, I am confused of what is required and what not.
 
in the file authority-providers.xml this is configured by default - I did not change anything.
<provider>
        <identifier>file-provider</identifier>
           <class>org.apache.nifi.authorization.FileAuthorizationProvider</class>
           <property name="Authorized Users File">./conf/authorized-users.xml</property>
        <property name="Default User Roles"></property>
</provider>
 
I think I have to configure this here in nifi.properties:
 
nifi.web.https.host=localhost
nifi.web.https.port=???
 
host would be localhost but what should I configure for the port? any port?
 
The file login-identity-providers has definitions for ldap-provider only, but his is not my case.
 
I have added following entry to authorized-users.xml
 
   <user dn="cn=Uwe Geercken,ou=people,dc=example,dc=com">
        <role name="ROLE_ADMIN"/>
    </user>
 
This would be my name, but I don't know if this is the correct format (taken from the documentation)
 
Any help would be appreciated to get me going.
 
Regards,
 
Uwe
 
 
 
 

***This email originated outside SecureData***

Click here to report this email as spam.

 
SecureData, combating cyber threats
 

The information contained in this message or any of its attachments may be privileged and confidential and intended for the exclusive use of the intended recipient. If you are not the intended recipient any disclosure, reproduction, distribution or other dissemination or use of this communications is strictly prohibited. The views expressed in this email are those of the individual and not necessarily of SecureData Europe Ltd. Any prices quoted are only valid if followed up by a formal written quote.

SecureData Europe Limited. Registered in England & Wales 04365896. Registered Address: SecureData House, Hermitage Court, Hermitage Lane, Maidstone, Kent, ME16 9NT

Reply via email to