Simple Qlik Sense Section Access - security

I am attempting to use section access with Qlik Sense. I am testing against "ADMIN1", that is a RootAdmin in Qlik Sense, but also admin in the Windows server. I tried the following script in data load editor, I hit load data, quit then re-enter. Qlik says: "Access Denied".
Section Access;
LOAD * Inline [
ACCESS, USERID
ADMIN, ADMIN1
];
Section Application;
LOAD * Inline[
Customer, Age
1,1];
I replaced ADMIN, ADMIN1 with ADMIN, DOMAIN1\ADMIN1 but still "Access is Denied". Same when I try ADMIN, * or ADMIN, '*'.
How can I make this simple test work?
Thanks,
Amir.

In case someone comes across this same issue, here's an example:
section access;
LOAD
ACCESS, USERID, SECURITY;
SQL SELECT access AS ACCESS,
'DOMAIN\'+UPPER(userName) AS USERID,
SECURITY
FROM dbo.securityRules;
section application;
LOAD
field1,
field2,
secureFieldID AS SECURITY;
The securityRules table "Access" column is either set as "ADMIN" or as "USER", the secureFieldID column either indicates an ID which corresponds to the resource we are granting access to (e.g. cost centre ID, section ID etc) or it can be "*" for ADMIN which means they can see everything which is defined in the table (all users access).
Everything in uppercase per the example or it will not work.

Just noticed that in all Sense documentation, regarding Section Access, there is no "ADMIN" value in "ACCESS" column. When I've changed "ADMIN" to "USER" everything worked.
Section Access;
LOAD * Inline [
ACCESS, USERID
USER, MYDOMAIN\ADMIN1
];
Section Application;
LOAD * Inline[
Customer, Age
1,1];
Also make sure that the username is used with domain prefix and this domain is added as "User directory connector" in QMC.

Related

Inviting a guest User to a SharePoint Site using PowerAutomate

