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
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Mar 10, 2016, at 1:55 PM, Matt Gilman <matt.c.gil...@gmail.com> 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
> 
> [1] 
> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user-authentication
>  
> <https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user-authentication>
> 
> On Thu, Mar 10, 2016 at 4:12 PM, Uwe Geercken <uwe.geerc...@web.de 
> <mailto:uwe.geerc...@web.de>> 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
> 
> 
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to