Short intro: here you can find article about some new features of Oracle Identity Cloud Service 19.3.3, which was released in Jan 2020 and was rolled out on most of the Oracle DC in Jan-Feb 2020…
Относительно недавно, как вы возможно уже знаете, вышел очередной релиз Oracle Identity Cloud Service 19.3.3 с достаточно важным новым функционалом. Сам продукт был выпущен в январе 2020, но был развернут в большинстве ЦОД Oracle в января-феврале 2020. В статье мы посмотрим на некоторые новые возможности (преимущественно связанные с функционалом предоставления доступа) и на то, что нас ждет в ближайшем будущем.
Как вы знаете, функционал Identity Management в части предоставления доступа (Provisioning) и контроля доступа (Access Management) в последнее время стал “commodity”, т.е. широко доступным, предлагаемым большим количеством вендоров за все меньшую стоимость. Также по сути дела стандартизирован функционал, что позволяет заказчику внедрить определенный набор стандартных возможностей за меньшее время и меньший бюджет с предъявлением все меньших требований компетенции сотрудников компаний-интеграторов, которые внедряют решение. Локальные вендоры, а также серьезно демпингующие глобальные вендоры, распространение open-source решений, все это заставляет пионеров в этой индустрии искать новые области применения своих наработок. Например, в области CIAM (Consumer Identity & Access Management), а также в области облачного Identity Management.
Oracle не является исключением. Облачная стратегия Oracle, а также обострившаяся конкуренция на рынке IDM решений привела к тому, что помимо уже хорошо известных и зарекомендовавших себя на рынке онпрем решений Identity Governance и Access Management, появился новый облачный сервис Identity Cloud Service (IDCS), который в зависимости от требований заказчика может полностью заменять или дополнять онпрем решения. Как онпрем, так и облачные сервисы позволяют управлять доступом в онпрем и облачные приложения, и онпрем и облачный вариант имеют свои преимущества и недостатки. Так, онпрем продукты позволяют выполнить намного более гибкую настройку, позволяют осуществить более глубокую кастомизацию, адоптировав продукт под бизнес процессы предприятия. Тогда как облачный сервис позволяет меньше кастомизации, но существенно более прост при внедрении и обслуживании, внедрять облачный IDCS дешевле и проще (если вы готовы, разумеется, поступиться уникальностью своих бизнес процессов). Кроме того, в большинстве случаев заказчику нет необходимости заботиться об обновлении, что часто является камнем преткновения для онпрем решений, оно выполняется облачным провайдером (в данном случае – Oracle). Чтобы взять лучшее из обеих продуктов, возможны различные гибридные схемы (с использованием IDCS Connector for Identity Manager, например), но это предмет отдельной статьи.
Преимуществом облачного решения является и его принципиально новая “cloud-native” архитектура на основе микросервисов. Вся функциональность строится “API-first” и изначально доступна через REST API, после чего к ней дописывается UI.
В релизе IDCS 19.3.3 был добавлен существенный функционал в части Identity Provisioning, позволяющий реализовать гибридные сценарии управления доступом, когда доступ в онпрем системы заказчика управляется через облачный сервис. Об этом функционале, а также о некоторых других новых возможностях, я бы хотел рассказать.
1. IDCS Provisioning Bridge. IDCS развивается в сторону гибридной схемы взаимодействия, и еще более года назад появился компонент App Gateway, позволяющий осуществлять SSO в онпрем приложения, транслируя SAML-assertion в HTTP-заголовки (например, так выполняется SSO в онпрем установку Oracle e-Business Suite, подробнее тут - https://blogs.oracle.com/cloudsecurity/how-to-simplify-sso-to-oracle-ebusiness-suite-in-just-3-steps). Сейчас появился компонент IDCS Provisioning Bridge, позволяющий выполнять provisioning в онпрем приложения. Этот компонент скачивается из раздела Downloads и скорее всего представляет собой ICF Connector Server (ICF – Identity Connector Framework, в котором разрабатываются современные коннекторы Oracle Identity Governance), дополненный возможностями REST-запросов в сторону IDCS с целью получения списка задач для выполнения.
Потенциально IDCS Provisioning Bridge может выполнять код любого ICF коннектора, однако каждый коннектор принимает на вход уникальный набор атрибутов, который должен быть задан в соответствующей форме приложения в IDCS. На сегодняшний день эти формы имеются для Oracle e-Business Suite и Oracle Internet Directory (см. экран ниже). В скором будущем будут поддерживаться другие приложения из списка коннекторов Oracle Identity Governance (https://www.oracle.com/middleware/technologies/identity-management/oim-connectors-downloads.html), а также будет добавлена возможность создания собственного коннектора с уникальным набором атрибутов.
Особенностью решения задачи предоставления доступа с помощью Provisioning Bridge является то, что необходимо открывать только outbound стандартные порты, взаимодействие с IDCS инициируется со стороны Provisioning Bridge по REST. Принципиально другое решение для управления доступом – Generic SCIM.
2. Generic SCIM. Как вы знаете, SCIM (System for Cross-Domain Identity Management, ex-Simple Cloud Identity Management), http://www.simplecloud.info/) – стандарт, определяющий набор REST-endpoint’ов для управления доступом, является наследником SPML / vCard. Текущая версия SCIM2.0 – стандарт IETF с 2012, определяющий следующие REST-endpoint’ы.
Create: POST https://example.com/{v}/{resource}
Read: GET https://example.com/{v}/{resource}/{id}
Replace: PUT https://example.com/{v}/{resource}/{id}
Delete: DELETE https://example.com/{v}/{resource}/{id}
Update: PATCH https://example.com/{v}/{resource}/{id}
Search: GET https://example.com/{v}/{resource}?filter={attribute}{op}{value}&sortBy={attributeName}&sortOrder={ascending|descending}
Bulk: POST https://example.com/{v}/Bulk
GET /ServiceProviderConfig
GET /ResourceTypes
GET /Schemas
В IDCS появилась возможность создания приложения, доступ в которое предоставляется посредством стандартных SCIM-совместимых REST вызовов. Причем эти приложения могут быть развернуты как онпрем, так и в облаке. Но в случае онпрем-разворачивания управление доступом происходит посредством inbound REST-вызовов из облака, что принципиально отличает это решение от решения по управлению доступом через IDCS Provisioning Bridge (думаю, в ближайшем будущем нас ждет Generic SCIM коннектор, работающий изнутри Provisioning Bridge’а, что решит вопрос inbound вызовов). Стоит ли упоминать, что в этом случае интегрируемое приложение должно поддерживать SCIM и быть доступно из внешней сети Oracle Cloud.
Чтобы добавить SCIM-совместимое приложение, необходимо выбрать из App Catalog’а одно из следующих приложений (они отличаются способом аутентификации).
Далее необходимо заполнить атрибуты расположения SCIM-совместимого приложения (см. экран ниже), настроить маппинг атрибутов и указать те операции, которые будут поддерживаться приложением: доверенная реконсиляция (Authoritative Sync), создание / удаление / активация / деактивация / изменение учетной записи (“ресурса” в понятиях SCIM). Здесь операции по включению / исключению пользователя в / из роли / группы относятся к операции изменения учетной записи.
3. SCIM Gateways (SCIM-шлюзы). А что делать, если вы хотите управлять доступом к вашему онпрем или облачному приложению, которое не поддерживает SCIM? В этом случае вы можете использовать шлюз SCIM Gateway, который будет транслировать выходящие SCIM-совместимые REST-вызовы в вызовы, понятные приложению. В этом случае само интегрируемое приложение изменять не нужно, а SCIM Gateway при определенных условиях можно расположить в DMZ зоне. Но потребуется код, который будет транслировать вызовы, фактически являющийся коннектором к приложению.
Существуют коммерческие SCIM Gateway’и, два из них (Aquera , Kapstone) сертифицированы с IDCS и доступны через Oracle OCI Marketplace. Коммерческие шлюзы как правило поддерживают большое количество онпрем и облачных приложений, но требуют разворачивания в облаке и лицензирования / подписки. Но в этом случае ответственность за разработку коннектора и поддержание его актуальности ложится на производителя шлюза. Так, например, компания Aquera, чей SCIM-шлюз сертифицирован с IDCS, разрабатывает коннекторы к любым приложениям под заказ.
Альтернатива коммерческим SCIM-шлюзам – собственный SCIM Gateway, который вы можете разработать самостоятельно и разместить в облаке или DMZ зоне. У вас будут варианты – разработать один шлюз для всех приложений, или же по шлюзу на каждое приложение. Oracle разработал пример шлюза на Node.js, который доступен на Github - https://github.com/oracle/idm-samples/tree/master/idcs-scim-gateway-app. Вы можете взять этот уже работающий прототип SCIM-шлюза и добавить свой код взаимодействия с целевой системой в нужных местах.
Итак, указанные способы интеграции с целью предоставления доступа (Provisioning) уже сейчас позволяют управлять доступом в гибридном окружении (в онпрем и облачные приложения). В скором будущем нас ждут возможность использовать готовые ICF коннекторы, разработанные Oracle или же вами.
4. Risk Calculation. Не относится к функционалу предоставления доступа, но тоже любопытно. Теперь вы видите рядом с каждым пользователем уровень ассоциированного с им агрегированного риска, наподобие того, как показано ниже.
Риск ранжируется, как и в Oracle Identity Governance, на “low”, “medium” и “high” (ок, есть еще “non applicable”), но внутри это число от 0 до 100, значение вычисляется Risk Provider’ом на основе разных влияющих факторов – входя из неизвестного расположения, необычного устройства, вводы неправильного пароля и т.д.
Там же можно посмотреть события и инциденты, которые повлияли на вычисление агрегированного значения риска.
Ну а настройка рисков (какой именно диапазон имеют риски “low”, “medium” и “high”) выполняется в Risk Provider’е, который имеется встроенный (от самого IDCS), или же можно интегрироваться с Symantec CloudSOC.
Ждем учета риска, связанного с предоставленным доступом, в агрегированном риске для пользователя, наподобие как это сейчас происходит в Identity Governance.
Остальные новые возможности, развитие продукта и общее описание функциональности можно посмотреть в презентации Oracle Identity Cloud Service (февраль 2020), которая выложена в разделе Презентации и брошюры.
Если вы нашли неточность в статье, плз, сообщите об этом мне - oleg.faynitskiy@gmail.com.
Относительно недавно, как вы возможно уже знаете, вышел очередной релиз Oracle Identity Cloud Service 19.3.3 с достаточно важным новым функционалом. Сам продукт был выпущен в январе 2020, но был развернут в большинстве ЦОД Oracle в января-феврале 2020. В статье мы посмотрим на некоторые новые возможности (преимущественно связанные с функционалом предоставления доступа) и на то, что нас ждет в ближайшем будущем.
Как вы знаете, функционал Identity Management в части предоставления доступа (Provisioning) и контроля доступа (Access Management) в последнее время стал “commodity”, т.е. широко доступным, предлагаемым большим количеством вендоров за все меньшую стоимость. Также по сути дела стандартизирован функционал, что позволяет заказчику внедрить определенный набор стандартных возможностей за меньшее время и меньший бюджет с предъявлением все меньших требований компетенции сотрудников компаний-интеграторов, которые внедряют решение. Локальные вендоры, а также серьезно демпингующие глобальные вендоры, распространение open-source решений, все это заставляет пионеров в этой индустрии искать новые области применения своих наработок. Например, в области CIAM (Consumer Identity & Access Management), а также в области облачного Identity Management.
Oracle не является исключением. Облачная стратегия Oracle, а также обострившаяся конкуренция на рынке IDM решений привела к тому, что помимо уже хорошо известных и зарекомендовавших себя на рынке онпрем решений Identity Governance и Access Management, появился новый облачный сервис Identity Cloud Service (IDCS), который в зависимости от требований заказчика может полностью заменять или дополнять онпрем решения. Как онпрем, так и облачные сервисы позволяют управлять доступом в онпрем и облачные приложения, и онпрем и облачный вариант имеют свои преимущества и недостатки. Так, онпрем продукты позволяют выполнить намного более гибкую настройку, позволяют осуществить более глубокую кастомизацию, адоптировав продукт под бизнес процессы предприятия. Тогда как облачный сервис позволяет меньше кастомизации, но существенно более прост при внедрении и обслуживании, внедрять облачный IDCS дешевле и проще (если вы готовы, разумеется, поступиться уникальностью своих бизнес процессов). Кроме того, в большинстве случаев заказчику нет необходимости заботиться об обновлении, что часто является камнем преткновения для онпрем решений, оно выполняется облачным провайдером (в данном случае – Oracle). Чтобы взять лучшее из обеих продуктов, возможны различные гибридные схемы (с использованием IDCS Connector for Identity Manager, например), но это предмет отдельной статьи.
Преимуществом облачного решения является и его принципиально новая “cloud-native” архитектура на основе микросервисов. Вся функциональность строится “API-first” и изначально доступна через REST API, после чего к ней дописывается UI.
В релизе IDCS 19.3.3 был добавлен существенный функционал в части Identity Provisioning, позволяющий реализовать гибридные сценарии управления доступом, когда доступ в онпрем системы заказчика управляется через облачный сервис. Об этом функционале, а также о некоторых других новых возможностях, я бы хотел рассказать.
1. IDCS Provisioning Bridge. IDCS развивается в сторону гибридной схемы взаимодействия, и еще более года назад появился компонент App Gateway, позволяющий осуществлять SSO в онпрем приложения, транслируя SAML-assertion в HTTP-заголовки (например, так выполняется SSO в онпрем установку Oracle e-Business Suite, подробнее тут - https://blogs.oracle.com/cloudsecurity/how-to-simplify-sso-to-oracle-ebusiness-suite-in-just-3-steps). Сейчас появился компонент IDCS Provisioning Bridge, позволяющий выполнять provisioning в онпрем приложения. Этот компонент скачивается из раздела Downloads и скорее всего представляет собой ICF Connector Server (ICF – Identity Connector Framework, в котором разрабатываются современные коннекторы Oracle Identity Governance), дополненный возможностями REST-запросов в сторону IDCS с целью получения списка задач для выполнения.
Потенциально IDCS Provisioning Bridge может выполнять код любого ICF коннектора, однако каждый коннектор принимает на вход уникальный набор атрибутов, который должен быть задан в соответствующей форме приложения в IDCS. На сегодняшний день эти формы имеются для Oracle e-Business Suite и Oracle Internet Directory (см. экран ниже). В скором будущем будут поддерживаться другие приложения из списка коннекторов Oracle Identity Governance (https://www.oracle.com/middleware/technologies/identity-management/oim-connectors-downloads.html), а также будет добавлена возможность создания собственного коннектора с уникальным набором атрибутов.
Особенностью решения задачи предоставления доступа с помощью Provisioning Bridge является то, что необходимо открывать только outbound стандартные порты, взаимодействие с IDCS инициируется со стороны Provisioning Bridge по REST. Принципиально другое решение для управления доступом – Generic SCIM.
2. Generic SCIM. Как вы знаете, SCIM (System for Cross-Domain Identity Management, ex-Simple Cloud Identity Management), http://www.simplecloud.info/) – стандарт, определяющий набор REST-endpoint’ов для управления доступом, является наследником SPML / vCard. Текущая версия SCIM2.0 – стандарт IETF с 2012, определяющий следующие REST-endpoint’ы.
Create: POST https://example.com/{v}/{resource}
Read: GET https://example.com/{v}/{resource}/{id}
Replace: PUT https://example.com/{v}/{resource}/{id}
Delete: DELETE https://example.com/{v}/{resource}/{id}
Update: PATCH https://example.com/{v}/{resource}/{id}
Search: GET https://example.com/{v}/{resource}?filter={attribute}{op}{value}&sortBy={attributeName}&sortOrder={ascending|descending}
Bulk: POST https://example.com/{v}/Bulk
GET /ServiceProviderConfig
GET /ResourceTypes
GET /Schemas
В IDCS появилась возможность создания приложения, доступ в которое предоставляется посредством стандартных SCIM-совместимых REST вызовов. Причем эти приложения могут быть развернуты как онпрем, так и в облаке. Но в случае онпрем-разворачивания управление доступом происходит посредством inbound REST-вызовов из облака, что принципиально отличает это решение от решения по управлению доступом через IDCS Provisioning Bridge (думаю, в ближайшем будущем нас ждет Generic SCIM коннектор, работающий изнутри Provisioning Bridge’а, что решит вопрос inbound вызовов). Стоит ли упоминать, что в этом случае интегрируемое приложение должно поддерживать SCIM и быть доступно из внешней сети Oracle Cloud.
Чтобы добавить SCIM-совместимое приложение, необходимо выбрать из App Catalog’а одно из следующих приложений (они отличаются способом аутентификации).
Далее необходимо заполнить атрибуты расположения SCIM-совместимого приложения (см. экран ниже), настроить маппинг атрибутов и указать те операции, которые будут поддерживаться приложением: доверенная реконсиляция (Authoritative Sync), создание / удаление / активация / деактивация / изменение учетной записи (“ресурса” в понятиях SCIM). Здесь операции по включению / исключению пользователя в / из роли / группы относятся к операции изменения учетной записи.
3. SCIM Gateways (SCIM-шлюзы). А что делать, если вы хотите управлять доступом к вашему онпрем или облачному приложению, которое не поддерживает SCIM? В этом случае вы можете использовать шлюз SCIM Gateway, который будет транслировать выходящие SCIM-совместимые REST-вызовы в вызовы, понятные приложению. В этом случае само интегрируемое приложение изменять не нужно, а SCIM Gateway при определенных условиях можно расположить в DMZ зоне. Но потребуется код, который будет транслировать вызовы, фактически являющийся коннектором к приложению.
Существуют коммерческие SCIM Gateway’и, два из них (Aquera , Kapstone) сертифицированы с IDCS и доступны через Oracle OCI Marketplace. Коммерческие шлюзы как правило поддерживают большое количество онпрем и облачных приложений, но требуют разворачивания в облаке и лицензирования / подписки. Но в этом случае ответственность за разработку коннектора и поддержание его актуальности ложится на производителя шлюза. Так, например, компания Aquera, чей SCIM-шлюз сертифицирован с IDCS, разрабатывает коннекторы к любым приложениям под заказ.
Альтернатива коммерческим SCIM-шлюзам – собственный SCIM Gateway, который вы можете разработать самостоятельно и разместить в облаке или DMZ зоне. У вас будут варианты – разработать один шлюз для всех приложений, или же по шлюзу на каждое приложение. Oracle разработал пример шлюза на Node.js, который доступен на Github - https://github.com/oracle/idm-samples/tree/master/idcs-scim-gateway-app. Вы можете взять этот уже работающий прототип SCIM-шлюза и добавить свой код взаимодействия с целевой системой в нужных местах.
Итак, указанные способы интеграции с целью предоставления доступа (Provisioning) уже сейчас позволяют управлять доступом в гибридном окружении (в онпрем и облачные приложения). В скором будущем нас ждут возможность использовать готовые ICF коннекторы, разработанные Oracle или же вами.
4. Risk Calculation. Не относится к функционалу предоставления доступа, но тоже любопытно. Теперь вы видите рядом с каждым пользователем уровень ассоциированного с им агрегированного риска, наподобие того, как показано ниже.
Риск ранжируется, как и в Oracle Identity Governance, на “low”, “medium” и “high” (ок, есть еще “non applicable”), но внутри это число от 0 до 100, значение вычисляется Risk Provider’ом на основе разных влияющих факторов – входя из неизвестного расположения, необычного устройства, вводы неправильного пароля и т.д.
Там же можно посмотреть события и инциденты, которые повлияли на вычисление агрегированного значения риска.
Ну а настройка рисков (какой именно диапазон имеют риски “low”, “medium” и “high”) выполняется в Risk Provider’е, который имеется встроенный (от самого IDCS), или же можно интегрироваться с Symantec CloudSOC.
Ждем учета риска, связанного с предоставленным доступом, в агрегированном риске для пользователя, наподобие как это сейчас происходит в Identity Governance.
Остальные новые возможности, развитие продукта и общее описание функциональности можно посмотреть в презентации Oracle Identity Cloud Service (февраль 2020), которая выложена в разделе Презентации и брошюры.
Если вы нашли неточность в статье, плз, сообщите об этом мне - oleg.faynitskiy@gmail.com.
No comments:
Post a Comment