We are developing a PowerAutomate Flow to automate the process of inviting external users to a SharePoint Site.
Below are the steps being followed so far
Created an MS Form for an external user to register
Passing the response**(Email)** from the form to the flow
Adding the user to a SharePoint Group using email parameter and sending an email invite to the External User(Requirement)
I have been able to get to point no 2 , However I have been experiencing challenges achieving point no 3
Came across different articles online for adding a guest users , However most of them talk about adding the guest to Azure AD as shown below
https://medium.com/southworks/adding-a-guest-to-an-office-365-sharepoint-site-with-javascript-fa7604ad8678
https://laurakokkarinen.com/how-to-build-a-guest-user-self-service-registration-for-office-365-with-azure/
https://www.timlinenterprises.com/how-to-invite-external-users-using-microsoft-flow-and-microsoft-graph-api/
Also checked a few articles for running PowerShell commands from Flow , However this approach doesn't look straightforward either
The below article works only for internal users
https://www.c-sharpcorner.com/article/add-the-users-to-the-sharepoint-groups-using-microsoft-flow/
The end goal here is to invite external user to a SharePoint Site once the user registers himself through a registration form (MS Form)
Would appreciate if anyone could help me out in achieving this.
Thanks in advance
Before inviting the user to SharePoint you must add him to Azure AD. So you will need to configure an HTTP action to invite the user first.
If you are using SharePoint Modern Sites (those who have Microsoft 365 groups associated), you need to create a HTTP action to add the guest to the group:
HTTP Action Configuration Here
NOTE: HTTP will not accept "#" sign directly, so you need to put it into a "Compose" or "Variable" and add it as per my screenshot.
In the URI you have the Group ID from Azure AD.
In the Body it's the guest user ID
You will need to register and Azure AD App to use for the HTTP action and give it the following permissions:
Graph -> Application -> GroupMember.ReadWrite.All, Group.ReadWrite.All and Directory.ReadWrite.All
https://learn.microsoft.com/en-us/graph/api/group-post-members?view=graph-rest-1.0&tabs=http#permissions
Use the App ID and Secret to connect the HTTP action.
This is my solution to add Guest Users to Private Channels in MS Teams with PowerAutomate.
Step0 - Register the domain of the Guest Users in your AD account as a valida Guest Domain
Step1 - User a registration form (MS Forms)
Step2 - Create a Trigger Process in MS PowerAutomate to receive the Form Data. I like to create small/short flows to only capture and validate form data, and then call a separate Flow / RestService. This makes your solution a little bit more decoupled and reusable. (Imagine replacing the Form with a web app form or mobile app form in the future).
Create a second HTTP request trigger flow receiving the Form data (optional way to setup multi-flow solution)
Step3 - Create a Private Channel in teams via GrapAPI
GraphAPI - POST https://graph.microsoft.com/v1.0/teams/<teams_id>/channels
POST BODY:
{
"membershipType": "private",
"displayName": "<e.g. channel name from form data>",
"description": "<e.g. description from form data>",
"members": [
{
"#odata.type": "#microsoft.graph.aadUserConversationMember",
"user#odata.bind": "https://graph.microsoft.com/v1.0/users('owner.user#mydomain.com')",
"roles": [
"owner"
]
}
],
"#odata.type": "#Microsoft.Graph.channel"
}
Step4 - Call GraphAPI to retrieve the Guest User Details
GraphAPI: GET https://graph.microsoft.com/v1.0/users?$filter=mail eq 'guest.user#email.com'
I have added this in a loop - since I had many members who had to be added - and I also included a condition check to check if the domain is indeed valid
Now you can assign the output (or portions of the output) to some variables
Step5 - Retrieve the ID value from the step above (Step4). This is the value that must be used to add the new guest member.
Retrieve the ID from the Step4 output
Also set a variable to the account type - which should (MUST BE) be "guest"
Now - Add guest users to the private teams channel
Step6 - Call GraphAPI to add guest members
GraphAPI: POST https://graph.microsoft.com/v1.0/teams/<team_id>/channels/<channel_id>/members
Post Body:
The role must be "guest" for guest account
But valid options for other types of access can be
owner
member
guest
Microsoft documentation (HERE) states roles must be owner or empty
This did not work so well for me.
Use guest
{
"#odata.type": "#microsoft.graph.aadUserConversationMember",
"roles": [
"#{variables('membership_type')}"
],
"user#odata.bind": "https://graph.microsoft.com/v1.0/users('#{variables('principal_user')}')"
}
Bonus Step
Now you can catch all responses from the previous steps and respond back with an HTTP Request/Response connector.
A 200 response on successful executions
A non-200 response on failed executions (or how ever you desire)
To configure exception handling or failure handling responses do this below

DataProc BigQuery Connector Access Across Projects

I am writing a Spark Job to run on a DataProc cluster in Project A but the job itself will pull data from a BigQuery instance in Project B using the BigQuery Connector. I have owner privileges for both project, but the job is run using a service account. The response I'm getting in the stack trace is this:
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Access Denied: Table ABC:DEF.ghi: The user me-compute#developer.gserviceaccount.com does not have bigquery.tables.get permission for table ABC:DEF.ghi.",
"reason" : "accessDenied"
} ],
"message" : "Access Denied: Table ABC:DEF.ghi: The user me-compute#developer.gserviceaccount.com does not have bigquery.tables.get permission for table ABC:DEF.ghi."
}
As you noticed, Dataproc clusters run on behalf of service accounts instead of individual users; this is intentional, since different users may be creating Dataproc clusters in a shared project where they do not want their personal permissions to leak across other members of the org using the same project, and instead should define permissions according to service accounts which each represent a particular scope of workloads.
In this case, all you have to do is go into project B and add the service account from project A as one of the roles that can access BQ in project B. If it's not a complex arrangement withlots of users and different teams, you could just add it as "project viewer" on project B, otherwise you'll want something more fine-grained like a "bigquery viewer" or "bigquery editor".
Add that service account the same way you would add any user to project B.

