Как внедрить много-факторную аутентификацию

[gl00mie]

Цитата:

Сообщение от ndabbot

Я не разработчик или администратор Dynamics AX.
Мне нужно узнать, возможно ли настроить много-факторную аутентификацию (пароль ну и к примеру СМС токен, единовременный пароль, софт токен) непосредственно для Dynamics AХ 2012.

В стандарте так сделать нельзя, потому что из Dynamics AX, начиная с версии 4.0 (т.е. 2 версии назад), выкинули собственный механизм аутентификации, привязав всё к AD с использованием SSO.

Цитата:

Сообщение от ndabbot

Клиент хочет что бы его менеджеры, находясь в офисе или вне его, заходя через клиент или через веб портал, вводили не только пароль, но и дополнительный токен.

Тут нужно абстрагироваться от Аксапты, см., например, Authenticate Clients Using Smart Cards (для IIS и того же портала).

Цитата:

Сообщение от ndabbot

Насколько я понял у клиента пользователи входят в Dynamics с отдельными аккаунтами, не интегрированными в Active Directory

Это как?..

Цитата:

Сообщение от ndabbot

по какой то причине компания не хочет использовать технологию единого входа (SSO).

Тогда они не того вендора выбрали

Цитата:

Сообщение от ndabbot

Видение клиента состоит в том, что он хочет заставить менеджеров вводить пароль и токен при авторизации каких либо транзакций, иначе они просто отдают пароль секретарям.

Выходит, дело не в SSO, не в использовании AD для аутентификации пользователей, а в некоторых бизнес-процессах, требующих одобрения менеджерами тех или иных документов/действий. И сейчас просто менеджерам неудобно это делать в Аксапте самостоятельно, потому они и передают свои учетные данные посторонним людям, чтобы те выполняли одобрение за них.
Если так, то идти, мне кажется, нужно в противоположном направлении: не пытаться усложнить менеджерам вход в Аксапту, а напротив, упростить им одобрение тех или иных документов/действий в системе. Это решается иначе, например, через функционал Workflow: в 2012-й куча бизнес-процессов может быть штатно привязана к Workflow, выполняющемуся на базе Windows Workflow Foundation (WF). WF позволяет "выходить за рамки" системы, в частности, уведомление о том, что пользователю передан на одобрение тот или иной документ или действие, может приходить в т.ч. на электронную почту, можно прямо в том же Outlook "проголосовать" - и ответ вернется в WF, повлияв на дальнейшее выполнение бизнес-процесса в Аксапте. См. также Workflow examples.
А секретарям можно просто объяснить, что "авторизация транзакций" за менеджеров не только не входит в их обязанности, но и может преследоваться как уголовное преступление (п.2 статьи 272 УК РФ, штраф до 300 тыщ или лишение свободы на срок до 5-и лет).

[Kabardian]

Цитата:

Сообщение от gl00mie

В стандарте так сделать нельзя, потому что из Dynamics AX, начиная с версии 4.0 (т.е. 2 версии назад), выкинули собственный механизм аутентификации, привязав всё к AD с использованием SSO.Тут нужно абстрагироваться от Аксапты

Ну, топик был не про авторизацию для первичного входа в систему (клиент/портал), а про дополнительную авторизацию при выполнении важных операций. А такой механиз в Аксапте из коробки есть - это электронная цифровая подпись, работает так – пользователь входит в Аксапту с обычной учетной записью, выполняет обычные операции, и, если для определенной операции настроено подтверждение через электронную цифровую подпись, то система запрашивает электронную подпись.

Другой вопрос, насколько оправдано это. Подозреваю, что в компании сложилась практика когда менеджерам часть работы могут помогать выполнять секретари, и ничего плохого в этом нет - менеджер при этом может отвлекаться только на подтверждение действительно важных операций, которые как я понял из топика и требуется подтверждать. Проведите аналогию, например, с розничной торговлей и ролями кассир, старший кассир, если даже взять сценарии из стандартной коробки AX 2009/2012 Retail - там кассир по-сути операционист и выплоняет 95% работы, кассиров много и они могут ошибаться, тогда например, сброс чека может выполнить только старший кассир со своим паролем. Здесь скорее всего, аналогичная ситауция, и нужно придумать работающее решение. Если ситуация именно такая, то первый вопрос приходящий на ум - почему у секретарей нет своего логина и своих прав доступа? Возможно, ограниченное количество рабочих мест и за одним рабочим местом работают сразу несколько сотрудников поочередно и т. п. В общем, фантазировать можно много на эту тему.. и до тех пор пока не будет больше вводной информации о том как это сейчас работают у клиента, и почему именно так от топикстартера, ситуация совсем непонятная.

Цитата:

Сообщение от gl00mie

Выходит, дело не в SSO, не в использовании AD для аутентификации пользователей, а в некоторых бизнес-процессах, требующих одобрения менеджерами тех или иных документов/действий. И сейчас просто менеджерам неудобно это делать в Аксапте самостоятельно, потому они и передают свои учетные данные посторонним людям, чтобы те выполняли одобрение за них.

Выше уже прокомментировал это и бизнес-ситуация может быть любая.. и сейчас непонятно почему именно сложилась такая практика менеджер<>секретарь.

Цитата:

Сообщение от gl00mie

Если так, то идти, мне кажется, нужно в противоположном направлении: не пытаться усложнить менеджерам вход в Аксапту, а напротив, упростить им одобрение тех или иных документов/действий в системе. Это решается иначе, например, через функционал Workflow: в 2012-й куча бизнес-процессов может быть штатно привязана к Workflow, выполняющемуся на базе Windows Workflow Foundation (WF). WF позволяет "выходить за рамки" системы, в частности, уведомление о том, что пользователю передан на одобрение тот или иной документ или действие, может приходить в т.ч. на электронную почту, можно прямо в том же Outlook "проголосовать" - и ответ вернется в WF, повлияв на дальнейшее выполнение бизнес-процесса в Аксапте. См. также Workflow examples.

А вот с воркфлоу идея и правда интересная, но требует больше усилий для решения вопроса, чем просто сделать двухшаговую аутентификацию:

• обосновать ключевым пользователям/безопасникам необходимость воркфлоу и плюшки от его использования
• научить сотрудников работать с воркфлоу
• настроить/поддерживать воркфлоу
• разработать/настроить воркфлоу для конкретных бизнес-процесов (скорее всего нужных не будет)

Учитывая все вышесказанное, предлагаю: а) ждать вводных от топикстартера б) пока информации нет, обсуждать в ключе решения конкретной технической задачи – как сделать второй шаг авторизации, если предполагаем ,что первый шаг авторизации каким-то образом уже выполнен за кадром.