Qlikview section access как сделать

Советы по работе с Section Access в Qlik Sense (2.0+)

Абсолютно не важно, какое у вас отношение к Section Access в Qlik: все равно с ним сталкивается со временем каждый разработчик.

Технология работы с Section Access в QlikView уже была описана в одном из текстов на Data-Daily. Та же технология Section Access разграничения прав доступа к данным органично перешла в серверную версию Qlik Sense, но есть ли разница в работе с Section Access в Qlik Sense? Сейчас опишу общий подход применения Section Access и его отличие в Qlik Sense.

Section Access: Краткое описание технологии

Section Access используется для разграничения доступа к данным. Section Access является частью скрипта загрузки, где определяется таблица доступа к данным.

Например, таблица авторизации Section Access слева идет по полю Страна (COUNTRY).

НА ЗАМЕТКУ! Конечно, в живом приложении таблица авторизации невидна в модели данных.

Что означает авторизация по полю Страна? Когда пользователь с конкретным ID пользователя открывает приложение, программа определяет, какие поля таблицы клиентов будут для него видимы.

В Section Access нужно определить минимум три поля: ACCESS, USERID и поле усечения, которое выстраивает связь с нужными данными.

Итак, в этом примере пользователь связан с полем Страна, именно определяло видимость или невидимость строк из модели данных: строки, которые были связаны со страной, были видимы. Страна же выступала полем усечения данных.

Усечение данных в системах Qlik может быть организовано в разном формате:

  • строковый уровень доступа,
  • агрегированный уровень доступа,
  • колоночный уровень доступа,
  • объектный уровень доступа.

Рассмотри каждый из них:

Строковый уровень доступа: Здесь вы определяете поле усечения, и какой кусок информации видит пользователь. Например, поле усечение Страна, оно связано с Испанией, то есть далее пользователь увидит только те данные, которые связаны с Испанией. Операции по продажам в других странах будут для него закрыты и невидимы.

Агрегированный уровень доступа: Схоже с подходом, описанным выше, но работает несколько иначе, то есть пользователь будет видеть детальную информацию по Испании, но по другим странам будет видеть только данные в агрегированном виде. Для других стран эта информация будет скрыта.

Колоночный уровень доступа: Ограничиваем доступ не по строкам, а по столбцам. Например, мы составляем приложение по эффективности работы персонала и хотим, чтобы эта информация была доступна не для всех. Тогда скрываем всю колонку.

Объектный уровень доступа: Можно ограничить доступ к конкретным объектам приложения.

Приложение может использовать комбинацию этих четырех подходов.

Section Access использует строковый уровень доступа к данным, позволяя использовать один мастер-файл для решения различных по масштабу вопросов по обеспечению безопасности данных. Лучше стремиться именно к тому способу организации доступа к данным.

Для агрегированного уровня доступа к данным лучше всего использовать два приложения: одно с детальными данными, которые вы сокращаете, используя поле усечения, а второе приложение без сокращения данных с агрегированными данными для всех стран.

Колоночный уровень доступа может быть организован через два приложения, при этом одно включает чувствительные поля, а другое нет. Хотя такой доступ можно реализовать и через единое приложение через поле OMIT в Section Access.

Объектный уровень доступа к данным, на мой взгляд, не слишком «безопасен» для работы, потому что, скрывая объект по пользователю, у особо желающего сохраняется доступ к самим данным через другие объекты.

Это общие моменты по организации доступа к данным. А теперь переходим к Section Access в Qlik Sense.

Qlik Sense: Что изменилось в Section Access

В Qlik Sense есть две системы авторизации:

  • Контроль доступа: дает доступ пользователям к ресурсам Qlik Sense. Работает через службу репозитария Qlik Sense (QRS) и зависит от операционной системы.
  • Усечение данных: основано на принципах Section Access, который работает динамически и изменяет отображаемые данные. Поэтому одним приложением могут пользоваться разные пользователи, которые должны видеть разные данные. Функция реализуется через Qlik Sense Engine Service (QES).

Каждая из типов авторизации работает отдельно и не связана между собой.

Усечение данные определяет, какие данные разрешено видеть пользователю – весь пласт данных или только отдельные куски.

Права доступа, также как и в QlikView, определяются скриптом загрузки.

Разделы в скрипте

Контроль доступа реализуется через таблицу(ы) безопасности, загружаемые в Qlik Sense также, как и обычные данные. Эти таблицы могут храниться в базе данных. Скрипт управляет таблицами безопасности и доступом к данным.