CouchDB, limit creating users to admins only

I'm working on a CouchDB backend that will exist as a central store for a React app using PouchDB. Reading the docs on the security section: http://docs.couchdb.org/en/2.1.1/intro/security.html, one does not need an admin account or a user account of any kind to create user records. Now, they wouldn't be able to create any documents, as I have admin party disabled. But I also don't want an open API end point to allow just anyone to write data. Is there a way for me to restrict this?
I've tried to see if I could setup a security document like so:
curl -X PUT http://admin:admin#localhost:5984/_users/_security -d '{"admins":{"names":[],"roles":[]},"members":{"names":[],"roles":[]}}'
But I'm still able to add users:
curl -X PUT http://localhost:5984/_users/org.couchdb.user:abc1 -d '{"name":"abc1", "password":"abc1", "roles":[], "type":"user"}'
Is there something I can change so I cannot do a put request to the couchdb.users namespace without admin credentials?
You are setting no admins or users in your security document and a database with no members allows any user to write regular documents, same as default behaviour.
Try to set your server's admin as _users database admin, i.e. change the security document to -d '{"admins": { "names": ["admin"], "roles": [] }, "members": { "names": [], "roles": [] }}' or even better create an admin role and assign it to a separate CouchDB user for more granular control.

Symfony - Understanding super admin

I'm trying to understand something about Symfony and the "super admin".
When I use FOSUser to create a user with super admin privileges
php app/console fos:user:create adminuser --super-admin
I'd firstly like to know what means (from the doc)
[...]Specifying the --super-admin option will flag the user as a super admin[...]
I imagine it means granting ROLE_SUPER_ADMIN to the user because I don't see any super-admin field in the user table.
Secondly, while (still from the doc)
A super admin has access to any part of your application
security:
role_hierarchy:
ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH, ...]
Why do we still need to configure the access hierarchy for it ?
Looking at FOSUserBundle's code you will find that the CreateUserCommand if invoked with the --super-admin flag will call the UserManipulator with a boolean argument $superadmin=true.
Now the UserManipulator calls the UserManager who will create a User Object, call it's setSuperAdmin() method and persist the new user afterwards.
The method looks as follows:
public function setSuperAdmin($boolean)
{
if (true === $boolean) {
$this->addRole(static::ROLE_SUPER_ADMIN);
} else {
$this->removeRole(static::ROLE_SUPER_ADMIN);
}
return $this;
}
So answering your first question:
Yes, the --super-admin flag causes FOSUserBundle to create a new user with the ROLE_SUPER_ADMIN role.
You still have to include the role hierarchy in your security configuration because the ROLE_SUPER_ADMIN role basically doesn't differ from any other role.
It's just a convention provided by the Symfony standard edition that users with role ROLE_SUPER_ADMIN should not have any access restrictions.
If you want the ROLE_SUPER_ADMIN to bypass all security voters by default - have a look at JMSSecurityExtraBundle's IddqdVoter which implements this for the special role ROLE_IDDQD. But this has already been suggested in your other question here.
By defining the hierarchy, you explicitly grant it the ROLE_ADMIN and ROLE_ALLOWED_TO_SWITCH roles (or other custom roles you could have)
If you comment this line, and you try to access with your ROLE_SUPER_ADMIN user to an action with a ROLE_ADMIN check, you will get a not allowed error.
The ROLE_SUPER_ADMIN is just a convention for the name the super administrator role should have, but it does not have privileges by it's own, you have to explicitly grant them to it.

How to create a user with readonly privileges for all databases in Postgresql?

