Comments 10
А можете привести пример IAM систем к которым можно писать коннекторы на скриптовых языках ( perl, python)?
Вроде было что-то в OpenIAM, но на Groovy: Developing a Provisioning Connector
IBM Tivoli Identity Manager, например.
PS: В Windows мире чаще используется VB или PowerShell.
PS: В Windows мире чаще используется VB или PowerShell.
В статье упор сделан на Identity Management, тоесть на решения IDM. IAM в рамках одного сервера — редкость и гораздо более обширная тема, так как Access Management уже совсем другая кухня, и по идее, IDM должен иметь коннектор к AM системе для провижонинга и даже может использовать ее для контроля доступа к себе(Oracle OIM и OAM).
Как раз у Oracle исключительный случай.
Если говорить о сценарии приема нового сотрудника на работу, большинство IdM-систем умеют из коробки не только создать учетку в AD, но и добавить в группы — чем не Access Management?
Если говорить о сценарии приема нового сотрудника на работу, большинство IdM-систем умеют из коробки не только создать учетку в AD, но и добавить в группы — чем не Access Management?
Это вообще provisioning, Access Management — это принятие решения о доступе пользователя к тому или иному ресурсу, на основалии определенных правил и/или политик. Та же сама адаптивная аутентификация в OpenSSO. Системы класса IDM таким не занимаются. Они могут добавить пользователя в группу, но не могут сказать авторизован ли он для доступа к чему-то.
Откуда такое определение?
В большинстве источников IdM=IAM, UAP (provisioning) и IAG (контроль) — это «области знаний» внутри. Конкретный продукт или набор продуктов может уметь работать с доступом, а может и не уметь.
Я бы отнес к Access Management все операции с доступом, в том числе и provisioning доступа через группы — классический UAP.
Обычно правила и политики (контроль доступа) относят к IAG — об этом я написал в статье.
В большинстве источников IdM=IAM, UAP (provisioning) и IAG (контроль) — это «области знаний» внутри. Конкретный продукт или набор продуктов может уметь работать с доступом, а может и не уметь.
Я бы отнес к Access Management все операции с доступом, в том числе и provisioning доступа через группы — классический UAP.
Обычно правила и политики (контроль доступа) относят к IAG — об этом я написал в статье.
Это у вас в Quest назвали Access Management — Access Government) Добавление пользователя куда либо — обычный provisioning. У систем разная зона ответственности. С точки зрения деплоймента я бы не стал мешать системы управления доступом и системы отвечающие за self-service и provisioning в одном, так как это резко ограничивает возможные варианты внедрения.
Вы правильно сказали что IAM, IM, AM — области знаний. Но не надо их смешивать в одно, хоть они и работают в связке.
В целом было бы интересно посмотреть что у вас там делается и как вы разделяете задачи между продуктами, но в живую ни одного деплоймента не видел)) Пока только Oracle (OAM, OIM, OUD, OVD) да OpenSSO(OpenAM) + OpenIdm попадаются.
Вы правильно сказали что IAM, IM, AM — области знаний. Но не надо их смешивать в одно, хоть они и работают в связке.
В целом было бы интересно посмотреть что у вас там делается и как вы разделяете задачи между продуктами, но в живую ни одного деплоймента не видел)) Пока только Oracle (OAM, OIM, OUD, OVD) да OpenSSO(OpenAM) + OpenIdm попадаются.
Скрины у Вас из какой системы?
Sign up to leave a comment.
Какие задачи решают IAM системы?