Re: Data anonymization in Nifi
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
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
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
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