Если раздел доступа определяет в скрипте, часть скрипта загрузки данных должна быть размещена в разных разделах и иметь название Section Application.

Например:

Неофициальный форум разработчиков QlikView и Qlik Sense

Форум разработчиков QlikView и Qlik Sense. Получи любые ответы на вопросы по QlikView и Qlik Sense в течении нескольких часов!

  • Форум
  • » Для продвинутых
  • » Организация доступа к приложениям Section Access (Active Directory)

Страницы 1

#1 2015-04-03 12:13:16

Организация доступа к приложениям Section Access (Active Directory)

Собственно, хотелось бы узнать у кого и как организованы ограничения на доступ в приложения и на определенные данные в приложениях QlikView 11.20.

Вводные данные:
— Пользователей сейчас около 30, рост до 500+.
— Active Directory, с разделением по территориальным группам
— Количество готовых приложений сейчас

10, потенциал на 100-150.

Хотелось бы узнать от сообщества, как лучше поступить, варианта три:
— ограничивать права на приложения через AD
— ограничивать права через section access, с использованием групп AD или конкретных пользователей.
тут вопросы: как ограничивать права через группы AD используя section access
как администрировать эти права, скажем сразу в 100 приложениях для 1000 пользователей ?
кто разрабатывал свои решения для этого? какой функционал?
— создать одно приложение, в котором будут ограничения через section access на открытия других приложений.

В идеале хотелось бы огранизовать единый центр прав для всех пользователей и приложений QlikView с интеграцией AD.
Например, чтобы можно было легко дать права на просмотр 20ти приложений, одному пользователю, но с ограничением например по региону, или по магазинам.

Наилучший вариант, это наверно внешняя БД с данными правами, которые загружаются из, скажем SQL базы в момент перегрузки приложения, в которых мы используем ADMIN и USER права, а также какие либо отдельные поля.

Но так же необходимо и учесть, что если мы будем проводить «срез» данных, скажем по магазинам, то нужно еще и использовать все возможности паблишера, по разбивке приложений на эти магазины, и соответственно ограничить на них просмотр в access point.

В общем, думаю что тема интересная, и очень обширная, ведь в определенный момент любые, даже средние комании придут к этому вопросу.

#2 2015-04-03 20:57:55

Re: Организация доступа к приложениям Section Access (Active Directory)

Вопрос действительно очень интересный и варианты могут быть различные.
Наиболее используемый, на моём опыте, это разграничение через группы в AD, поскольку является самым простым для будущих администраторов системы.
Отдельные группы создаются как для территориального/структурного разделения так и для ограничения функционала приложений.
На уровне пользовательских приложений используются LDAP запросы к AD для создания таблицы в разделе Section Access, в которой каждому пользователю определяется доступ к набору данных и функционалу.
Для администраторов готовится инструкция по настройке доступов и далее они работают только с AD.

Читать еще:  Как сделать ссылку в access?

В случае использования Qlikview Publisher — можно частично (или полностью в зависимости от задач) сократить таблицу в Section Access и использовать Loop and Reduce также по группам пользователей.

При большом количестве приложений и вариативности разделения прав требуется более гибкий инструмент, например для случая быстро предоставить доступ пользователю к 20 приложения.
Альтернативой предложенному вами варианту с использованием базы данных, может быть специально созданное приложение Qlikview для управления правами. В нём будет информация о всех пользователях, приложениях и возможных ограничениях/срезах (измерения из приложений). Администратор с помощью указанного приложения будет создавать таблицы доступа для каждого приложения и сохранять их в обычные CSV, QVD файлы (не обойтись без написания макросов).
Пользовательские приложения будут подгружать таблицы доступа из созданных файлов и обновление прав будет вступать в силу согласно расписанию автоматических задач. Можно дополнительно внедрить в указанное приложение возможность быстрого обновления прав в выбранном приложении с использованием Partial Reload.

И кратко комментарии к вопросам:
«- ограничивать права на приложения через AD» — вариант удобный для администраторов, но недостаточно функциональный;
» — ограничивать права через section access, с использованием групп AD или конкретных пользователей» — по сути то, что я описал в начале, и боюсь для предоставления доступа группе необходимо предварительно выгрузить пользователей из неё (хотя в документации указано, что это возможно, но на практике не срабатывало).
«- создать одно приложение, в котором будут ограничения через section access на открытия других приложений.» — боюсь этот вариант потенциально опасен, ведь если пользователь использует прямую ссылку на другое приложение (полученную ранее например), то он минуя разграничение прав попадёт в приложение куда по факту доступа не должен иметь.

