Безопасность на уровне куба с использованием CustomData - PullRequest
Новая
       4

Безопасность на уровне куба с использованием CustomData

1 голос
/ 21 сентября 2011

Я новичок в SSAS, но меня попросили создать продукт с тремя кубами (пока что назовите их «A», «B» и «C»). Другая группа создает веб-части «A», «B» и «C» для доступа к этим кубам, и существуют роли «A», «B» и «C», которые определяют, какие пользователи могут получить доступ к кубам.

Моя проблема

Не гарантируется, что клиентский сервер SSAS находится в том же ящике, что и сервер SharePoint, поэтому у нас возникли проблемы с входом пользователя в систему SharePoint, а SP не выдавал себя за этого пользователя. Мы не можем гарантировать, что клиент разрешит нам установить проверку подлинности Kerberos или настроить SharePoint в качестве доверенного сайта, поэтому мы исследуем использование переменной CustomData для передачи идентификатора текущего пользователя.

Вопрос

Однако это приводит к вопросу о реализации безопасности доступа к кубу. Я

  1. Создать роль «SharePoint», которая принимает переменную CustomData, а затем либо предоставляет (через безопасность измерений?) Доступ к кубу (через все элементы измерения?)
  2. Создайте «куб безопасности», инкапсулирующий, у кого есть доступ к чему, и пусть веб-часть определяет, должен ли он «иметь» доступ,
  3. Вместо того, чтобы сохранять безопасность в форме пользователя / куба в таблице фактов, сохраняйте ее в форме пользователя / членов формы измерения (мне это не нравится, поскольку входящие данные находятся в форме пользователя / куба и расширяются это из членов измерения создает «ненужные» строки).

Дополнительная справочная информация

В настоящее время безопасность организована в виде таблицы фактов

| UserKey | SecurityItemKey |

, где Personkey ссылается на таблицу пользователей, а SecurityItemKey в настоящее время ссылается на список кубов (у нас есть таблица элементов безопасности, чтобы пользователи могли легко перечислять свои параметры и проверять, что они хотят).

В настоящее время я пробую вариант 1. выше, но когда я создаю MDX в соответствии с 

Exists(
  {[Security Item].[Security Item Key].&[235]},
    StrToSet("{([User].[User].[User].[" +
            CustomData() + "])}"
    ),
    'Fact Security'
    )

для безопасности измерения, я получаю ошибки в строках «Атрибут« {1} »в измерении« {2} »имеет недопустимое сгенерированное выражение безопасности измерения». Я использую тот же MDX в запросе, и это нормально.

Обратите внимание, что на измерение, к которому я добавляю это, нет ссылки в MDX, и я волнуюсь, что это является частью проблемы, но я пока не могу найти ничего, говорящего "да" или "нет".

Итак, что я делаю не так, и что вы рекомендуете делать по-другому?

1 Ответ

1 голос
/ 28 сентября 2011

Продолжайте - вот что мы сделали:

Вместо того, чтобы принудительно обеспечивать безопасность данных измерений для защиты всего куба, мы создали куб «Безопасность», который запрашивается процессом SharePoint, который затем отвечает за предоставление или отказ в доступе. Только пользователь SharePoint имеет доступ к этой роли с доступом ко всем кубам.

Обычным пользователям по-прежнему предоставляется доступ к каждому кубу отдельно через отдельные роли.

Итак, проблема безопасности состоит в том, что существует одна роль с доступом ко всем, но мы чувствовали, что это приемлемо, и просто нужно полагать, что члены роли назначены соответствующим образом.

...