We have built a secure share using secure views. Within our primary account, we have executed simulated_data_sharing_consumer under SYSADMIN and it works great, it works great for our consumers. However, we have a need to be able to perform the action for demo purposes. When I try to execute the view using SIMULATED_DATA_SHARING_CONSUMER under a different role, we get an error that the "shared view consumer simulation requires that executing role owns the view". I have transferred ownership to the role, but still nothing. What am i missing?
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 am trying to create a subscription during the application run time, the code should be able to create a subscription and clean it up after it finishes.
I want to do this with the least possible permissions to the service account I am using. For now, I have created a custom role and gave two access to the role pubsub.subscriptions.create , pubsub.subscriptions.delete.
Although this is allowing the creation and clean up of a subscription, it is allowing not only to delete the current subscription, but also the subscriptions created by other users in the same project.
How can I assign permissions, to be able to create subscriptions in Pub/Sub, delete the subscription created by this service account?
Another way to put it could be, how can I, create a subscription at run time and modify only this subscription's permission to include pubsub.subscriptions.delete. (with the same service account).
Is there a way to make a service account admin/editor for the resources(topics, subscriptions, compute engine, etc.) created by this account? something like an IAM role - make admin after resource creation.
Related Documentation Links:
https://cloud.google.com/pubsub/docs/access-control
This is impossible due to limitations of the Google IAM by design.
In Google IAM permissions correspond 1:1 with REST methods. To call a method, the caller needs that permission. In other words, permissions are granted on methods so that call them, and not on objects so that modify/rename/delete them, as would be necessary in your case. You want to delete a certain object, right?
To get more granular access, you need to assign a Policy with a Custom Role on a Subscription object explicitly, but you can hardly assign a Pub/Sub Custom Role below the Project level.
A Subscription creator does not become an "Admin" of the created object as it could be in an access management service with permissions assigned on objects. If explicit assigning of a Policy with a Custom Role on a freshly created Subscription was possible, it must be done by an account with a Role that can manage permissions: pubsub.admin for example. That means that you would have to grant this Role to your service account in addition to the existing Custom Role with the pubsub.subscriptions.create and *.delete permissions. As soon as you do this, the least privilege principle becomes meaningless.
Understanding IAM custom roles
Cloud IAM Documentation > Understanding roles > Pub/Sub roles
Access Control > Required permissions
Access Control > Roles
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.
We have the angularjs application where we have different roles associated to the users. For ex: the two roles are Admin and Local. Based on the role, we show some menu items for the Admin and adds more features/screen to the Admin .
The userInfo with the Admin Property is returned from the login response and based on what we decide which all menu and screens to be rendered .
But if we user the developer tool, and the set the break point where the admin property is used, and set the admin property as true the user even he is a local user would be able to access admin privileges .
In short who has some idea about the javascript code can get the admin privileges . Is there any idea other than minification of the code to prevent this kind of security threats
Thanks
As the front-end of your application will run on the client machine there is actually no way to stop a user from debugging or modifying the code. Thus it's impossible to prevent someone from tricking their local instance of the application to think it's signed in as an administrator.
If you simply want to hide the admin interface, one possibility is to have separate (or additional) templates for administrators and restrict access to these based on the user's privilege. If there is anything to be gained from this is up to you. You will still need to validate the rights to execute any privileged action on the server anyway. Obtaining administrative privileges on the client must never be the same as obtaining them on the server side.