I want to create a user with only select privilege for all tables in all databases. I thought that I could get a list of databases and apply the following command for each database:
GRANT select ON DATABASE dbname to user1;
But I got the following error:
ERROR: invalid privilege type SELECT for database
When I googled people advised to do the grant select operation for all tables. But new tables are being added always. So this is not an acceptable solution for me. Does anyone know any workarounds?
You need to do 2 things: firstly, allow access to existing objects; and secondly, set the default access for new objects created from now on.
Note that granting access to "TABLES" includes views, but does not include sequences (such as the auto-increment function for "SERIAL" columns), so you'll probably want to grant access to those as well.
The below assumes you want to do everything in the public schema. The ALTER DEFAULT PRIVILEGES statement can act on the entire database by omitting the IN SCHEMA ... clause; the GRANT has to be run once for each schema.
-- Grant access to current tables and views
GRANT SELECT ON ALL TABLES IN SCHEMA public TO user1;
-- Now make sure that's also available on new tables and views by default
ALTER DEFAULT PRIVILEGES
IN SCHEMA public -- omit this line to make a default across all schemas
GRANT SELECT
ON TABLES
TO user1;
-- Now do the same for sequences
GRANT SELECT, USAGE ON ALL SEQUENCES IN SCHEMA public TO user1;
ALTER DEFAULT PRIVILEGES
IN SCHEMA public -- omit this line to make a default across all schemas
GRANT SELECT, USAGE
ON SEQUENCES
TO user1;
PostgreSQL manual
http://www.postgresql.org/docs/current/interactive/sql-grant.html
http://www.postgresql.org/docs/current/interactive/sql-alterdefaultprivileges.html
You cannot do this on database level, only on schema level.
Assuming you are only using the public schema in each database, you can do this:
GRANT SELECT ON ALL TABLES IN SCHEMA public TO user1;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO user;
I realize you've already said this isn't an acceptable answer, but it's the right answer anyway.
Specifying security (GRANT and REVOKE) is part of table design and testing.
Don't move tables to production before table definitions, security, tests, and test data are under version control.
Having said that, PostgreSQL doesn't have any SELECT permissions on databases. You can grant only CREATE, CONNECT, or TEMP permissions on databases.
You can grant SELECT on all tables in a given schema. I don't know how that affects tables created after running the GRANT statement, but it's fairly easy to test.
PostgreSQL Grant syntax
For Postgres versions lower than 9.0:
psql -d DBNAME -qAt -c "SELECT 'GRANT SELECT ON ' || tablename || ' TO USER;'
FROM pg_tables WHERE schemaname = 'public'" | psql -d DBNAME
psql -d DBNAME -qAt -c "SELECT 'GRANT SELECT ON ' || viewname || ' TO USER;'
FROM pg_views WHERE schemaname = 'public'" | psql -d DBNAME
psql -d DBNAME -qAt -c "SELECT 'GRANT SELECT ON ' || relname || ' TO USER;'
FROM pg_statio_all_sequences WHERE schemaname = 'public'" | psql -d DBNAME
I do the next steps for create read-only user:
create your_user:
1. createuser --interactive --pwprompt
go to postgresql in your_databases:
2. psql your_database
define access privileges:
3. GRANT SELECT ON ALL TABLES IN SCHEMA public TO your_user;
define default access privileges:
4. ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO your_user;
Try:
CREATE USER readonly WITH ENCRYPTED PASSWORD 'yourpassword';
GRANT CONNECT ON DATABASE <database_name> to readonly;
GRANT USAGE ON SCHEMA public to readonly;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;
I'm aware that this is a very old question, but it still comes up when searching for this problem so I'm just posting this for an up-to-date answer.
As of Postgres 14 or newer, there are now predefined roles for that purpose:
CREATE USER your_readonly_user WITH PASSWORD 'changeme';
GRANT pg_read_all_data TO your_readonly_user;
According to the docs, this gives all the necessary privileges to:
"Read all data (tables, views, sequences), as if having SELECT rights on those objects, and USAGE rights on all schemas, even without having it explicitly. This role does not have the role attribute BYPASSRLS set. If RLS is being used, an administrator may wish to set BYPASSRLS on roles which this role is GRANTed to."
See here for more info on the predefined roles.

Resources