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

Неофициальный форум разработчиков 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.

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

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

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

Читать еще:  Как сделать форму в окне в access?

Практика бизнес-анализа на QlikView, Qlik Sense, Tableau

Бизнес анализ с QlikView, Qlik Sense, Tableau, Microsoft Power BI, Prognoz

Свежие записи

Свежие комментарии

  • gromych к записи Применение ABC-анализа на практике, ABC-анализ в QlikView
  • gromych к записи Starter Pack консультанта QlikView
  • Sergii к записи Starter Pack консультанта QlikView
  • 576457 к записи Применение ABC-анализа на практике, ABC-анализ в QlikView
  • Антрацит к записи Применение ABC-анализа на практике, ABC-анализ в QlikView
  • FAQ по разграничению прав доступа в Qlik Sense/Qlik View

    Q: Правильно ли концептуально, что * — это не любое в данных, а любое из таблички SECTION ACCESS
    т.е. пользователь ADMIN увидит не все данные, как ожидалось бы, а только 1 и 2 записи, т.к. прав для 3 в SECTION ACCESS вообще не расписаны.

    SECTION ACCESS;
    LOAD * INLINE [
    ACCESS, USERID, PASSWORD, REDUCE
    ADMIN, ADMIN, ADMIN, *
    USER, USER1, USER1, 1
    USER, USER2, USER2, 2
    ];

    DATA:
    LOAD * INLINE [
    SUB, GRUUP, SUM, REDUCE
    SUB1, Group1, 100, 1
    SUB2, Group2, 200, 2
    SUB3, Group2, 300, 3
    ];

    A: Могу даже модель приложить.

    Если
    * — показывает из списка описанных прав 1 и 2
    Пусто — действительно показывает Все 3.
    Во как.
    https://community.qlik.com/servlet/JiveServlet/download/1276635-280316/acc.qvw

    Q: Подскажите, можно ли в рамках одного отчета разграничить данные для разных пользователей.
    Например есть несколько отделов в магазине и что бы заведующие из разных отделов видели данные только по своему отделу? Или нужно делать разные отчеты?

    A: Если речь не идет о разграничении прав на просмотр (то есть принципиально не запрещается заведующему отдела А видеть отчет по отделу Б),

    то можно использовать функцию OSUser(), которая возвращает логин учетной записи пользователя

    Далее на лист с отчетом ставим триггер, организующий выборку в поле «Отдел»:
    iF(OSUser()=’Ivanov’, ‘Отдел А’, iF(OSUser()=’Petrov’, ‘Отдел Б’))

    Либо можно в скрипте загрузки организовать таблицу соответствия логинов и отделов и в отчете ограничивать измерение отдела значением, соответствующим логину.
    В общем решил остановится на SECTION Access. Но элементарный скрипт не работает. Захожу под любым ID и вижу все товары:
    SECTION Access;

    LOAD * INLINE [
    USERID, ACCESS, PRODUCTTYPE
    U1, USER, A
    U2, USER, B
    U3, USER, C
    U4, USER, D
    U5, USER, E
    U6, USER, A
    U6, USER, B
    U6, USER, C
    U6, USER, D
    ADMIN, ADMIN, *
    ];

    Tovar:
    load * inline [
    Товар , PRODUCTTYPE
    Полоценце , A
    Полоценце , A
    Салфетка , B
    Салфетка , B
    GT , A
    Нож , C
    Нож , C
    Нож , C
    Нож , C
    Вилка , D
    Вилка , D
    Вилка , D
    Вилка , D
    Вилка , D
    Кружка , A
    Кружка , B
    Кружка , C
    Диван , B
    Диван , B
    ];

    Q: Вопрос, можно ли реализовать в Qlik Sense следующий сценарий данных:

    заранее определюсь пользователь — это бизнес пользователь системы, финансист, он умеет только смотреть на диаграммы

    1. из БД в qvd с множеством преобразований грузяться факты в Qvd файл, сотни миллионов записей, за периода 1 год
    2. пользователь знает что ему нужно работать с аналитикой за последний месяц, он в интерфейсе приложения выбирает период соотвествующий
    3. в память из qvd файла поднимаются только данные за выбранный период

    цель — использование qlik sense в условиях когда данных очень много, а сервер ATX с двумя процами и 64 гига оперативки

    A: Вот как реализовать Ваши задачи в Qlikview — могу подсказать.
    А вот что касается Qlik Sense — то в «базовой комплектации» еще многого пока не хватает.

    Q: Есть база на sql server. В ней таблица. В таблице есть поле — регион. Созданы представления, отдельно для каждого региона, в которых в выражении where указан фильтр по региону. Созданы пользователи в sql server для каждого региона. Для каждого представление настроен доступ только для определенного пользователя (этого региона).
    Нужно предоставить разрозненный доступ пользователям на одинаковых дашбордах

    Подскажите, как реализовать такой дифференцированный доступ через qlik server?
    Возможно, существует более простой и технически правильный способ предоставить разрозненный доступ пользователям?

    A: Самое первое что приходит на ум, это использовать «QVuser( )».
    То есть, допустим есть 5 регионов. В QlikView создаем 5 пользователей и 5 листов (sheet) для каждого региона. В свойствах первого листа (sheet_01) в (General —> Conditional) пишем условие, что данный лист (sheet_01) виден только для пользователя user_01 и все расчеты на данном листе «урезаны» для региона, который нужен пользователю user_01. По аналогии делаем sheet_02, на котором данные для пользователя user_02 и т.д.

    Q: Прошу помощи профессионалов и заранее извиняюсь за глупый вопрос.
    Есть таблица Торговые точки с полями Агент и Адрес, пример:
    Торговые точки:
    Агент Адрес
    Иванов г.Москва
    Петров г.Волгоград
    Сидоров г.Владимир

    Доступ к файлу ограничен через поле: NTNAME
    Как разграничить доступ чтобы один USER видел Адреса по агенту Иванов, другой другого….
    Если использовать ограничение доступа по USERID и PASSWORD я использую следующий:
    Section Access;
    LOAD * INLINE [
    ACCESS, USERID, PASSWORD
    USER, 1, 1
    USER, 2, 2
    ];
    Section Application;
    LOAD * INLINE [
    USERID, Агент
    1, Иванов
    2, Петров
    ];
    И все видят адреса по своему Агенту, а если прописать по другому, то файл вообще не откроется:
    Section Access;
    LOAD * INLINE [
    ACCESS, NTNAME
    USER, 1
    ];
    Section Application;
    LOAD * INLINE [
    NTNAME, Агент
    1, Иванов
    ];

    Читать еще:  Поле мемо в access как сделать

    A: Вот рабочий пример из справочного руководства (ошибка в строке RechNo(), правится легко )
    Код:
    section access;

    load * inline [
    ACCESS, USERID,REDUCTION, OMIT
    ADMIN, ADMIN,*,
    USER, A,1
    USER, B, 2,NUM
    USER, C, 3, ALPHA
    ];

    section application;
    T1:
    load *,
    NUM AS REDUCTION;
    load
    Chr(RecNo()+ord(‘A’)-1) AS ALPHA,
    RecNo() AS NUM
    AUTOGENERATE 3;

    Q: Добрый день! подскажите пожалуйста кто сталкивался, можно ли сделать ограниченный доступ к текстовому блоку скрипта qlikview? т.е. например в скрипте есть текст:

    текст 1(описывающий таблицу клиенты)
    текст 2(описывающий таблицу счета):

    Можно ли реализовать следующее: Администратор1, имеющий доступ к редактированию скрипта, может изменять текст 1, но не может изменять текст 2 ?
    A:Несколько необычно, чтобы администратору что-либо запрещалось.
    Речь идет о локальной версии?
    Из средств, ограничивающих доступ, есть область скрытого скрипта.
    Есть загрузка скрипта из текстовых файлов, в этом случае, если нет доступа к редактированию файла (qvs/txt) то пользователь, редактирующий главный скрипт, сможет открыть на просмотр и загрузить скрипт, но не сможет внести изменения.
    Это что касается Вашего вопроса.
    Также, рекомендую почитать в руководстве главу 29 «Безопасность» и попрактиковаться с Section Access .

    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.

    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.

    Читать еще:  Как сделать подтаблицу в access?

    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