I'm trying to configure ACL for my Mosquitto Broker (1.4.15) installed on Ubuntu (18.04.5) in such way that:
Every user get to subscribe and publish to any topic under his user name
With the exception of admin user, I want him to be able to read and write any topic.
when I type the following in ACL file:
pattern readwrite %u/#
Every user is able to connect and readwrite to topics under his name (user/home/kitchen)
However if I add this to ACL file:
pattern readwrite %u/#
user admin
topic #
No one other than admin user can even connect to the broker. Also the admin is given his intended rule to readwrite any topic.
I think the idea can be possible if I code every user separately but given potential huge number of users this is not practical. Any suggestion to how use pattern and user together?
Related
I all, I'm writing a boilerplate for future projects. Composition is as follows:
Server:
Express,
Prisma 2,
Typescript,
JWT Auth (Access token in memory, Refresh in cookie)
MySQL
I'm writing an RBAC schema, and have successfully written express middlewares to determine if a user is logged in, and for if a user has a specific permission on their role.
If you've ever used any of the minecraft server permission plugins, I'm trying to emulate the common pattern used there.
Users have role(s)
Roles have permissions
Roles can inherit permissions from one or more roles
Roles have a "nextRole" field to determine what role to give when the "promote" event is triggered.
Everything works fine on the server side.
What I'm wondering about is, how should I go about copying the middlewares (login, permissions) to the client side, and how should I determine whether a user has permission to do something?
What I've looked at:
Creating a "hasPermission" endpoint wouldn't be very good as I'd need to make an API call every time a permission check is needed.
Eager loading all roles and permissions from the api when logging in and returning them in the response (I can't eager load the recursive role inheritance/nextRole as far as I know)
Returning ONLY the user without roles and permissions for the JWT/login bit and getting roles/permissions from their own endpoints (again, needs to be recursive to get all inheritance and said permissions from inheritance)
Has anyone created an RBAC schema like this, and how did you go about checking permissions on the client side without being too redundant/using too much memory/too many api calls?
This is a good question, here's my answer to it.
An app is normally protected by the auth info, which means it could be blocked if a user is not permitted. If this is a server application, it can be easily done, because the session can be used to find out the current user info including roles.
However if this is a client app, it's a bit tricky. Say we can protect a route (page or section of page) once the user log in.
if (!user.authenticated) return null
We can use the above line to block private or public user. Or other information you can grab from the user to protect more.
if (user.role !== 'Admin') return null
We could wrap in these into a component, such as
<Allow role="admin" render={...} />
I believe you get the point. However there's something which is very unique about the client approach. The entire user info is returned back, and only the user info, not the user type or permission type.
So to follow your plan, do we need to share a permission or role type to the client side? This is a million dollar question.
In practice, the UI never needs the complete info, why? because UI normally reshapes the permission a bit. That doesn't mean you can't share the complete info from the backend. Doing that may make the UI job easy or more complicated. Nobody knows.
The reason is what I explained above, the UI is writing a if statement (could be hidden) anyway. Either this if is true or false, most of the front-end code is already loaded. It's very different than the backend version, which can entirely block the deliver of the content.
I've written a security module for my MVC intranet that allows administrators to grant permissions to users for certain functions like viewing, editing, deleting etc. When an intranet user visits a page, the underlying security module checks the SQL database to see if an administrator has given them access to perform the task and, if they have the required permission, they can click a link or whatever.
What baffles me is that the above system doesn't work unless I republish the website after the administrator has granted the permission. The permission is stored correctly in a permissions table in the database but when the user tries to use the permission it doesn't work. As far as I can tell my security module is completely standalone and is just a case of reading and writing to a database using static methods like this:
if (SecurityManager.HasRole(Request.ServerVariables["AUTH_USER"], "edit")) { }
I'm sure this is just a basic flaw in my understanding but does anyone have any ideas how I can get this to work?
I need to give users access to edit specific Azure Logic App workflows. I find I can support this with the Logic App Contributor role. At times, I have workflows that contain an XML Validation action. I do want users to be able to edit business rules before and after that action, and even configure the action such as selecting a different XSD. However, I do not want them to be able to configure the Integration account that supports the XML Validation action, or even have a read-only view to the Integration account. When I have such an action, a would-be editor is blocked with the error:
it does not have permission to perform action 'Microsoft.Logic/integrationAccounts/join/action' on the linked scope(s)
Is there a way to apply roles so that a user can edit such a workflow with no direct access to the Integration Account?
You should be able to configure a custom role that matches your scenario.
Essentially you would grant the user the following permissions
Microsoft.Logic/workflows/*
Microsoft.Logic/integrationAccounts/join/action
The Microsoft.Logic/integrationAccounts/join/action perimssion allows the user to modify a logic app linked with an integration account, but does not grant any permissions on the integration account itself (the user would need Microsoft.Logic/integrationAccounts/* for that)
You can restrict the Microsoft.Logic/workflows/* permission further (e.g. by scoping it down to write action only).
As mentioned by #SzymonWylezol, MS made a change on its end and the error no longer occurs. In the case where the IA in a separate Resource Group than the Workflow, I find the user must be given the join action permission on the IA, in that Resource Group.
I recently set up CouchDB on my server, but I'm running into a lack of information regarding changing permissions. I have an admin account, so it's not an admin party, but the restrictions are still looser than I'd like.
I'd like the Futon interface (which I've exposed) to be read-only for unauthenticated users. If I understand correctly, as it is, any visitor to the exposed Futon interface can become a member, who is
allowed to read all documents and create and modify any document except for design documents.
I'd like to take these abilities away, and configure CouchDB so that unauthenticated users can neither create documents nor become users. Basically, I want CouchDB to be read-only for everyone besides me.
Looking at the docs about security, there are ways to restrict access to the database of any kind to registered members, but I'd like to keep letting unauthenticated users have read-only access. According to this page,
If there are any member names or roles defined for a database, then only authenticated users having a matching name or role are allowed to read documents from the database (or do a GET /{db} call).
so that would restrict read access as well.
Are there any ways to fine-tune the permissions settings on CouchDB?
To simply solve your problems, assign your admin a role (eg: "ADMIN").
Then, foreach databases, restrict the "Admin" permissions to the role "ADMIN".
By default, a newly registered user won't have any role so he won't be able to access a database as an admin.
I ended up using nginx configuration to block all non-GET requests. This allows anyone to read the database, but prevents writing to the database.
However:
I can't safely expose futon now
As an admin, I can't edit the database
but to solve these
I could potentially write a new interface for CouchDB that only exposed read functionality
I can do my administration through SSH port forwarding.
If nginx blocking isn't secure, I'd love it if someone could let me know 😄
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.