Цитата:
Сообщение от
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.
А вот с воркфлоу идея и правда интересная, но требует больше усилий для решения вопроса, чем просто сделать двухшаговую аутентификацию:
- обосновать ключевым пользователям/безопасникам необходимость воркфлоу и плюшки от его использования
- научить сотрудников работать с воркфлоу
- настроить/поддерживать воркфлоу
- разработать/настроить воркфлоу для конкретных бизнес-процесов (скорее всего нужных не будет)
Учитывая все вышесказанное, предлагаю: а) ждать вводных от топикстартера б) пока информации нет, обсуждать в ключе решения конкретной технической задачи – как сделать второй шаг авторизации, если предполагаем ,что первый шаг авторизации каким-то образом уже выполнен за кадром.