Re: Data anonymization in Nifi

[Vyshali]

Hi Chris,

Thanks for the suggestion.Should I have code in python or some languagues
for hashing the data using exectescript processor ? If so,will the format of
the data be detained after hashing.
Please provide some clarity on that.

Thanks,
Vyshali



--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/

ConsumeJMS with ActiveMQ over SSL in NiFi 1.4.0

[Brian Ghigiarelli]

I'm having a bit of trouble getting an ActiveMQ v5.14 JMS consumer up and
running over SSL with the new-ish ConsumeJMS processor, and was wondering
if anyone has any pointers on where to start.

ConsumeJMS using a JMSConnectionFactoryProvider configured with a
StandardSSLContextService and the MQ ConnectionFactory Implementation of
"org.apache.activemq.ActiveMQSslConnectionFactory" throws the typical
SSLHandshakeException ("unable to find valid certification path to
requested target") whenever I try to start the consume processor.

However, I'm using that the same StandardSSLContextService for GetJMSTopic
(as well as in other processors) and everything's working fine. I'd like to
switch to ConsumeJMS for its shared resources and expression language
support for the Broker URI, though.

Any ideas on where to start troubleshooting? Has anyone else solved this?

Thanks in advance,
Brian

Re: Multiple users or group as initial admin identity

[Kevin Doran]

Hi Fredrik and Bryan,

I agree these changes would be fairly straightforward to make and could 
simplify deployment in some environments.

I'll also add that while we look into this, in the meantime a workaround would 
be to continue to use the use the Initial Admin user, and have an automated 
step in your deployment/configuration that uses that admin to script 
interaction with the REST API [1] to add the desired LDAP  group to the admin 
access policies using the /tenants and /policies endpoints. I.E.:

GET /tenants/users   # call this and determine the identifier for the admin 
identity
GET /tenants/users/{adminIdentifier}   # access policies is a list at 
component.accessPolicies in the resulting json

for each policy:
# add the user group identifier to the policy's userGroups list
PUT /policies/{id}  # write the updated policy back to the server

That would save the step of having to do this in the UI. I agree it would 
simplify things and save this unnecessary scripting to add something like 
Initial Group Admin Identity to the configuration XML.

[1] https://nifi.apache.org/docs/nifi-docs/rest-api/index.html 

Cheers,
Kevin

On 10/20/17, 09:28, "Bryan Bende"  wrote:

Hi Fredrik,

These are some good ideas.

If we did support multiple initial admins, I would suggest it be done
through multiple elements, rather than a comma separate list since
commas are part of a DN which could be a single user.

We already support this patter in the new user group provider:





Down in the policy provider we currently only support a single
property called "Initial Admin", but that could possibly be:





I would think groups could be done similarly by providing a group to
the user group provider and then declaring that group to be an admin,
possibly:



and



-Bryan


On Thu, Oct 19, 2017 at 10:56 AM, Fredrik Skolmli  
wrote:
> Hi all.
>
> With the ability to populate NiFi with users and groups from LDAP (as of
> 1.4.0(?)), I'm running into a few tasks that could be avoided or improved.
>
> I would like to specify a group as the initial admin identity instead of a
> single user, enabling the group members to log in and do the initial setup
> of new NiFi instances.
>
> Another option, as a quickfix, would be to allow the initial admin 
identity
> property to be a comma separated value (i.e. "admin1,admin2").
>
> The latter would be a rather small patch to implement, but I would some
> appreciate feedback from the community on what the best and most reliable
> approach would be. Or if both would be considered.
>
> ..or are there any other ideas on the roadmap to solve this that I haven't
> found in JIRA or thought of myself?
>
> Thanks.
>
> BR,
> Fredrik

Re: Multiple users or group as initial admin identity

[Bryan Bende]

Hi Fredrik,

These are some good ideas.

If we did support multiple initial admins, I would suggest it be done
through multiple elements, rather than a comma separate list since
commas are part of a DN which could be a single user.

We already support this patter in the new user group provider:





Down in the policy provider we currently only support a single
property called "Initial Admin", but that could possibly be:





I would think groups could be done similarly by providing a group to
the user group provider and then declaring that group to be an admin,
possibly:



and



-Bryan


On Thu, Oct 19, 2017 at 10:56 AM, Fredrik Skolmli  wrote:
> Hi all.
>
> With the ability to populate NiFi with users and groups from LDAP (as of
> 1.4.0(?)), I'm running into a few tasks that could be avoided or improved.
>
> I would like to specify a group as the initial admin identity instead of a
> single user, enabling the group members to log in and do the initial setup
> of new NiFi instances.
>
> Another option, as a quickfix, would be to allow the initial admin identity
> property to be a comma separated value (i.e. "admin1,admin2").
>
> The latter would be a rather small patch to implement, but I would some
> appreciate feedback from the community on what the best and most reliable
> approach would be. Or if both would be considered.
>
> ..or are there any other ideas on the roadmap to solve this that I haven't
> found in JIRA or thought of myself?
>
> Thanks.
>
> BR,
> Fredrik