We are running RabbitMQ 3.6.5 in a Windows environment and are using the LDAP plugin. This allows our developers to view the queues and inspect the messages. By default, the RabbitMQ LDAP plugin allows "all users to access all objects in all vhosts" (as documented here). This includes the ability to publish messages directly from the LDAP plugin. What we would like to do is deny this permission to LDAP users, while still allowing them to see the queues.
According to the LDAP plugin page, this is accomplished by inserting Erlang queries into the RabbitMQ configuration. Using the examples on that page, we first tried simply granting read permission with this query (LDAP specifics changed):
{resource_access_query,
{for, [{permission, configure, {in_group, "OU=someGroup,OU=Departments,OU=ABC,DC=ABC,DC=ORG"}},
{permission, read, {constant, true}}
]
}}
When that had no effect, we tried explicitly denying write permissions:
{resource_access_query,
{for, [{resource, queue, {for, [{permission, configure,
{in_group, "OU=someGroup,OU=Departments,OU=ABC,DC=ABC,DC=ORG"}
},
{permission, write, {constant, false}},
{permission, read, {constant, true}}
]}},
]}}
Unfortunately that had no effect either. In both cases, LDAP users were still able to publish messages in the LDAP plugin.
Does anybody know what we are missing?
The RabbitMQ team monitors this mailing list and only sometimes answers questions on StackOverflow.
You need to read the RabbitMQ Access Control guide as well, specifically this section. Messages are published to Exchanges in RabbitMQ, not Queues, via the basic.publish AMQP 0.9.1 method. In your case deny write permission to the exchange resource and grant read permission to the queue resource.
Once you have configured the LDAP plugin correctly, I strongly recommend enabling the auth cache plugin. Otherwise, LDAP queries will be made when every message is published or read, as well as all other operations requiring authorization.
Related
Considering MQTT's pub/sub behavior, topic namespace is not isolated and any user can access every other user's data on a topic.
I've seen services like flespi which claim they provide isolated name spaces but some of them use containers to isolate users...
Is it possible to modify an MQTT broker, e.g. Mosquitto, for that purpose? Or is there such open source broker?
Mosquitto can set access control to topics based on authentication username. This allows the administrator to restrict access to topics and restrict which clients can subscribe, publish or receive messages on particular topics. This is documented in Mosquitto’s documentation.
For greater flexibility you can also use the dynamic security plugin, or the mosquitto-go-auth plugin which allows you to use a variety of different data sources for authorization and ACL configuration.
I've got Artifactory set up to allow SSO via an OIDC client in Keycloak. Keycloak talks to Active Directory in the background. I've also got the same Active Directory configured within Artifactory. I've also configured Keycloak to provide user groups in the userinfo structure.
What I'm trying to do is to get OAuth users to automatically be added to the imported LDAP groups within Artifactory. I don't mind if this is done via the userinfo structure or via a separate LDAP lookup when a user logs in. However I can't seem to figure out how to achieve this.
I know that Artifactory provides a plugin called synchronizeLdapGroups.groovy, which seems to advertise doing what I need, however it seems like the plugin is not actually taking effect. That is to say, users do not end up with the permissions that being in the LDAP groups would provide.
I've attempted to write a plugin myself to do what I need, but when I make the API call to add the groups to the user, the plugin crashes. It's unclear why at this point.
It seems like others have used the SCIM feature in Artifactory for something akin to this (mostly via SAML rather than OIDC though), however Keycloak doesn't support SCIM out of the box and the SCIM plugin I've tried using has similarly given me no results.
Has anyone done something similar to this, and has a working solution I could follow?
If it's a specific group you want all users to be in you could try:
Under Security - OAuth SSO settings tab - check "Auto Create Users"
Under Identity and Access - Groups - select the specific group and check "Automatically Join New Users To The Group"
I'm guessing you want to automatically sync user-group association between Keycloak and Artifactory. SCIM is what you're looking for but there's a known issue specifically with Keycloak SCIM plugin.
We're looking into the SCIM plugin for Keycloak (can't commit on a specific timeline for a fix but it should be sometime this quarter).
If you only need the association in the UI you could try SAML with "Auto associate groups" set. It won't apply the groups association for APIKey/Token calls but it would work for the UI.
EDIT:
after further investigation github.com/Captain-P-Goldfish/scim-for-keycloak isn't relevant here - it makes keycloak a SCIM client, not a SCIM server. There's no official support of SCIM in keycloak, see issues.redhat.com/browse/KEYCLOAK-2537 . and there's no working plugin for keycloak that makes it a SCIM server that I could find (tried a few, all broken). For now Artifactory can't support SCIM with Keycloak
SCDF Server for Cloudfoundry: 1.2.4.RELEASE
Configuring the security properties for LDAP authentication, and I have the authentication part working, but authorization is proving a little strange.
SCDF's security implementation appears to be looking for some roles like this:
ROLE_CREATE, ROLE_MANAGE, ROLE_VIEW.
But for me, the standard group names require some specific naming convention in AD similar to the following: app_myapplication_authz_CREATE, app_myapplication_authz_MANAGE, and app_myapplication_authz_VIEW
When I debug through the SCDF authentication output, I can see that my authenticated principal's group memberships are being retrieved correctly. They show up in the DEBUG output as: ROLE_APP_MYAPPLICATION_AUTHZ_CREATE, ROLE_APP_MYAPPLICATION_AUTHZ_MANAGE, ROLE_APP_MYAPPLICATION_AUTHZ_VIEW
Now, I include a YML security configuration that looks like this:
spring:
cloud:
dataflow:
security:
authorization:
enabled: true
rules:
- GET /metrics/streams => hasRole('ROLE_APP_MYAPPLICATION_AUTHZ_VIEW')
- POST /apps/** => hasRole('ROLE_APP_MYAPPLICATION_AUTHZ_CREATE')
- etc, etc, etc
And so on, for all the endpoint authorizations.
However, I'm still receiving a message after successful authentication that I don't have the appropriate roles and I need to talk to my administrator.
What am I misconfiguring, or what am I missing in this setup?
Update
I downloaded the source code for the 1.2.1.RELEASE version of the spring cloud dataflow ui from here: GitHub spring-cloud-dataflow-ui
And discovered that in all the .html view files, the role names are hard-coded for ROLE_VIEW, ROLE_CREATE, ROLE_MANAGE. Thus, it looks like my configuration will allow me to customize the authorization on the REST endpoints based on my LDAP group names, but I will not be able to do the same with the actual UI views. I think I have one option here, which would be to build/generate my own custom version of the UI, and bundle that with the spring-cloud-dataflow-server JAR instead of using the OOTB ui.
I'll have to weigh whether I really want to do that.
We don't yet have the direct mapping of LDAP AD Groups <-> SCDF Roles. We haven't had anyone from the community or customers' ask for this integration, though. UAA backed OAuth turns out to be the popular choice in PCF so far.
That said, I created spring-cloud/spring-cloud-dataflow#2084 to track the support for group mapping. It could be trivial to implement it (Group vs. ROLE mapping in YAML and parsing logic in the backend code); I marked it for 1.5, but we may pick it up sooner for the 1.4 release next week.
I'd recommend not venturing into adjusting the UI code directly, though. Too much on the local fork and you'll have to maintain it.
I am learning Jenkins and i am using version 1.605. I am learning about setting security options in jenkins. I found below options in jenkins configure global security page under the security realms:-
Delegate to servlet container
Jenkins'own user database
LDAP
I want to understand in which scenario, which option should be used?Please help me understand.
The "servlet container" refers to the web server that you are using to host Jenkins, typically Tomcat. The configuration file $CATALINA_BASE/conf/tomcat-users.xml may already be set up and managed by your organization. In this case: "why reinvent the wheel?". Use this if your organization already has a process that manages the Tomcat users configuration. This is also probably the most archaic solution.
The "own user database" is just what it sound like. Instead of relying on something else, Jenkins keeps it's own database of users. You can create and delete users through the Jenkins UI. You can even let new users sign up right from UI. If you don't know what to use, use this one. It's simple and self-contained.
The "LDAP" provides integration with LDAP/ Windows Active Directory. If you are in a corporate/small business environment that already utilizes LDAP for maintaining users and groups, it will be very beneficial to hook into that and off-load user management to the IT team that manages LDAP/AD. Note that unless you are that IT admin, you will need to contact the said admins for connection information/credentials to the LDAP/AD
Slav did a very clear answer.
If you choose the option 2 or 3, you can use the Role Stragegy plugin to create application roles and assign roles to Jenkins users, LDAP users or LDAP static/virtual groups.
If you have a lot of users, this plugin can save your life to assign permissions :)
I have ejabberd set up using external_auth to authenticate against the user database of my web application. What I would like is to be able to create a MUC (chat room) for site moderators, and automatically add those users to the chat, to the exclusion of all other users.
Eventually I would also like to be able to map my site's groups functionality to MUC's in ejabberd also.
The external authentication API for ejabberd doesn't seem to provide for fine-grained access control, basically only allowing you to query whether a user is registered and whether a username / password combination successfully authenticates a user.
The only reference I've seen to acl's for MUC's is here:
http://www.ejabberd.im/aclpopulate
But that seems to require setting privileges through the webadmin interface.
Is there no way to do this automatically from external auth?
To answer my own question, it doesn't seem possible to do what I need by using external auth.
I ended up integrating ejabberd commands into the user / group lifecycle of my web app, which was quicker than I had anticipated, and has the added bonus of being a zillion times faster than using external auth (I use ejabberd's internal user database, using ejabberdctl to create users, update passwords, add and remove from shared rosters and create muc's).
To help with that process I created a PHP wrapper for ejabberdctl which is freely available on github:
https://github.com/tomlancaster/Ejabberd-Wrapper-PHP
Please feel free to use and abuse it as you wish.
If you have your own authentication module, in that case you can redirect the authentication process of ejabberd. In ejabberd_auth.erl file redirect authentication by modifying check_password_with_authmodule/3 and check_password_with_authmodule/5 two function. From your authentication module return back the term as these two functions return.
If you authentication module is in deferent machine, make a socket connection to communicate with your authentication module and get the result and give the result back to check_password_with_authmodul function.
After this changes rebuild ejabberd and start.