qlikcentral

Understand / Create / Inform

Section Access Reduction in Qlik Sense

Even with the advent of Qlik Sense Security rules in the QMC you may find yourself working with Section Access. Maybe you don’t have a server, maybe you want to guard against users just taking the QVF file (and all your data with it) or maybe you want to implement section access reduction. it was the latter that prompted the bog, seeing an interesting behaviour for the first time took a bit of investigating.

Either way the functionality can be tricky to implement. You often have you test various circumstances to see what works and in the process it wasn’t uncommon (back in QlikView) to lock yourself out of your own dashboard.

Section Access can do two things:

  1. Stop people accessing the dashboard
  2. Reduce what people can see based on their logon Id

Lets focus on the first…… Setting up Section access is simple. You just need a table loaded in from any source (inline, CSV, database, etc) and the table has to be constrained within Section Access; and Section Application ; statements.

In the table two fields are required

These have to be in UPPERCASE (as do all field names and values in this table). Once the data model has been reloaded the only person who can open the dashboard is user: DOMAINNAMERPEARCE

That’s fairly simple, the next stage of the process will be to look at reducing the data based on access granted to the USERID in the section access table. Lets review the next script:

We now have an additional field REDUCTION which would link to TableA by the field with the same name, in turn that would also link to TableB by the field Type. Because our user only has the REDUCTION value of 1 when we reload the data, save and close the dashboard and re-open there will only be one record in both TableA and TableB.

We reduce the data not only in the first table but in subsequent tables based on possible values! This is key if your data model contains a link that needs to be bridged no matter what as in the example below:

Section Access Reduction Data Model

Here the REDUCTION starts on the left hand Department table so I’d have grouped staff USERID’s by the department they work in. We move through the model reduction the data by possible value. This works well for the first three tables and users will only be able to see the sales data associated with their department.

If you consider how the next link will work… In this example I want all staff to see all purchases but this isn’t the case here. If you follow the logic both the Calendar and Purchase Tables will now only have records where there’s been a sale on the same date (and then only sales which associate with the person opening the dashboard) which isn’t what we want.

In order to resolve the issue we need to add dummy records to the sales table. One for each date there’s been a purchase duplicate those for each SalesPersonID. We can of course add a flag to ensure that data isn’t used in any counts or sums….

If we want a user to have access to several REDUCTION lines we simple add them again in the Section Access table:

If you want the user to see all the data there’s two ways to acheive this. You could change their ACCESS to ADMIN although the proper way would be to give them a * value for REDUCTION. (THIS CODE WILL LOCK YOURSELF OUT. )

The wildcard only refers to data within the Section Access table so in the example above there is no other data and as such the line isn’t loaded (and you’re locked out). In the example below you would see two records in tableA and tableB:

If you have other people that need to see 1 or 2 then of course you don’t need dummy lines but if you do use star * then you have to ensure all possibilities are covered in the section access table even if that means using a dummy record. This is what caught me out recently!

Finally we can look at the OMIT field. Now rather than reducing the records we can remove columns (Hint – Don’t remove Key fields!). Here is the Default, we have the field OMIT here but there is no value. That’s the same as saying leave all the fields intact… Lets remove the Comments Fields !:

We can add the first column name we want to hide from the user:

Now when we reload, save and re-open the dashboard the field comments still shows in the data model viewer although when you preview the data it’s gone (see below)!

Читать еще:  Как сделать чтобы форма в access запускалась при открытии?

Sense OMIT columns

We can repeat the process to remove more columns.

So effectively rather that saying what records we want to keep using REDUCTION we are saying what we want to remove by using OMIT! Pretty powerful stuff and remember this is available for free in Qlik Sense desktop. If you buy server licenses you get the QMC and even more power over what users can see by hiding sheets and objects using the security rules!

QlikView Section Access for defining data access in your applications

New age BI tools like QlikView and Tableau are making it easy to access information on the go. With this ease of access, there comes an additional danger – the danger of putting the application in wrong hands. Imagine what can happen if your QlikView application (which stores and presents information for all business critical decisions) falls in wrong hands!

Data Security is one of the top concerns for any Organization, more so for data driven Organizations.

In order to gaurd against this danger, QlikView (& now QlikSense) come with Section Access – a way to decide who can view what information, which objects can be viewed by whom and from which domain etc. These can also be set with help of QlikView publisher. In this article, we will discuss section access and show how it can be applied to a QlikView application.

