Is there a way to set default roles to all user that belong to specific role ?
I can manually alter the role to default for one user at a time, but it is time consuming and people come and go.
To answer your question directly: Setting the default role for multiple users within one statement isn't possible. It isn't possible to mention multiple users within one single ALTER USER-statement: https://docs.snowflake.com/en/sql-reference/sql/alter-user.html
Alternative solutions are:
Use Mike Walton's idea in the comments of your question and create a procedure that selects all users of a certain role and generates/executes an ALTER-statement for every user within the procedure (I like that one)
I once had a similar problem and created an Excel-sheet for all my users and roles. Here I maintained which user belonged to which role and used Excel to generate all my corresponding CRAETE ROLE, CREATE USER, GRANT ROLE and also ALTER USER-statements. So Excel generates the code based on your USER-ROLE-matrix and then you can paste the code to Snowflake. (Of course then you can extend and adapt that "excel code generator" for your use cases etc.)
Kind regards :-)
Related
I have a windows sql user that is assigned db_datawriter role on a db.
Presently the user can connect to the database via management studio and make changes to the data in the database.
Also, he can use a windows forms application that connects to the database (using connection string) using his windows credentials and modifies the data.
I want to prevent this user from being able to connect via management studio. But continue to allow him to modify the data via the windows forms application.
This is partly a security question, but also a design question, so I'll give you an answer on both fronts.
Using Interfaces
db_datawriter is almost always too permissive. Rarely does an application actually need the permission to write to every table in an ad-hoc manner. By way of analogy, think about the classes you create when you build an application. Do they look like this?
class MyClass
{
public int someIntIneedForAnInternalAlgorithm;
public string someStringThatCanOnlyChangeInternally;
public ISomeInterface SomeInterfaceMyImplementationNeeds;
// ...
}
Probably not. They should look more like this:
class MyClass
{
public MyClass(ISomeInterface injectedInterface) { // ...
private int someIntIneedForAnInternalAlgorithm;
public string SomeStringThatCanOnlyChangeInternally { get; private set; }
private readonly ISomeInterface theInterfaceIneeded;
// ...
In other words, some of the internal state of the class is typically private. You interact with it through some controlled public interface.
A database is not different. You can think of the tables as the "internal state". The application doesn't need direct access to all of that, it should access it through an interface. The interface could be made up of views, functions, or stored procedures. You then grant access only to the objects in the "public interface", according to the principle of least privilege
You might still want to allow users to read from the tables arbitrarily - for example, maybe you trust them enough to let them write their own queries for reporting purposes. But you don't let them write arbitrarily to the tables.
This isn't a complete solution: if your users are able to connect using their own credentials, they can still manipulate the database directly through that interface. But at least they don't have ad-hoc permission to interact with the tables arbitrarily.
Application Credentials
What if this isn't enough? What if you want to ensure that the only way to interact with the database is through the application? Well, then you create a login for the application. The application connects as itself, on behalf of the user, instead of forwarding the user's credentials.
There are, of course, downsides to this approach. For one, it means that you have lost information about who is doing what. Previously if you had something like a modified_by column on a table, you could populate that column with absolute confidence using something like the original_login() function. But now the original_login() function will return the application login. So you have to provide the user information some other way, for example as parameter data to your stored procedures, or by passing it as session context.
Another downside is that you might have been using active directory security groups to provide more granular permission. For example, you might have created a login for MyCompany\Sales Department, and granted that group special permissions to be able to interact with sales data. But now the application is doing the logging in for everyone, so it needs the ability to do everything.
Can I Have My Cake and Eat it Too?
"OK", I hear you say, "I understand these ideas, but here's the thing. I want to control access according the application's identity, but I also want to control access according to the user's identity."
Prima facie, the answer to this seems to be "tough luck", right? Like, isn't that a contradiction? You are either logging in as the user, or the application. It can't be both. So you can't control permissions according to both.
But that answer does make an assumption: It assumes that the only way to get identity information is via the transport credentials (ie, the login). But that's not entirely true. There are two ways to escape this apparent contradiction:
Log in using the application identity, pass the user identity as data, and resolve additional permissions with logic inside the database making use of the user identity data, or...
Log in using the user's credentials, use normal SQL Server roles and permissions to provide access to the interface, but make sure that the login is coming from the application.
How do you do each of these? Which is easier to implement? Which is more secure?
Unfortunately the answer to the second question is different from the answer to the third.
Let's look at the first way. Suppose you pass the users' active directory username to the database when you access it. Can you check the security groups of that user? Sure. You can use the xp_logininfo procedure to get the "permisison paths" for some given user name. But I'm not even going to start going into the details of how you would have to write your database interface in order to make use of this. In involves making use of execute as, it involves manually resolving sql permissions via data... it's just a hell of a lot of work.
So, forget that, what about the second way? Well, that's much easier. You come up with some secret key. You give the secret key to the application. The application still forwards user credentials to log in, but when someone tries to use one of the objects in your database interface, you check that the secret key is correct. You can again use session_context for this.
Is this "a bit of a kludge"? Maybe. But hey, we're trying to control permissions two different ways simultaneously. Absolute elegance is not something we're likely to achieve.
Using this approach in a stored procedure
create or alter procedure p as begin
set nocount on;
if (isnull(session_context(N'applicationKey'), '') != 'my secret value')
throw 50001, 'Access to this database is only allowed through MyApplication', 1;
/*
do work here
*/
end
Using it in a view...
create view v as
select *
from sys.objects
where session_context(N'applicationKey') = 'my secret value'
Quick, Dirty, Potentially Dangerous Hack if you want Minimal Code Changes
There is another way, but it has a lot of issues and I wouldn't really recommend it: A logon trigger. To use it, you would add the application name to your connection string, and make sure you set an initial catalog as well
"Data Source=MyServer;Initial Catalog=myDatabase;Application Name=myappname; Integrated Security=SSPI"
Then check the application name value of the connection string in the login trigger. You also want to make sure you don't prevent other potentially valid logins from connecting though, so check the database name too, as well as checking that the user logging in is a member of the group you want to restrict. In this example I've used the db_datareader role, but I would suggest making a role specific to your application:
CREATE TRIGGER application_check
ON ALL SERVER WITH EXECUTE AS 'sa'
for logon
AS
begin
if (
is_member(original_login(), 'db_datareader')
and db_name() = 'mydatabase'
and app_name() != 'myappname'
) rollback;
end
Thank you for helping on this!
I am designing an app with documents and posts sharing with Laravel.
I tried to do it myself since two weeks but I am not sure what the best is.
I've tried implementing many packages and used crud generators, but as a Laravel beginner it's difficult to find the good package and to mix them.
What I want is a system like google docs sharing behaviour but for posts.
You could write a post and set it as
private
shared with those with the secret link
shared with users names list (or ids in database)
shared with groups of users
So what is the best way to build that?
1) Using a package? Which one?
2) table_users | table_posts | table_permissions
one permission per user that can read / edit (permission level)
3) table_users | table_posts including permissions for each posts
owner_id
share_link
users_that_can_read
users_that_can_edit
If anyone can direct me to a good tutorial or give me a good start structure for this tables to be efficient and secure.
Maybe I do not see all the complexity of this so I will enjoy any suggestions
The problem for this is I want a more flexible rights management than wordpress one that provides user rights levels, the availability of data will be managed by simple subscribers for a lot of things(files, posts, maybe comments, groups and maybe more stuff).
You just need to create three tables roles,permissions and roles_permission.The roles of the user goes in the table roles table.the permission of a user are stored in the table permission.You can map the roles and permission of a particular user in the roles_permission table.However,for more flexible way to add role-based-permission use entrust package.In which,you can dynamically add/update/delete the roles and permissions in laravel.
Everything seems to work as expected, but I can't seem to find in the core method that removes aros_acos records.
The problem I am having is if I use $this->Acl->allow() it creates a record.
However $this->Acl->deny() doesn't delete the record. It merely marks it as denied (Which is fine, if you are looking to explicitly deny Aco's.)
Because my default action is to deny all unless there is an allow record in the aros_acos, I don't need those records, and on a larger project, this table is going to fill up quickly. Is there a method to remove those records? Or is this something I am going to have to do "manually"?
Thanks
If you want to mange the roles in wide level then use the CakePHP Acl Manage plugin for manage roles for users or group.
We currently have a single business unit and 90% records are owned by a single Scribe user. Now we have added a new business unit and out of 400K contacts, 30K contacts will be moving under this new business unit.
I have created a new user in CRM who belong to this new business unit. Next step is to change the owner of these 30K contacts to newly created user.
Correct me if I am wrong, but this is the only way I can move these 30K contacts in to the new business unit?
Problem I am having is changing owner field of these 30K contacts in one go. I can use advance find and then change owner that way but imagine doing 30K this way?! I can also export excel sheet with all records, change owner and import it back in but that gives error (may be because I am changing a very important security related record?)
One last option for me is to make this change directly in to the CRM database but that is not my favorite choice.
Any suggestion will be very appreciated.
You can also write a console application using the CRM 2011 SDK
http://www.microsoft.com/en-us/download/details.aspx?id=24004
this application will execute a RetrieveMultiple
http://msdn.microsoft.com/en-us/library/gg328149.aspx
and because are more than 5K need to do paging as explained here:
http://msdn.microsoft.com/en-us/library/gg327917.aspx
for each retrieved record you need to set the new owner using an AssignRequest message
http://msdn.microsoft.com/en-us/library/microsoft.crm.sdk.messages.assignrequest.aspx
The MSCRMToolkit on Codeplex has a Workflow Execution Manager utility which allows you to run an On Demand workflow on a FetchXML recordset. Haven't tried it myself yet but have been keeping it in my back pocket, just in case.
I know this is an old question but the easiest way I find to change the Owner on a large amount of records is to (carefully) edit the database directly. If you know what you're doing with SQL then it's a piece of cake, otherwise I would steer clear.
To Update the Owner of a Lead:
USE <DEPLOYMENT>_MSCRM
GO
UPDATE LeadBase
SET OwnerID = <guid of owner here which can be found in the OwnerBase Table>
It is similar for other entities, OpportunitiesBase for Opportunities etc.
***** WARNING, this will update every record in the LeadBase Table *****
I am developing multi-sites with drupal.
I have to take care of 10 sites and they need single login
I supposed I need to create separate user database to support that
feature.
i.e 10 sites, 10 database and +1 user database.
Where should I look and modify? User Module? Which lines?
Normally database settings are in settings.php file .
I had export the database and make and working user-database already.
Please kindly try to explain in details thanks.
I don't know the full details of your situation but it sounds like you might benefit from one database with prefixed tables and a shared user table.
See
http://thedrupalblog.com/setting-multi-site-drupal-6-installation-shared-databases-and-single-sign and http://drupal.org/node/201673 (bit outdated but may still be helpful)