I am new to Qlik Sense, and I have been assigned a task to divide users into two sets.
User Set A :
These users can Create App, Load data, Create data models and create sheets over data model, so these users have the privilege to edit the sheet and data.
User Set B :
These users can only Create and view sheets over data model or already created App. (limited privilege)
Any help or redirection to proper knowledge source is appreciated.
you can do this in the QMC( Qlik Management Console,web-based application for configuring and administrating your Qlik Sense site ).
Before you do that is important that you understand the way it works:
Access control is property-based.
Security rules are inclusive by design.
Then leaveraging QMC proprieties:
In the QMC, you can create customized properties that you can connect to resources. The main purpose of custom properties is to use them in the security rules. You can also create and connect QMC tags that can be used for filtering on the overview page of a resource. Tags cannot be used in the security rules.
Examples of applications for custom properties:
Grouping nodes by geography
Create a custom property called Countries and set the values to names of countries. Apply the custom property to your nodes and you can then create and deploy synchronization rules / load balancing rules to countries instead of individual nodes.
Grouping streams by department
Create a custom property called Departments with values appropriate to your organization. Apply the custom property to your streams and you can then apply security rules to streams according to their Departments property instead of managing security rules for individual streams.
Your case is the second one, and you can refer to this Access rights for user types, I would go creating 2 groups:
Group A: Developers
Group B : Contributors
Indeed
Developer : is allowed to create apps, sheets, stories, objects and can use and create data connections.
Contributor: is allowed to create stories and sheets for published apps but is not allowed to create new apps.
Here a general overview:
The following activities with corresponding access rights have been identified.
See table here
Related
I'm part of a frontend project and I need some help to bring our authorization model into keycloak. We're building on node.js and the whole project uses stateless micro services - as well as our frontend middleware as the whole backend services we use. The frontend uses the standard JS adapter for session and token management.
So far we have identified four roles: travel agent, back office, configurator and data security officer. That's easy so far. My problem is how to model the next authorization layer we need.
For example: For the travel agents we want to be able to grant per person whether he can see specific customer data or is able to cancel orders. There are about 6-8 options for the travel agents. Thus, for the back office there shall be options for stock operations or different views on orders.
Like the backend we don't persist any data! That's why I have store all the things in keycloak and find a way to easily bring these information back to our middleware.
Here's what I tried / thought of so far:
* Use groups for the first layer and roles for the second one. --> doesn't work because the groups don't get exposed in the token.
* Use realm roles for the upper and attributes for the lower hierarchy. --> attributes are not included in the access token.
* Use realm roles for the upper and client roles on the lower hierarchy. --> works, but we have to make sure that roles on the second layer are definitely associated with only one role on the first layer. I don't know how yet.
* Use roles for the first layer and resources on the second one. --> That seems to get very close to what we need. But at the moment I can't figure out the correct approach with all these policies and permissions...
Discussions here at Stack Overflow seem very fruitful and I wanted to give it a try, although I don't have any code to offer.
Thanks for any help and please let me know, if I shall provide some further information.
Sven
Unlike the downvoter, I find this to be a legitimate question.
It looks like you're on the right path in terms of using Keycloak groups/roles/attributes. You can pick a combination that suits your needs. For example, if you need a hierarchy structure, you might use groups. Or you might want to use roles since these can be composite.
Regardless of which path you choose, your problem is how to expose these in the token. It can be done using mapper configurations.
For example, to expose Roles for the user, you'll want to create a "User Realm Role" mapper that adds your roles as a claim on the tokens. To do this:
click on "clients" in the left side menu
click on the client you're using
click on the "Mappers" tab
add a mapper of type "User Realm Role".
There are also mappers for "Group Membership" and "User Attribute" that can be used to add these two concepts as claims. If those aren't enough, or if you need more fine-grained control, you can roll your own custom mapper. See the Keycloak documentation and other questions here on Stack Overflow for how to do this.
We are developing a keycloak(5.0.0) based solution where our clients can create their account with us and manage their own users - and only their users.
Initially with thought that we could use realms for this. Every client gets their own realm. After initial testing we deemed it might not be a good solution as after creating ~500 realms the application becomes unresponsive(https://issues.jboss.org/browse/KEYCLOAK-4593).
We decided to try using Groups to emulate a tenant. Our objective is to create during an external process(keycloak REST API) a group with an admin user.
Can't find currently a way how to restrict this administrator to be able to only manage their own group(creating subgroups, managing users, and giving them roles).
I've noticed several emails mentioning these features but I fail to find actual examples to make this work.
http://lists.jboss.org/pipermail/keycloak-user/2017-June/010882.html
http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009496.html
The second link shows exactly what we would like to achieve.
Current alternative I can see is to implement a facade(client or separate web app) which would restrict visibility and access to other groups.
Are there other alternatives?
Domains are virtual view of a data source that presents the data in business terms, allows for localization, and provides data-level security. ADomain is a metadata layer that provides a business view of the data accessed through a data source
this is domain definition as in Jaspersoft reporting tool.
I am currently given the task to build or come with a design to create some domains in tableau.. (like in jaspersoft)
examples of domains in jaspersoft
In jaspersoft when you click on a domain : ex customer domain: you will see the list of tables (that are selected)
How to do the same in tableau?
Please guide me on this..
The meta data layers in Tableau are quite lightweight compared to other BI tools, which is ofter a plus, but seems to fight against your assigned task.
Usually the best approach in Tableau is to learn to use the tool well, build visualizations for your business domain, test and refine them, and then later focus on factoring out common meta-data as your Tableau projects grow. That tends to work better than insisting on a big meta data design up front approach.
Still as you learn to use Tableau, the features that you'll want to understand related to your question are everything about data connections (which define how to connect to a data source, and the fields, data types, calculations, groups, sets, field roles etc). You can start with a data connection in a single workbook and then save the connection separately (typically on the server) so that it can be shared among multiple workbooks (to reduce duplication). You can also use Tableau Server like a proxy for your database.
For security, you can look into the groups and access controls provided by Tableau Server, along with user filters.
Some of the features you ask about might be more properly relegated to the database server, such as by defining common views visible to different users.
I'm developing a REST API using Zend Framework 1.12.3.
I have to implement subscriptions for different types of plans (i.e. Basic and Premium), each plan having different privileges (e.g. Premium may offer instant, daily and weekly SMS notifications, while Basic may offer only weekly SMS notifications).
Also, there may be custom plans only for certain clients.
I've added a column in the users table called subscription, but what I cannot figure out is where to save the privileges for each subscription plan.
Should I save these privileges directly into the DB (i.e. create a table called subscriptions, and another one called subscriptions_privileges having as columns subscription_id, privilege_name and privilege_value), or would it be better if I save them into the config file?
Thanks
Note: Actually this question is not linked with Zend Framework, it is system architecture question.
Short answer:
it is much more easy to hardcode your subscription plans in your source code configuration files;
it is much more flexible to store this data in database (you can create some administration panel to allow managers to manage them, track history of plan changes, use these data in analytical SQL queries). Theoretically you can deal with all this stuff through reading and writing to your config files, but databases are just the exact tool for these tasks.
P.S.: You can add separate layer of abstartion in your application. Use model objects for your subscriptions which can be populated either from database or from your hard-coded config files using different adapters.
I have a design issue that i'm facing and because i am relatively new to mongodb i think i need some help to make the right decision.
problem:
i am building a type of social networking website for let's call group A consumers. I also need to build this same type of website for group B consumers. initially, i want to keep them separate with no interaction/sharing between the two groups but i do not want to maintain two separate websites. so a multi-tenant solution is ideal. the tricky part of this problem is that at SOME point in the future, i want to create a website for BOTH group B and A consumers, essentially merging them into 1 website. this 1 website will have all users from the original groups A and B but now they can all see each other, interact with each other, friend each other, etc.
is the right path to first create a multi-tenant mongo database, then later how easy is it to remove this multi-tenancy?
I would suggest that you do not create and drop the databases. Instead you can have the application with 2 tenants like facebook and g+ with their own set of users. However at some point of time in the future, you can just share your facebook user to g+ or the otherwise. in this case, there is no need to drop / merge tenant based tables or database and they will remain intact.
Your application should have the multi-tenancy capabilities that enable user sharing across tenants or linking users across tenants and that is the sure shot approach.