What is Section Access?

It is a feature used to control the security of QlikView applications. Section access is defined as part of the load script, where we define an authorization table, i.e. a table where you define who gets to see what information and from where. Section access can be of various types, depending on the sensitivity of the information and business comfort:-

  1. A simple username and password might be sufficient to access some documents
  2. In some scenarios, you would want specific users in your domain to be logged in specific machines and use certain keys to unlock the information.
  3. You may also want to restrict access to specific objects and sheets of a document.
  4. Remove fields from the data model for the specified user (by omitting them).
  5. Row level data reduction based on authorization mentioned.

In this article, we will cover row level data reduction only and rest of the methods will be discussed in future posts.

Facts before Implementing Section Access:

Here are some basic rules to remember before implementing section access:-

  1. Backup your application because Incorrect syntax will render your document inaccessible and there’s no possibility of recovering the data or script.
  2. Section access data (Security table) loaded by an external source (xlsx, txt …) must be loaded by using upper case in the SECTION ACCESS statement.
  3. Security table contains several user-specific system fields, like USERID, PASSWORD, ACCESS are basic system fields. You can also combine several fields to build the Section Access solution depending on the desired level of security. (To know more about System fields, please refer QlikView Reference Manual).
  4. Apart from the standard fields, additional fields can be defined to administer data reduction for each user.

Problem:

For Sachin Dashboard (we had created this application as a tribute to Sachin’s test career), I want to restrict users to see his performance against a particular country only. Look at below security table, it defines the permission to user.

You can see that we have defined 10 users with userid, password, level of access and value for field AGAINSTCOUNTRY, for which these users require access. One of the key things, I want to discuss in the above table is, “*” in Section Access. “*” denotes all values i.e. users, who have access to see all values listed in the table. If a value is not listed in the security table, it will not be available to anyone.

For ACCESS, we have two access levels “ADMIN” and “USER”. ADMIN has privileges to change everything in the document and controls what “USER” can see in the document.

Implementation of Section Access:

Now let’s Implement this section access to an existing document. We will perform this in following steps:-

  1. Create a copy of existing document because if any thing goes wrong, we have a backup.
  2. As we know that we are going to apply restriction on row level data based on Against_Country field, so first let’s make sure that it is available in UPPER case. Here, I have converted it to upper case (Changes done to the original table).
  3. Add a new tab and write script to import Security table followed by Section Access statement using inline table or external file. (We are doing this with external file).
  4. Save document and then go to Setting —> Document Properties —> Opening tab and turn check box on for “Initial data reduction Based on Section Access” and “Strict Exclusion”.
  5. Save it and reload. Close the dashboard after the reload.
  6. Now Open dashboard, here it will ask for User Identification and based on your user permission you will be able to see the results.
  7. Here, I have given USERID and password of Kunal and i am able to see Sachin Test Career summary only for the country Australia (as mentioned in Security table).

End Notes:

In this article, we have seen an example of how to restrict user to row level data limitation using Section Access. We also looked at what are security feature we should look at while developing or delivering dashboard. I recommend you to apply security feature to document before sharing it with any one.

In future, we will also discuss about other security features like NT domain identification, document properties (Sheets, Object), field level security. It also provides an example of how naming conventions can be used to architect a solution that is more robust and lowers maintenance costs for your QlikView documents.

If you like what you just read & want to continue your analytics learning , subscribe to our emails, follow us on twitter or like our facebook page.

You can also read this article on Analytics Vidhya’s Android APP

Qlikview section access как сделать

When comparing Qlik Sense to QlikView, the most obvious differences are on the front-end, with its completely overhauled and fully responsive design. Other major differences are the server-based development, the use of Master Items and the shift towards APIs, mashups, extensions and widgets.

Somewhat less prominent, though very deserving of your attention, is the security model in Qlik Sense. This has a completely new approach compared to QlikView, and you can pretty much create endless variations. Rather than hacking stuff together and hoping it works, my colleague Rik and I recently decided to take a more structured approach and do some R&D on Sense security rules. Our goal was to gain more understanding of security in Sense, develop methods for gathering and modeling security requirements and to design reference patterns for common implementation scenarios.

Читать еще:  Как сделать запросы в access 2007?

