С введением в бизнес-аналитику самообслуживания появилось разделение пользователей на различных уровнях, оно касается того, как люди проводят самообслуживание и до какой меры. Есть разные типы пользователей, которые отличаются друг от друга уровнем заинтересованности, техническим опытом и возможностями работы с данными. Хотя каждый пользователь – это фактически уникальный случай самообслуживания, тем не менее пользовательскую базу можно разделить на четыре группы. В этой статье мы рассмотрим четыре типа пользователей в модели самообслуживания в бизнес-аналитике.
Оытные пользователи или «чемпионы» данных
Опытные пользователи – это самые технически продвинутые бизнес-пользователи, которые проявляют большой интерес к самостоятельной бизнес-аналитике. Они сами разрабатывают и создают информационные панели и знают, как загружать данные, обработать их для создания логической модели. Они, как правило, самообучаются и имеют гибридный набор навыков, обычно это смесь знаний в области коммерции и передовых технических навыков. Эта группа пользователей часто недовольна существующими решениями в области отчетности или бизнес-аналитики и считает, что ИТ-специалисты не смогут предоставить нужный функционал. В результате, особенно в прошлом, они удаляли дампы данных из ИТ-продуктов и создавали собственные информационные панели в Excel, используя для приложений технические навыки, такие как VBA и Visual Basic.
134 Бизнес процессы Пользователи
Как правило, им нравится участвовать в процессе разработки, но они не могут сами заниматься ею из-за действующих корпоративных правил и строгого отделения ИТ от бизнеса (традиция старой школы). Самостоятельная бизнес-аналитика ориентирована, в частности, на эту группу, и идентификация таких пользователей – это ключ к внедрению решений в рамках организации.
В устоявшейся среде самообслуживания опытные пользователи обычно участвуют в комитетах, вращаются в околотехнической среде, и представляют интересы бизнеса. Они также разрабатывают большую часть первых версий приложений, затем в рамках естественно развивающегося процесса эти наработки передаются более опытным ИТ-специалистам для доработки и оптимизации.
Опытные пользователи отстаивают технологию самообслуживания в бизнес-аналитике и часто не просто демонстрируют идеи и информацию, которые они смогли извлечь из своих данных, но и показывают эффективность и своевременность такого решения. В то же время они служат отправной точкой контакта для других пользователей и клиентов, когда дело доходит до вопросов приложений и информационных панелей. Иногда они также участвуют в качестве технических консультантов по вопросу о целесообразности реализации других проектов с использованием той же технологии.
В среде бизнес-аналитики с самообслуживанием можно с уверенностью сказать, что эти опытные пользователи являются основой для дальнейшего успешного внедрения.
Бизнес-пользователи или визуализаторы данных
Под бизнес-пользователями здесь имеются в виду обычные пользователи систем аналитики, главная цель которых – извлечь пользу из данных, которые они представляют. Они представляют группу лиц, заинтересованных в проведении анализа и обнаружении данных, чтобы лучше понять свой бизнес и принимать более взвешенные решения. Презентация и простота использования приложения являются ключевыми для этого типа пользователей, они меньше заинтересованы в построении новой архитектуры аналитики. При этом некоторые формы создания новых диаграмм и загрузки данных все еще могут быть интересными для них, хотя и на очень базовом уровне.
Как адаптировать цифровой продукт под китайского пользователя?
Для них самыми важными факторами является своевременность, актуальность данных и удобство использования. Это те, кто «разрезает» и «нарезает» данные и углубляется в измерения, они хотят просто щелкнуть мышью в приложении, чтобы получить ценную информацию. Обычно все пользователи этой группы принадлежат к одному отделу и у них есть опытные пользователи, которые наблюдают за ними как в отношении вопросов, так и в получении отзывов о том, как можно еще улучшить информационную панель. Их взаимодействие с ИТ-отделом в основном ограничивается запросом доступа и устранением непредвиденных технических ошибок.
Потребители или читатели данных
Простые потребители чаще всего составляют самую большую группу пользователей продуктов самообслуживания в бизнес-аналитике. Это – конечные получатели всех сгенерированных идей и аналитики данных и, как правило, их интересует только «дистиллированная» готовая информация, которую они получают в удобной форме. Обычно это те пользователи, которые довольствуются отчетом, в цифровом или печатном виде, в котором на нескольких страницах описаны основные моменты, и не требуется никакого взаимодействия с их стороны. Кроме того, они более чувствительны к своевременности и доступности своих отчетов.
Хотя, как правило, это – самая большая часть аудитории, данная группа в то же время в наименьшей степени использует возможности самообслуживания в бизнес-аналитике. Это создает проблемы с лицензированием, поскольку эти пользователи не используют всех преимуществ предлагаемых функций, они платят полную сумму, чтобы получить доступ к отчетам. Поэтому этому типу пользователей редко дают ключи для входа в систему или вообще не дают им доступ к платформе самообслуживания в бизнес-аналитике, а лишь ограниченную необходимую информацию в печатном (цифровом) формате или в подготовленных презентациях.
ИТ-специалисты или контролеры данных
ИТ представляет группу технических пользователей, которые находятся на заднем плане, они разрабатывают и управляют структурой, в которой работает самообслуживание BI-продукта. Они – основа для внедрения среды, ИТ обеспечивает правильную настройку для различных вариантов использования, по требованиям описанных выше групп пользователей.
В то же время они обеспечивают наличие политики безопасности и поддерживают ее, а также внедряют структуру управления для внедрения контроля качества данных и передовых методов. По сути, они несут ответственность за опытных пользователей и помогают им в решении технических вопросов, но в то же время обеспечивают единообразие терминов и определений, а также внешнего вида и поддержки во всех приложениях.
При самообслуживании в BI, ИТ играет меньшую роль в фактической разработке информационных панелей, и занимает скорее позицию наставника, проводя обучения и консультации по применению лучших практик. Работая в тесном сотрудничестве с опытными пользователями, ИТ-отдел также предоставляет пользователям техническую поддержку и поддерживает связь с инфраструктурой, чтобы обеспечить соответствие серверной инфраструктуры ее назначению и поддерживая работоспособность для обслуживания пользователей. Эта группа также занимается обновлением платформы там, где это необходимо, и внедрение в нее дополнительных функций, если и когда они доступны.
Объединяем их
В типичной корпоративной среде можно выделить описанные выше четыре группы; однако это не означает, что на практике не встречаются гибридные группы или меньшее количество групп пользователей. То, как организация адаптирует самообслуживание в аналитике данных в зависимости от имеющихся навыков, конкурирующих устоявшихся решений, культуры и стремления к новым технологиям – эволюционный процесс.
Обычно все начинается с того, что ИТ-специалисты становятся первыми пользователями в недавно внедренной среде самообслуживания, они не только настраивают инфраструктуру, но и разрабатывают в ней первые приложения для клиентов. Затем к ним за помощью могут обратиться опытные пользователи; как правило, они сами являются бизнес-спонсорами, часто являются сторонниками аналитики данных, изменяя приложение на свой вкус и продвигая его среди пользователей. База пользователей появляется с успехом решения, в котором аналитика интегрирована в их бизнес как обычный процесс.
Последняя группа, потребители, в основном представляет собой последний тип созданной группы пользователей, которая чаще всего не имеет фактического доступа к самой платформе, а скорее получает распечатки, сводки по электронной почте со скриншотами или презентации PowerPoint. Из-за стоимости лицензирования и размера потребительской аудитории предоставить им доступ к платформе самообслуживания не так легко; следовательно, в большинстве случаев автоматизированный и оптимизированный процесс печати PDF-файлов является самым логичным решением для этой группы пользователей.
В то же время объем внедряемой системы также определяет количество различных групп пользователей. В среде маленькой компании это будут в основном опытные пользователи и ИТ-специалисты, которые будут использовать самообслуживание. Это значительно упрощает подход, и упрощает настройку.
Источник: biconsult.ru
Типы пользователей на уровне учётной записи
Дополнительные сведения о планах и их возможностях см. на странице «Расценки».
Типы пользователей на уровне учётной записи
PLANS
- Business
- Enterprise
For more information about plan types and included capabilities, see the Smartsheet Plans page.
Тип пользователя определяет, какие действия с учётной записью Smartsheet вам доступны.
ПРИМЕЧАНИЕ. Тип пользователя НЕ связан с доступом к таблицам. Доступные действия с таблицей определяет ваш уровень разрешений совместного доступа (наблюдатель, редактор или администратор), который может меняться в зависимости от конкретной таблицы. Подробные сведения об уровнях разрешений см. в статье Уровни прав общего доступа.
Функции, описанные здесь, недоступны для плана «Профессиональный». Не знаете, какой у вас план? См. статью Как узнать свой план и тип пользователя в Smartsheet.
Системный администратор
Системный администратор отвечает за управление пользователями и настраивает параметры для всех пользователей в рамках учётной записи.
Системному администратору НЕ нужна лицензия.
Администратор группы
Администратор группы может создавать группы и управлять ими (подробные сведения о группах см. в статье Как использовать группы контактов в Smartsheet и управлять ими) на основании контактов из списка контактов Smartsheet (подробные сведения см. в статье Список контактов). Любой пользователь в рамках учётной записи может предоставлять доступ к информации из групп, созданных администратором, и добавлять в них новые сведения.
Администратору группы нужна лицензия.
Наблюдатель ресурсов
Для новых учётных записей Smartsheet недоступна старая версия управления ресурсами. Если вы используете старую версию управления ресурсами, ваши данные не изменятся и вы по-прежнему будете иметь доступ к своим представлениям ресурсов.
При этом всем новым пользователям доступно решение Resource Management от Smartsheet; подробнее см. здесь.
Наблюдатели ресурсов в старой версии управления ресурсами могут отслеживать распределение (в процентах) для всех пользователей учётной записи во всех таблицах. Наблюдатель ресурсов должен быть лицензированным пользователем и иметь учётную запись плана «Бизнес» или «Корпоративный». (Дополнительную информацию см. в статье Представления ресурсов).
Наблюдателю ресурсов нужна лицензия, однако он может отслеживать любых пользователей учётной записи (как лицензированных, так и нелицензированных) в качестве ресурсов.
Лицензированный пользователь
Количество лицензированных пользователей, доступное для вашей учётной записи, зависит от её типа. Дополнительные сведения о максимальном и минимальном количестве пользователей, доступном для разных планов, см. на странице Расценки.
- Любой системный администратор может выдавать лицензии с помощью формы Управление пользователями.
- При использовании 30-дневной пробной версии вы также считаетесь лицензированным пользователем.
Для создания и администрирования процессов, программ и проектов Smartsheet, а также для управления и владения ими нужна платная лицензия. Например, лицензия требуется для следующих действий:
- создание таблиц и шаблонов и владение ими (количество таблиц, которые вы можете создать, зависит от вашего плана);
- создание отчётов, владение и управление ими;
- создание рабочих пространств;
- публикация таблиц, отчётов и панелей мониторинга;
- вставка и удаление столбцов*;
- изменение свойств столбца*;
- скрытие/демонстрация столбцов*;
- создание и изменение форм*;
- блокировка столбцов и строк*;
- создание и редактирование запросов на изменение, автоматизированных действий и рабочих процессов;
- создание напоминаний на уровне таблицы и напоминаний на уровне строк для других пользователей;
- запросы на резервное копирование таблиц;
- получение прав наблюдателя ресурсов или администратора группы в рамках плана «Корпоративный» или «Бизнес»;
- просмотр журнала действий;
- создание, изменение и удаление общих фильтров;
- создание правил условного форматирования;
- отправка строк;
- изменение параметров проекта.
* Для этих действий необходимо иметь доступ к таблице с правами владельца или администратора.
Пользователь бесплатной версии
Пользователи бесплатной версии (нелицензированные пользователи и соавторы с бесплатным доступом) также могут вносить вклад в общую работу. Пользователи бесплатной версии могут просматривать, редактировать и изменять таблицы и отчёты в рамках платформы Smartsheet. Для создания и администрирования процессов, программ и проектов Smartsheet, а также для управления и владения ими нужна платная лицензия. Дополнительные сведения о пользователях бесплатной версии см. в статье Функции, доступные пользователям бесплатной версии.
Если пользователи бесплатной версии получают доступ к таблице с правами администратора, они не смогут создавать формы в рамках таблицы и управлять ими, а также вставлять, переименовывать, удалять, скрывать/показывать и перемещать столбцы, а также изменять их параметры. Эти функции доступны только владельцам таблицы и лицензированным пользователям с правами администратора.
Полный список разрешений, доступных лицензированным пользователям, см. выше в разделе Лицензированный пользователь.
Нелицензированный пользователь
Нелицензированные пользователи имеют учётную запись в рамках плана «Бизнес» или «Корпоративный», но не могут создавать таблицы или быть их владельцами. На нелицензированных пользователей не распространяется ограничение по количеству пользователей в рамках учётной записи.
Нелицензированные пользователи в рамках планов «Профессиональный», «Бизнес» и «Корпоративный» могут запросить лицензию, нажав на кнопку «Повысить уровень» в верхней части экрана. На время ожидания лицензии им будет предоставлен 30-дневный пробный план, который позволит создавать таблицы и владеть ими. Подробнее о пробных планах и о том, что происходит, если администратор не утверждает запрос на получение лицензии.
Наблюдатели ресурсов могут отслеживать назначенные таким пользователям задачи, а системные администраторы — управлять их учётными записями, как описано выше. Нелицензированные пользователи могут получить доступ к таблицам в качестве наблюдателей (с правами только для чтения), редакторов (с возможностью изменять данные в ячейках) и администраторов (с возможностью управления таблицей). Кроме того, такие пользователи могут даже повторно предоставлять доступ к таблицам, если это позволяет их уровень доступа.
Чтобы добавить нелицензированного пользователя к учётной записи плана «Бизнес» или «Корпоративный», снимите флажок Лицензированный пользователь, высылая приглашение. Подробнее см. в статье Центр администрирования: добавление, изменение и удаление пользователей.
Соавторство с бесплатным доступом
Соавторы с бесплатным доступом могут получить доступ к неограниченному количеству таблиц, но не могут создавать собственные таблицы. Они могут получить доступ к таблицам в качестве наблюдателей (с правами только для чтения), редакторов (с возможностью изменять данные в ячейках) и администраторов (с возможностью управления таблицей). Кроме того, такие пользователи могут даже повторно предоставлять доступ к таблицам, если это позволяет их уровень доступа.
Типы пользователей, специфичные для соединителей
Если ваша организация приобрела соединитель Smartsheet for Jira или Smartsheet for Salesforce, любой системный администратор может контролировать, кто имеет доступ к тому или иному соединителю.
Типы пользователей, описанные ниже, доступны только тем, кто приобрёл соединитель Salesforce или Jira. (Дополнительная информация о соединителях представлена здесь.)
Типы пользователей Smartsheet for Jira
Системные администраторы Smartsheet могут контролировать уровень доступа пользователей к соединителю Smartsheet for Jira. Дополнительную информацию об этом соединителе см. в статье Smartsheet for Jira.
Чтобы использовать соединитель Smartsheet for Jira, необходимо быть лицензированным пользователем Smartsheet и иметь учётную запись Jira.
Администратор соединителя для Jira
Администраторы соединителя для Jira назначаются системным администратором Smartsheet. Они занимаются установкой и настройкой соединителя Smartsheet для Jira.
Администратор соединителя для Jira может выполнять следующие действия:
- настраивать соединитель Smartsheet для Jira путём подключения Jira к Smartsheet (если такой пользователь также является администратором в приложении Jira). Дополнительные сведения см. в статье Соединитель Smartsheet for Jira;
- присваивать статус пользователей Jira другим пользователям учётной записи Smartsheet;
- устранять неполадки в рабочих процессах, созданных пользователями Jira, отключая их.
Пользователь соединителя для Jira
Пользователи соединителя Smartsheet для Jira могут создавать рабочие процессы с помощью Smartsheet для Jira, чтобы синхронизировать информацию между приложениями.
Дополнительные сведения о создании рабочих процессов с помощью этого соединителя см. в статье Smartsheet для Jira: создание и изменение рабочих процессов синхронизации.
Типы пользователей Smartsheet для Salesforce
Системные администраторы Smartsheet могут контролировать уровень доступа пользователей к соединителю Smartsheet для Salesforce. Подробные сведения об этом соединителе см. в статье Smartsheet для Salesforce
Чтобы использовать соединитель Smartsheet для Salesforce, необходимо быть лицензированным пользователем Smartsheet и иметь учётную запись Salesforce.
Администратор соединителя для Salesforce
Администраторы соединителя для Salesforce назначаются системным администратором Smartsheet и выполняют настройку соединителя.
Администраторы соединителя для Salesforce могут выполнять следующие действия:
- настраивать Smartsheet для Salesforce, подключая Salesforce к Smartsheet (для этого необходимо быть администратором в Salesforce). Дополнительную информацию об этом см. в статье Соединитель Smartsheet для Salesforce: настройка администратором;
- присваивать статус пользователей Salesforce другим пользователям учётной записи Smartsheet;
- устранять неполадки в рабочих процессах, созданных пользователями соединителя для Salesforce, отключая их.
Пользователь соединителя для Salesforce
Пользователи соединителя Smartsheet для Salesforce могут создавать рабочие процессы с помощью Smartsheet для Salesforce, чтобы синхронизировать информацию между приложениями.
Подробную информацию о создании рабочих процессов с помощью этого соединителя см. в статье Соединитель Smartsheet для Salesforce: синхронизация данных Smartsheet с Salesforce.
Связанный контент
Просмотр и изменение данных учётной записи, плана или платёжных данных
Как повысить уровень плана, изменить план, изменить платёжные данные, просмотреть уведомления о получении оплаты и историю оплаты.
Источник: help.smartsheet.com
Никто (почти) не знает, что такое авторизация
За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.
Что же это такое?
Процитируем Википедию:
Авториза́ция (англ. authorization «разрешение; уполномочивание») — предоставление определенному лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
С точки зрения любой информационной системы это процесс принятия решения о предоставлении доступа субъекту на выполнение операции на основании каких-либо знаний о субъекте. К этому моменту субъект, как правило, уже должен быть идентифицирован (мы должны знать, кто он) и аутентифицирован (подтверждена его идентичность).
Реализация авторизации при разработке корпоративной информационной системы или продукта, ориентированного на корпоративный сектор — очень сложная и ответственная задача, которой часто уделяется недостаточное внимание на этапе проектирования и первичном этапе разработки, что в будущем ведет к «костыльной» реализации.
Проблематика
Давайте разберемся, какие требования к авторизации встречаются, и почему их крайне важно учитывать изначально при проектировании системы, а не откладывать на будущее. Источников требований к авторизации в корпоративной информационной системе, как правило, два — это бизнес и информационная безопасность. В общем случае бизнес хочет хранить секреты в тайне и предоставлять полномочия пользователям в соответствии с их функцией в бизнес-процессе, а безопасность хочет обеспечить минимальную достаточность полномочий каждому пользователю и аудировать доступ.
Возьмем для примера гипотетическую систему согласования договоров крупной компании, типовой кровавый энтерпрайз. Практически наверняка возникнут следующие требования к авторизации от бизнеса:
- Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
- Автор договора должен видеть его на всех этапах.
- Создавать договор имеет право пользователь с грейдом не ниже 10.
- Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
- Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
- Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
- Руководство и секретариат головного офиса должны видеть документы всех филиалов.
- Пользователь, создавший договор, не должен иметь права его завизировать.
- Знать, кто имеет доступ к конкретному договору.
- Знать, кто имел доступ к конкретному договору в заданный момент времени.
- Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.
Итак, обозначим, почему эти требования проблемные:
- Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
- Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
- Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики.
- Они влияют на производительность.
Пути решения
Решить данную задачу нам помогают разработанные модели управления доступом:
MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.
DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.
RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.
АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).
Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.
Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:
| 1 | Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе | Тут напрашивается ACL, поскольку определить отношение пользователя к бизнес-процессу достаточно сложно, не записывая его в какой-то список в момент вовлечения. Это будет оптимальным решением с точки зрения производительности чтения относительно реализации с помощью политик. |
| 2 | Автор договора должен видеть его на всех этапах | Требование может быть реализовано обоими механизмами, но оптимальным я считаю ACL, поскольку в этом случае будет проще реализовать требование №3 от ИБ. |
| 3 | Создавать договор имеет право пользователь с грейдом не ниже 10 | Это политика (PBAC), без вариантов |
| 4 | Визирующий должен видеть договор начиная с поступления к нему на этап и далее | ACL будет оптимален |
| 5 | Руководители подразделений должны видеть договоры своих подразделений вниз по иерархии | Замечательная задача для PBAC, но его применение может снизить производительность чтения, а требования 1 и 2 от ИБ потребуют дополнительных усилий, поэтому стоит подумать над реализацией. |
| 6 | Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования | PBAC справится отлично |
| 7 | Руководство и секретариат головного офиса должны видеть документы всех филиалов | PBAC, с теми же ограничениями что и в п. 5 |
| 8 | Пользователь, создавший договор, не должен иметь права его завизировать | Это требование можно было бы закрыть с помощью PBAC, однако так делать не стоит. Это то самое место, где авторизация вступает в конфликт с бизнес-логикой, и если происходит такая ситуация, ответственность стоит отдать бизнес-логике. |
Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:
| 1 | Знать, кто имеет доступ к конкретному договору | Общий журнал для ACL и PBAC |
| 2 | Знать, кто имел доступ к конкретному договору в заданный момент времени | Общий журнал для ACL и PBAC |
| 3 | Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей | ACL |
Итого
Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований.
