In the ActiveMQ Artemis web console we have many addresses for different users.
We would like to view only the addresses that belong to a specific user with a specific role. Is this achievable to config in management.xml?
I don't believe there is a way to restrict the addresses that a user can see in the tree structure on the left of the ActiveMQ Artemis web console. However, you can restrict whether or not a user in a specific role can see the attributes or perform management operations on specific addresses, e.g.:
<match domain="org.apache.activemq.artemis" key="address="test"">
<access method="*" roles="test"/>
</match>
This match ensures that only a user in the test role can manage the address named test.
Related
Can I create a walled garden allowing only my organisation's users/ clients to use my ejabberd instance/ service.
This includes registration of users done only by my backend and preventing other clients' users to register or access the server. Additionally users of another server can not be added by existing users.
This includes registration of users done only by my backend
Then probably limit mod_register using the options access_from and ip_access:
https://docs.ejabberd.im/admin/configuration/modules/#mod-register
And then write your custom web application that sends ReST or XMP-RPC queries to ejabberd's
https://docs.ejabberd.im/developer/ejabberd-api/#understanding-ejabberd-commands
and executes the "register" API command:
https://docs.ejabberd.im/developer/ejabberd-api/admin-api/#register
and preventing other clients' users to register
If you use your custom web to show a formulary, that's your duty.
or access the server.
Additionally users of another server can not be added by existing users.
You may want to disable S2S (server-to-server), so communication from/to your XMPP server to other XMPP servers is not allowed.
I have an authentication server using oauth2.
I use it for :
Authentication from the other services, subscription, change and retrieve password etc.
As resource server to store and retrieve more users and groups informations. I have a ManyToMany relationship between users and groups.
Should I seperate the second part of functionalities of this app on another standalone service that will work as resource server only. And only keep the authentication part on the authorization server?
That way I could horizontally scale these two services separately.
Yes, the better idea would be to have the configuration as a separate standalone service running on cloud. With configuration server as a separate service you can add all the authorization and other sort of details like DB details, API details, messaging queue configuration etc, and get connected to N number of services.
The REST API for Kafka Connect is not secured and authenticated.
Since its not authenticated, the configuration for a connector or Tasks are easily accessible by anyone. Since these configurations may contain about how to access the Source System [in case of SourceConnector] and destination system [in case of SinkConnector], Is there a standard way to restrict access to these APIs?
In Kafka 2.1.0, there is possibility to configure http basic authentication for REST interface of Kafka Connect without writing any custom code.
This became real due to implementation of REST extensions mechanism (see KIP-285).
Shortly, configuration procedure as follows:
Add extension class to worker configuration file:
rest.extension.classes = org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension
Create JAAS config file (i.e. connect_jaas.conf) for application name 'KafkaConnect':
KafkaConnect {
org.apache.kafka.connect.rest.basic.auth.extension.PropertyFileLoginModule required
file="/your/path/rest-credentials.properties";
};
Create rest-credentials.properties file in above-mentioned directory:
user=password
Finally, inform java about you JAAS config file, for example, by adding command-line property to java:
-Djava.security.auth.login.config=/your/path/connect_jaas.conf
After restarting Kafka Connect, you will be unable to use REST API without basic authentication.
Please keep in mind that used classes are rather examples than production-ready features.
Links:
Connect configuratin
BasicAuthSecurityRestExtension
JaasBasicAuthFilter
PropertyFileLoginModule
This is a known area in need of improvement in the future but for now you should use a firewall on the Kafka Connect machines and either an API Management tool (Apigee, etc) or a Reverse proxy (haproxy, nginx, etc.) to ensure that HTTPS is terminated at an endpoint that you can configure access control rules on and then have the firewall only accept connections from the secure proxy. With some products the firewall, access control, and SSL/TLS termination functions can be all done in a fewer number of products.
As of Kafka 1.1.0, you can set up SSL and SSL client authentication for the Kafka Connect REST API. See KIP-208 for the details.
Now you are able to enable certificate based authentication for client access to the REST API of Kafka Connect.
An example here https://github.com/sudar-path/kc-rest-mtls
In Domino 9.0.x server running LDAP, It seems that LDAP clients does not honors ACL roles.
I am trying to hide dismissed email addresses using reader role ($Readers field), so only specific people can see them for administration purposes.
I need that an antispam appliance querying Domino via LDAP can see those roles-hidden addresses, to correctly allowing valid recipient control checks.
In this way, relevant email messages can be received while new email addresses will be available to existent external senders.
It seems that LDAP authenticated client does not "own" any roles, and cannot see any role-hidden address, while web browsing on directory with the same authenticated account can.
Anyone use role access with LDAP?
Is there any documentation about limitations on ACL roles in LDAP access?
Is there a kind of a superuser or admin for a pubsub service who can literally do everything for example a useful pubsub nodes use-case:
Delete a collection or a leaf node which has been created by another entity
This would be implementation specific, so it would have to be set in your server (providing your server supports such a user).
For example, in Openfire you would set the property
xmpp.pubsub.sysadmin.jid