We will be sharing some of the methods and patterns that we came up with in an upcoming white paper. In the mean time, I’d like to share with you some of the little interesting, strange and otherwise noteworthy things that we found. These range from basic to slightly obscure, but all should hopefully help you get more understanding of Qlik Sense security rules. Let’s start with noting that the approach in Sense is totally different than it was in QlikView…

The ABAC-approach
In Qlik Sense, security works via Attribute Based Access Control. This, in short, means that a user gains access to any part of the environment through the use of security rules (policies) that combine attributes. These rules can use any type of attribute: derived from the system or created by the user (custom properties). These attributes may belong to any resource: users, streams, apps, app content, data-connections and in fact every single facet of the Sense QMC. Together, the created rules combine into a greater total of conditional (IF, THEN) statements to form the user’s security access.

Resources
When creating security rules, we have to define the resource filter. This answers the question: to what resource(s) should we grant rights based on the condition? By being able to set rules on all these various resources, we can be very flexible. However, when trying to create and combine rules to create roles, we found that there are a lot more resources to be used then the dropdown is suggesting, and some of those are not to be left out! Here’s a list.

QmcSection-resources
Among these resources, there are the QmcSection*-resources. What these do, is plainly allow the user to access those particular sections in the QMC. When allowed into a section, we still have to assign rights to the users to create/read/update/delete the content. Now, why we can still choose to apply these rules to Hub, QMC or both is unclear to us, for, in the case of QmcSection*-resources, they obviously only apply to the QMC. Take notice of this when building the rules. This seems a bit of a strange behaviour, and the effect in the hub of setting a rule on such a resource is not entirely clear to us.

The use of e.g. App* vs App_*
When choosing your resources, take notice of the use of ‘*’ vs. ‘_*’ as the resource filter; a slight difference, but with big impact. The first version creates a rule on every resource from App down (app_objects, app_datasegments etc.), the latter only goes for Apps. Using the first will grant access to all underlying objects, data_segments etc. Using the latter will result in visible apps in the Hub, but when opening, no content will be shown. This way, we can grant access to certain app_objects to certain users, while denying access to that data to other users – if we would want to. Very flexible indeed, but be aware of this use.

Attributes and custom properties
Resources have standard attributes. Think of a Name, an ID and maybe a Group for a user, derived from the user-connection. On top of these ‘standard’ attributes, custom properties can be created and assigned to further enrich our resources. For example, we can create the custom property “@Department”, and assign this to a stream, a user, a data-connection etc. This custom property may than be used in security rules, so that we can grant or deny rights based on a department. This is an example of course, but you may see the use in other ways.

Rules
As noted before, in Qlik Sense, the security setup is done by creating rules. These rules use conditional structures (IF, THEN) to grant or deny access. What’s important to understand, is that in Qlik Sense, a user does not have any rights, unless you
assign
them. This
means we have to start from absolute scratch and that we can go every direction we want, because we can use all sorts of attributes (of users and other resources) to grant access to all types of resources. As mentioned, both inherited attributes as well as newly created custom properties may be used to create the rules.

Overlap in rules
When building security rules, we found that rules may overlap. You will notice this when you build those rules yourself, but some standard-delivered rules may overlap your rules. We found this out by setting publish rights for certain users. The user had the right to publish apps, and we thought we had restricted this users’ streams. However, a rule giving him access to all streams (streams*) was applied as well. Not so clever of course, but this might happen. Therefore:

Use the Audit function!
It’s great. It truly is. The audit function comes in very handy when building roles using security rules. The audit-functionality gives an overview per user and his rights per resource of your choice.

When clicking on a letter corresponding to a certain right, ‘Associated rules’ becomes available. When clicking this, an overview of all rules applicable to this user/resource is shown. This way, overlap (or gaps) in rules can be spotted easily, and by clicking the rule and ‘View’, we may than go into the security rule and alter this, or even disable or delete it.

Section access
After creating the security rules, we found that also in section access, there are some differences as compared to QlikView. We do not go into this here, but find the most important things on SA in Sense here.

Hiding the Dev Hub
One last thing on giving or denying rights to users. If we want to refrain users from entering or using the Dev Hub (deny access to this section), this does not seem possible.That is, the Dev Hub is not a resource we can apply rules upon. However, when zooming in on, it, my colleague Vincent Hayward found a work around. Find his answer in this QlikCommunity-thread.

Room for additions…
So, as you might have noticed, this is just a list of things we found to be notable. If you have encountered any other items, please share them in a comment below. We might build a nice and compact knowledge base here!

Ссылка на основную публикацию
Adblock
detector