We're looking to share data with departments that share a single Snowflake account, but need differential access to our data.
From the Snowflake documentation, it looks like sharing is always at the account level. Is there any way user or role level access can be controlled from the data provider side, or does this require the data consumer to do the appropriate grants?
Update: We're using secure data sharing to share data between accounts. We want to be able to restrict access to certain users or roles on the other account, if possible.
The snowflake access is actually role-level, there's no account-level access. The roles are set in a hierarchy and you can use that to customize your access quite extensively. Please take a while to read about the best practices before setting up the roles:
https://docs.snowflake.net/manuals/user-guide/security-access-control-considerations.html
edit: and for secure data sharing you're most likely looking at https://docs.snowflake.net/manuals/user-guide/data-sharing-reader-config.html
Related
We are looking at integrating our apps with Openid connect for our react based apps. We have ui and relevant permissions based on user - menus, navigations etc.
Can anyone point to spec or suggest on how do we handle such permissions in relation to openid connect or oauth. Basically how do we make this permissions available to ui, one approach is dedicated API for ui permissions again authorized by access token.
Another approach is permissions in token itself. Scope is one way of holding info, but it is for delegated access. Hence we are thinking to use multivalued custom attributes for holding roles and permissions in access token. But these permissions can also be huge sometimes and thinking hence if it is good idea to keep permissions in access token.
Any valuable pointers or any design approaches for handling ui permissions list please let know, we highly appreciate it.
The most flexible option is a custom API endpoint. An access token should hold important identity values such as these:
User ID
Roles
Company ID
Tenant ID
Country Code
Subscription level
These are claims, and are populated at runtime for each user, unlike scopes, which are fixed at design time.
Access tokens are designed only to be used by APIs, and clients should never read their payload. A good practice can be to return opaque unreadable access tokens to clients, to enforce this.
The actual permissions for a role can be looked up by the API once, then cached. This is preferable to storing large payloads in access tokens.
Finally, permissions for UIs may originate from two data sources: the identity data and your business data. The API can combine a result from both data sources, and transform the result to what the UI needs. Eg which columns are visible, which are read only and so on.
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 am creating a REST API for my next project. I am not sure what the best way to handle read / write permissions on resources is. Some resources will be readable by anyone, others will only be readable by "logged in" users, others will only be readable by specific users or admins. This also goes for write access.
How are these permissions stored and validated in REST APIs. Are there simply database tables that store the permissions for each resource or the permissions each user has to each resource? This approach seems like it could become bloated if there were many resources to keep track of not to mention every database query would require a JOIN to the table that contains permissions.
Thanks for your input in advance!
How your server side stores authentication and authorization data is entirely up to the server. It may use a database, it may use files, or none of the above.
From the perspective of RESTful HTTP, the point is that client might try to access some resource, the server may answer with 401 (Unathorized/Authentication required) or 403 (Fordbidden) HTTP error codes to enforce login/permission requirements.
Also remember, that not all services map directly to one or more relational database queries. In other words, plan to implement the authentication/authorization logic independently of the "data" if you can, and if you need fine-grained access restrictions, try to do it in code instead of joining stuff in the database, if it's possible.
I have a webapp deployed on GAE and users can sign-in using OpenID. Once users are signed-in they can access the data store for their own data.
Now, if I want to establish a "shared data space", how can I achieve such a thing? Can I give access to user A to data from user B? We share entities? How can I overcome access restrictions?
Any help on this aspect will be greatly appreciated.
EDIT 1
Not quite the BigTable expert. I'm not looking for magical kingdom solution, just pointer on how to tackle this problem (blog, article, tutorial, etc).
But if I get it right, data is accessible by anyone with access to the application (if access control is available). So if I give the a {KEY, entity} pair to user B from user A he will be able to access it no problem?
Maybe I'm just confusing concepts...
The GAE datastore is a database. Data stored in it is in no way restricted to a single user. BTW, you don't even have to sign in to use a GAE application. Just query for the data you want, and you'll get it, whether the current user stored it or anyone else is irrelevant.
I need clarification here, please. I'm currently learning EJB, and i've read about limitting the access right of methods to the users in certain "roles." I know how the metadata to limit the access rights works. But, what i dont know is how to put the users in the respective roles. Are the users' roles set in the database, and the ejb goes into the database and check to role(if so, how)? I mean, where or how to i progamatically impose that certain users belong to , for example, the customer role or the administrator role? If you know any books, you can also provide the title if you want.
Thank you.
There are several ways to declare roles in an EJB application (database, property files, LDAP ...).
Also since EJB 3.0, you can use annotations in your session beans :
#RolesAllowed("blabla")
#PermitAll
#DenyAll
#RunAs
It's called declarative authorization. As opposed to programmatic authorization (methods getCallerPrincipal() and isCallerInRole() from the javax.ejb.SessionContext object).
You can find many examples online.
User configuration is specific of the Application Server. Security in EJB is only about roles. I use Glassfish and it has many ways of configuring users: file (default), jdbc, ldap, etc. Each way is called a realm. All depends on the server you are using so check the documentation. In Glassfish is just a little tedious because of the mapping of server roles to application roles.