WEBVTT

00:00:00.000 --> 00:00:03.300
Насправді, більшість людей вважають, що ідентифікація – це просто ім'я користувача та пароль.

00:00:03.420 --> 00:00:05.460
Ви вводите їх, отримуєте доступ, і готово.

00:00:05.580 --> 00:00:09.320
Але коли ви бізнес, що обслуговує клієнтів, ідентифікація стає набагато складнішою.

00:00:09.500 --> 00:00:12.340
Що робити, коли ваш додаток має дозволити тисячам людей реєструватися

00:00:12.340 --> 00:00:15.680
або входити за допомогою свого Google-аккаунту замість створення ще одного пароля?

00:00:15.840 --> 00:00:20.020
І як убезпечити всі ці клієнтські дані, не змішуючи їх із вашим каталогом працівників?

00:00:20.020 --> 00:00:23.620
Саме для вирішення цієї проблеми було створено Microsoft Entra External ID.

00:00:23.800 --> 00:00:27.160
Ось у чому річ. Він повністю замінює Azure AD B2C.

00:00:27.320 --> 00:00:30.780
Наприкінці цього епізоду ви зрозумієте, що таке External ID насправді –

00:00:30.780 --> 00:00:34.580
три основні способи його використання та чому це важливо для будь-якого клієнтського додатку.

00:00:34.760 --> 00:00:37.760
Старий метод – окремі ізольовані системи ідентифікації.

00:00:37.960 --> 00:00:41.160
Уявіть, що 20 років тому ви створили додаток для клієнтів.

00:00:41.320 --> 00:00:44.560
Тоді вам доводилося створювати власну систему входу, писати код для паролів,

00:00:44.560 --> 00:00:48.760
налаштовувати базу даних для їх зберігання та розробляти процес відновлення пароля – усе з нуля.

00:00:48.900 --> 00:00:51.820
Це добре працювало для маленького додатку з кількома сотнями користувачів,

00:00:51.940 --> 00:00:54.180
але зі зростанням додатків усе швидко ускладнювалося.

00:00:54.320 --> 00:00:56.960
Компаніям потрібно було дозволити вхід через Google або Facebook,

00:00:57.140 --> 00:01:00.940
впровадити багатофакторну автентифікацію та обробляти мільйони аккаунтів без збоїв.

00:01:01.080 --> 00:01:03.900
Створення всього цього власноруч перетворювалося на справжній кошмар.

00:01:03.900 --> 00:01:06.620
Першою відповіддю Microsoft була Azure AD B2C.

00:01:06.620 --> 00:01:10.320
Це був сервіс ідентифікації клієнтів, який свого часу вирішував реальну проблему.

00:01:10.460 --> 00:01:12.300
Але саме тут і почалися труднощі.

00:01:12.460 --> 00:01:16.700
Головною проблемою були так звані спеціальні політики, які писалися на мові XML.

00:01:16.960 --> 00:01:21.560
Якщо ви коли-небудь працювали з XML-файлами на сотні рядків, ви знаєте, як це болісно.

00:01:21.780 --> 00:01:26.060
Важко налаштовувати, важко налагоджувати, а якщо щось ламалося успіхів у пошуку причини.

00:01:26.060 --> 00:01:30.440
До того ж, Azure AD B2C була відокремлена від основної платформи ідентифікації Microsoft.

00:01:30.440 --> 00:01:37.560
Тож, якщо у вас уже були Microsoft 365 або Azure AD для працівників, B2C відчувалася як вивчення зовсім іншого продукту.

00:01:37.720 --> 00:01:42.160
Як і варто було очікувати, IT-команди ледве підтримували її, розробники не хотіли з нею працювати,

00:01:42.260 --> 00:01:45.600
а клієнти отримували незручний інтерфейс реєстрації, що змушував їх йти.

00:01:45.760 --> 00:01:51.300
Microsoft зрозуміла, що потрібне щось простіше й уніфіковане, і саме це стало Microsoft Entra External ID.

00:01:51.520 --> 00:01:54.100
Що таке Microsoft Entra External ID насправді?

00:01:54.240 --> 00:01:57.040
Отже, що саме являє собою Microsoft Entra External ID?

00:01:57.040 --> 00:01:58.540
Ось найпростіше визначення.

00:01:58.540 --> 00:02:03.280
Це хмарний сервіс ідентифікації для зовнішніх користувачів, клієнтів, партнерів та гостей, а не працівників.

00:02:03.400 --> 00:02:04.460
Подумайте про це так.

00:02:04.560 --> 00:02:06.560
Уявіть, що у вашої компанії є офісна будівля.

00:02:06.700 --> 00:02:08.320
Це ваш орендарк-тенант для працівників.

00:02:08.440 --> 00:02:11.680
Це місце, де працюють ваші співробітники, де стоять їхні столи та куди вони потрапляють за перепустками.

00:02:11.840 --> 00:02:13.680
Entra ID керує цією будівлею.

00:02:13.800 --> 00:02:19.020
Тепер уявіть, що ви відкриваєте вітрину для клієнтів, окремий простір, власний вхід, власні правила та власна безпека.

00:02:19.020 --> 00:02:24.200
Клієнти не заходять у кімнату відпочинку персоналу, а співробітники не отримують випадковий доступ до облікових записів клієнтів.

00:02:24.300 --> 00:02:25.660
Це і є External ID.

00:02:25.840 --> 00:02:29.060
Це частина сімейства Microsoft Entra, але дещо інша за призначенням.

00:02:29.160 --> 00:02:35.280
Це рішення створено для CIEM, керування ідентифікацією та доступом клієнтів, що охоплює весь життєвий цикл зовнішнього користувача.

00:02:35.520 --> 00:02:40.000
Реєстрація, вхід, скидання пароля, керування профілем, багатофакторна автентифікація, видача токенів.

00:02:40.000 --> 00:02:46.020
Він працює зі стандартними протоколами, такими як O2.0, OpenID Connect та SML, тому до нього можна підключити майже будь-який застосунок.

00:02:46.100 --> 00:02:48.800
Але ось у чому головна відмінність від старого Azure ADB2C.

00:02:48.960 --> 00:02:52.320
External ID простіший. Більше жодних спеціальних XML-політик.

00:02:52.460 --> 00:02:55.440
Натомість ви налаштовуєте потоки користувачів безпосередньо в центрі адміністрування.

00:02:55.600 --> 00:02:59.680
Або використовуєте спеціальні розширення автентифікації, які підключаються до вашої наявної серверної логіки.

00:02:59.820 --> 00:03:01.440
Та сама потужність менше проблем.

00:03:01.440 --> 00:03:03.240
Три основні випадки використання.

00:03:03.400 --> 00:03:05.560
Отже, як насправді використовувати External ID?

00:03:05.700 --> 00:03:07.100
Існує три головні сценарії.

00:03:07.320 --> 00:03:10.880
Вони охоплюють майже кожну ситуацію, коли вам потрібно керувати доступом неспівробітника.

00:03:11.060 --> 00:03:14.360
Почнемо з найбільш поширеного «Ідентифікація клієнтів» або B2C.

00:03:14.520 --> 00:03:16.980
Уявіть, що ви створюєте застосунок для замовлення піци.

00:03:17.160 --> 00:03:20.600
Вам потрібно, щоб люди реєструвалися, робили замовлення та поверталися наступного тижня.

00:03:20.600 --> 00:03:24.020
Ви хочете, щоб вони входили через свій обліковий запис Google замість створення ще одного пароля,

00:03:24.020 --> 00:03:27.020
і вам потрібно зібрати їхні імена, номери телефонів та вподобання щодо доставки.

00:03:27.160 --> 00:03:29.100
External ID вирішує всі ці завдання.

00:03:29.280 --> 00:03:31.640
Ви отримуєте готові потоки реєстрації та входу.

00:03:31.800 --> 00:03:35.920
Ви налаштовуєте, які атрибути збирати, ім'я, телефон, усе, що вам потрібно.

00:03:36.080 --> 00:03:39.520
Ви налаштовуєте соціальний вхід через Google, Facebook або Apple.

00:03:39.520 --> 00:03:45.660
І коли користувач автентифікується, External ID видає токен вашому застосунку, щоб той знав, хто це.

00:03:45.800 --> 00:03:49.900
Це заміна Azure ADB2C, і саме з цього починає більшість організацій.

00:03:49.900 --> 00:03:53.320
Інший сценарій – це співпраця між компаніями або B2B.

00:03:53.480 --> 00:03:57.820
Це коли вам потрібно надати партнерам або постачальникам доступ до ваших внутрішніх застосунків.

00:03:58.020 --> 00:04:01.980
Можливо, у вас є сайт SharePoint, який має бачити зовнішній логістичний партнер

00:04:01.980 --> 00:04:04.900
або інструмент керування проектами для фрилансерів-дизайнерів.

00:04:04.900 --> 00:04:08.900
У цьому сценарії ви запрошуєте їх як гостювих користувачів у свій робочий тенан.

00:04:09.100 --> 00:04:12.660
External ID обробляє електронні листи із запрошеннями, процес активації,

00:04:12.660 --> 00:04:16.580
коли вони приймають запрошення і політики доступу, що контролюють, що саме вони бачать.

00:04:16.680 --> 00:04:20.420
Це вже багато років існує як функція співпраці B2BVJD.

00:04:20.620 --> 00:04:22.720
Але тепер це частина парасолькового бренду External ID,

00:04:22.880 --> 00:04:25.820
тому ви керуєте цим з того самого місця, що й ідентифікаторами ваших клієнтів.

00:04:25.820 --> 00:04:28.380
Далі йде взаємодія машина-машина або M2M.

00:04:28.540 --> 00:04:31.380
Вона менш помітна для кінцевих користувачів, але не менш важлива.

00:04:31.520 --> 00:04:35.100
Іноді ваш серверний сервіс має взаємодіяти з іншим ARRI, платіжним процесором,

00:04:35.100 --> 00:04:37.680
сервісом аналітики даних або внутрішнім мікросервісом.

00:04:37.820 --> 00:04:40.940
Людина тут не задіяна, це просто одна програма звертається до іншої.

00:04:41.120 --> 00:04:45.100
External ID використовує потік автентифікації клієнтських облікових даних ООТ 2.0.

00:04:45.100 --> 00:04:48.820
Ваш сервіс автентифікується за допомогою ідентифікатора клієнта та секретного ключа,

00:04:48.900 --> 00:04:50.800
отримуючи токен для виклику подальшого ARRI.

00:04:50.940 --> 00:04:53.740
Це потребує преміум-додатку M2M, тому є певні витрати,

00:04:53.860 --> 00:04:57.380
але якщо вам потрібно убезпечити обмін даними між ARRI, це вбудована функція.

00:04:57.380 --> 00:05:02.180
Ці три сценарії охоплюють майже кожну ситуацію із зовнішньою ідентифікацією, з якою ви зіткнетеся.

00:05:02.320 --> 00:05:06.200
Але є важливе рішення, яке вам потрібно прийняти, де саме ці користувачі будуть зберігатися.

00:05:06.200 --> 00:05:11.140
Оскільки External ID може працювати у двох дуже різних місцях – робочий тенант або зовнішній тенант.

00:05:11.300 --> 00:05:12.640
Розберімо ці два варіанти.

00:05:12.820 --> 00:05:17.400
External ID може працювати у вашому поточному робочому тенанті або як цілком окремий зовнішній тенант.

00:05:17.400 --> 00:05:21.080
Це не одне й те саме, і вибір неправильного варіанту може спричинити проблеми в майбутньому.

00:05:21.220 --> 00:05:22.980
Почнімо з варіанту робочого тенанта.

00:05:23.160 --> 00:05:26.160
Ваша компанія вже має Tenant Entra ID для ваших співробітників.

00:05:26.160 --> 00:05:27.720
Це і є ваш робочий тенант.

00:05:27.880 --> 00:05:30.980
Якщо ви увімкнете функцію самостійної реєстрації гостєвих користувачів у цьому тенанті,

00:05:31.060 --> 00:05:34.500
зовнішні користувачі зможуть реєструватися і потрапляти в той самий каталог, що й ваші співробітники.

00:05:34.700 --> 00:05:37.880
Їхні облікові записи будуть розташовані поруч із обліковим записом вашого гендиректора.

00:05:37.880 --> 00:05:41.500
Для простіших сценаріїв B2B, як-от запрошення кількох партнерів на сайт SharePoint,

00:05:41.620 --> 00:05:43.880
змішування їх у тому самому каталозі цілком прийнятне.

00:05:44.020 --> 00:05:47.040
Це легко налаштувати, і вам не потрібно керувати окремим тенантом.

00:05:47.040 --> 00:05:47.960
Але є нюанс.

00:05:48.120 --> 00:05:50.720
Якщо ви створюєте застосунок для клієнтів із тисячами користувачів,

00:05:50.820 --> 00:05:54.020
ви не захочете, щоб ці клієнти перебували в тому ж каталозі, що й ваші співробітники.

00:05:54.180 --> 00:05:55.380
Це ризик для безпеки.

00:05:55.580 --> 00:05:58.100
Співробітник може випадково отримати доступ до даних клієнтів.

00:05:58.100 --> 00:06:01.580
Зміна конфігурації, призначена для співробітників, може вплинути на доступ клієнтів.

00:06:01.680 --> 00:06:04.120
А брендинг ваших сторінок входу для клієнтів буде прив'язаний до того,

00:06:04.220 --> 00:06:05.660
що ви налаштували для своєї компанії.

00:06:05.820 --> 00:06:06.660
Це не ідеально.

00:06:07.020 --> 00:06:08.980
Альтернативою є варіант зовнішнього тенанта.

00:06:09.120 --> 00:06:12.340
Ви створюєте новий ізольований каталог спеціально для ідентифікаторів клієнтів.

00:06:12.460 --> 00:06:13.720
Тут немає співробітників.

00:06:13.860 --> 00:06:15.320
Це повністю відокремлений простір.

00:06:15.440 --> 00:06:17.440
Пам'ятаєте аналогію з офісною будівлею раніше?

00:06:17.440 --> 00:06:19.700
Робочий тенант – це ваша штаб-квартира компанії.

00:06:19.840 --> 00:06:23.340
Зовнішній тенант – це окремий магазин, який ви відкриваєте для своїх клієнтів.

00:06:23.480 --> 00:06:26.340
У них власний вхід, власні правила та власна безпека.

00:06:26.560 --> 00:06:27.740
Нічого не змішується.

00:06:27.920 --> 00:06:29.980
Отже, які переваги зовнішнього тенанта?

00:06:30.140 --> 00:06:32.760
По-перше, ви отримуєте ізольоване сховище користувачів.

00:06:32.920 --> 00:06:35.660
Дані клієнтів залишаються повністю відокремленими від даних працівників,

00:06:35.760 --> 00:06:37.660
що зменшує ризики та спрощує дотримання вимог.

00:06:37.760 --> 00:06:39.780
По-друге, ви отримуєте окремий брендинг.

00:06:39.780 --> 00:06:43.380
Ви можете налаштувати вигляд сторінок входу спеціально для ваших клієнтів,

00:06:43.480 --> 00:06:45.260
не впливаючи на корпоративний орендар.

00:06:45.360 --> 00:06:48.480
По-третє, ви отримуєте нативний арі автентифікації для мобільних додатків,

00:06:48.580 --> 00:06:52.160
що дозволяє створювати повністю кастомні екрани входу в iOS чи Android-додатках.

00:06:52.340 --> 00:06:54.780
Жодних перенаправлень у браузер чи незграбних веб-вікон.

00:06:54.920 --> 00:06:57.000
І по-четверте, ви отримуєте ціноутворення на основі MIU,

00:06:57.080 --> 00:06:58.460
тобто щомісячних активних користувачів.

00:06:58.460 --> 00:07:01.860
Ви платите лише за тих користувачів, які реально пройшли автентифікацію протягом місяця,

00:07:01.960 --> 00:07:04.080
що природно масштабується зростом вашої клієнтської бази.

00:07:04.160 --> 00:07:05.440
Отже, коли що обирати?

00:07:05.640 --> 00:07:06.700
Все досить просто.

00:07:06.920 --> 00:07:10.680
Якщо ви створюєте бід вас і додаток для тисяч клієнтів, обирайте зовнішній орендар.

00:07:10.820 --> 00:07:14.020
Це рекомендований підхід, і саме для цього було створено External ID.

00:07:14.220 --> 00:07:17.160
Якщо ви просто запрошуєте партнерів для доступу до внутрішніх ресурсів,

00:07:17.280 --> 00:07:19.100
варіант робочого орендаря цілком підійде.

00:07:19.100 --> 00:07:21.640
Головне – зрозуміти різницю до початку розробки,

00:07:21.640 --> 00:07:29.300
Тепер поговоримо про безпеку.

00:07:29.440 --> 00:07:31.480
Якщо ви відкриваєте доступ клієнтам до свого додатка,

00:07:31.580 --> 00:07:34.180
ви маєте переконатися, що сторонні особи не потраплять всередину.

00:07:34.320 --> 00:07:37.400
External ID включає ті самі функції безпеки корпоративного рівня,

00:07:37.500 --> 00:07:39.380
які EntraID пропонує для працівників.

00:07:39.520 --> 00:07:41.660
Це означає багатофакторну автентифікацію,

00:07:41.660 --> 00:07:43.860
умовний доступ та політики на основі ризиків.

00:07:44.020 --> 00:07:46.000
Для MFA наразі у вас є два варіанти.

00:07:46.200 --> 00:07:48.540
Одноразовий пароль на електронну пошту – безкоштовний.

00:07:48.720 --> 00:07:50.520
Система надсилає код на пошту користувача,

00:07:50.520 --> 00:07:51.820
він вводить його і готово.

00:07:51.960 --> 00:07:54.320
СМС-код працює так само, але надсилається на телефон,

00:07:54.480 --> 00:07:56.000
і тут передбачені витрати оператора.

00:07:56.220 --> 00:07:59.380
Варто зазначити, що підтримки Microsoft осентикейта поки що немає.

00:07:59.540 --> 00:08:02.580
Це поточне обмеження, над яким Microsoft, імовірно, працює,

00:08:02.700 --> 00:08:04.580
але наразі це тільки пошта або СМС.

00:08:04.720 --> 00:08:06.920
Умовний доступ – це найцікавіша частина.

00:08:06.920 --> 00:08:11.460
Ви можете задати правила, наприклад, вимагати MFA при середньому рівні ризику входу

00:08:11.460 --> 00:08:14.500
або блокувати доступ із країн, у яких ми не ведемо бізнес.

00:08:14.680 --> 00:08:17.980
Система оцінює кожну спробу входу в режимі реального часу.

00:08:20.520 --> 00:08:24.040
Система може автоматично підвищити вимоги безпеки

00:08:24.040 --> 00:08:26.480
без необхідності будувати цю логіку власноруч.

00:08:26.600 --> 00:08:28.300
Але є одна функція, яка дійсно виділяється,

00:08:28.400 --> 00:08:30.400
посилена автентифікація – step-up осентикейшн.

00:08:30.520 --> 00:08:31.520
Ось як це працює.

00:08:31.660 --> 00:08:34.200
Уявіть, що користувач входить у ваш додаток лише за паролем,

00:08:34.320 --> 00:08:35.620
щоб переглянути каталог товарів.

00:08:35.620 --> 00:08:37.240
Це нормально для дій із низьким ризиком,

00:08:37.340 --> 00:08:39.540
але коли вони намагаються переглянути історію платежів

00:08:39.540 --> 00:08:42.060
або завантажити рахунок, вам потрібна додаткова перевірка.

00:08:42.060 --> 00:08:44.740
Завдяки поетапній автентифікації ви можете вимагати МФА

00:08:44.740 --> 00:08:46.420
лише для певних розділів вашого додатка.

00:08:46.560 --> 00:08:48.940
Користувач не отримує запит, доки не спробує отримати доступ

00:08:48.940 --> 00:08:49.980
до чогось конфіденційного.

00:08:50.140 --> 00:08:52.680
І все це обробляється External ID у фоновому режимі

00:08:52.680 --> 00:08:54.940
за допомогою так званого контексту автентифікації.

00:08:55.140 --> 00:08:57.520
Ви визначаєте, які частини вашого додатка потребують

00:08:57.520 --> 00:08:59.720
додаткового захисту, а система бере на себе решту.

00:08:59.860 --> 00:09:02.400
Користувач отримує зручність під час звичайного перегляду,

00:09:02.480 --> 00:09:04.060
а конфіденційні дані залишаються захищеними.

00:09:04.780 --> 00:09:06.640
Брендинг і користувацький досвід

00:09:06.640 --> 00:09:08.740
Контроль брендингу – одна з головних причин,

00:09:08.820 --> 00:09:12.500
чому організації обирають External ID, а не власну систему входу.

00:09:12.620 --> 00:09:15.400
Ви отримуєте повний контроль над виглядом сторінок реєстрації та входу,

00:09:15.480 --> 00:09:17.560
завантажуєте свій логотип, задаєте кольори фону,

00:09:17.660 --> 00:09:19.160
додаєте фавікон для вкладки браузера

00:09:19.160 --> 00:09:20.960
та налаштовуєте верхній і нижній колон титули

00:09:20.960 --> 00:09:23.540
з посиланнями на політику конфіденційності і умови використання.

00:09:23.720 --> 00:09:25.180
Якщо вам потрібно ще більше контролю,

00:09:25.180 --> 00:09:27.100
ви можете завантажити власний CSS-файл,

00:09:27.100 --> 00:09:29.060
щоб змінити шрифти, кольори кнопок і макет.

00:09:29.180 --> 00:09:31.640
Це ваш бренд, ваші кольори, ви вирішуєте все.

00:09:31.820 --> 00:09:33.460
А ось тут починаються нюанси.

00:09:33.580 --> 00:09:35.040
Брендинг є глобальним для орендаря,

00:09:35.140 --> 00:09:36.540
а не для кожного окремого додатка.

00:09:36.680 --> 00:09:38.340
Тож, якщо у вас кілька додатків, наприклад,

00:09:38.440 --> 00:09:39.960
клієнтський портал і мобільний застосунок,

00:09:40.060 --> 00:09:41.700
вони матимуть однакові брендовані сторінки.

00:09:41.880 --> 00:09:44.060
Ви не можете надати кожному додатку власний вигляд.

00:09:44.200 --> 00:09:47.380
Старий Azure ADB2C дозволяв налаштовувати брендинг для кожного додатка,

00:09:47.380 --> 00:09:49.280
але External ID поки що це не підтримує.

00:09:49.280 --> 00:09:52.820
Ще одне обмеження – повідомлення про помилки на сторінках входу не можна налаштувати.

00:09:53.000 --> 00:09:54.960
Якщо хтось введе неіснуючу адресу електронної пошти,

00:09:55.060 --> 00:09:55.980
він побачить щось на кшталт,

00:09:56.060 --> 00:09:58.040
ми не змогли знайти обліковий запис із цією адресою.

00:09:58.160 --> 00:09:59.720
І ви не можете змінити цей текст.

00:09:59.940 --> 00:10:01.600
Для деяких організацій це прийнятно,

00:10:01.780 --> 00:10:03.840
але для інших, особливо в регульованих галузях

00:10:03.840 --> 00:10:06.120
або з суворим стилем бренду, це справжня проблема.

00:10:06.380 --> 00:10:08.240
Для мобільних додатків є кращий варіант.

00:10:08.240 --> 00:10:11.900
External ID має власний арі автентифікації для iOS та Android.

00:10:11.900 --> 00:10:14.940
Замість того, щоб перенаправляти користувачів на сторінку входу в браузері,

00:10:15.000 --> 00:10:17.620
ви можете створити повністю власні екрани входу всередині додатка.

00:10:17.800 --> 00:10:19.040
Жодних перенаправлень у браузер,

00:10:19.160 --> 00:10:20.480
жодних незграбних веб-переглядів.

00:10:20.620 --> 00:10:22.600
Користувач весь час залишається у вашому додатку,

00:10:22.680 --> 00:10:23.960
і ви контролюєте кожен піксель.

00:10:24.100 --> 00:10:25.420
Це набагато зручніший досвід,

00:10:25.520 --> 00:10:28.580
і це одна з тих функцій, яких ніколи не було в Azure AD B2C.

00:10:28.780 --> 00:10:30.580
Міграція з Azure AD B2C

00:10:30.580 --> 00:10:32.520
Якщо ви вже користуєтеся Azure AD B2C,

00:10:32.520 --> 00:10:34.760
ви, мабуть, запитуєте себе, що це означає для вас.

00:10:34.900 --> 00:10:35.820
Справа ось у чому.

00:10:36.000 --> 00:10:39.140
Microsoft підтримуватиме B2C принаймні до 2030 року.

00:10:39.260 --> 00:10:41.760
Отже, ваші існуючі орендарі не перестануть працювати завтра,

00:10:41.880 --> 00:10:42.920
але нових функцій не буде.

00:10:43.080 --> 00:10:45.640
Усі інновації, ключі доступу, власна автентифікація,

00:10:45.780 --> 00:10:48.220
захист від шахрайства є ексклюзивними для External ID.

00:10:48.420 --> 00:10:50.660
Ви знаходитесь на платформі, яка фактично заморожена.

00:10:50.820 --> 00:10:52.860
Компанія Microsoft опублікувала офіційні інструменти

00:10:52.860 --> 00:10:54.040
та рекомендації щодо міграції,

00:10:54.040 --> 00:10:55.900
і залежно від ваших масштабів існує два шляхи.

00:10:56.040 --> 00:10:58.600
Для орендарів із кількістю об'єктів каталогу користувачів,

00:10:58.740 --> 00:11:00.000
груп, спеціальних атрибутів,

00:11:00.120 --> 00:11:02.860
менше ніж 5 мільйонів стандартна міграція є досить простою.

00:11:02.980 --> 00:11:05.080
Це працює як перенесення між орендарями.

00:11:05.280 --> 00:11:07.320
Ви створюєте нового орендаря External ID,

00:11:07.480 --> 00:11:09.520
переносите користувачів та їхні облікові дані,

00:11:09.600 --> 00:11:11.120
а потім перемикаєте свої програми.

00:11:11.260 --> 00:11:14.040
Microsoft надає інструменти для масового експорту і імпорту користувачів,

00:11:14.640 --> 00:11:16.380
а для мінімізації збоїв під час переходу

00:11:16.380 --> 00:11:18.620
можна використовувати JIT-міграцію паролів.

00:11:18.740 --> 00:11:21.740
Для більших орендарів, що мають понад 5 мільйонів об'єктів каталогу,

00:11:21.820 --> 00:11:24.080
існує режим сумісності високого масштабу HSC.

00:11:24.260 --> 00:11:26.880
У цьому режимі Azure AD B2C та External ID

00:11:26.880 --> 00:11:29.020
працюють паралельно в межах одного орендаря.

00:11:29.160 --> 00:11:32.000
Ваші наявні кінцеві точки B2C залишаються активними,

00:11:32.060 --> 00:11:33.900
поки ви поступово переводите свої програми.

00:11:34.060 --> 00:11:35.660
Це рішення розроблене для організацій,

00:11:35.720 --> 00:11:37.780
які не можуть перенести мільйони користувачів за ніч,

00:11:37.900 --> 00:11:39.120
але воно має свої недоліки.

00:11:39.120 --> 00:11:41.080
Жодних соціальних провайдерів ідентифікації,

00:11:41.200 --> 00:11:42.860
ключів доступу, обмежений умовний доступ

00:11:42.860 --> 00:11:44.400
і деякі функції просто недоступні.

00:11:44.540 --> 00:11:47.160
Сприймайте це як стратегію переходу, а не як постійне рішення.

00:11:47.300 --> 00:11:48.520
Тепер про серйозну зміну.

00:11:48.720 --> 00:11:50.600
Спеціальні політики більше не підтримуються.

00:11:50.780 --> 00:11:52.820
Якщо ви створили складні процеси автентифікації

00:11:52.820 --> 00:11:55.300
за допомогою XML-фреймворку Azure AD B2C,

00:11:55.420 --> 00:11:56.960
вони не працюватимуть в External ID.

00:11:57.120 --> 00:11:58.320
Вам доведеться відтворити цю логіку,

00:11:58.420 --> 00:11:59.700
використовуючи потоки користувачів

00:11:59.700 --> 00:12:01.200
та спеціальні розширення автентифікації.

00:12:01.200 --> 00:12:02.540
Не існує магічного інструменту,

00:12:02.620 --> 00:12:04.540
який автоматично конвертує ваш XML у новий формат.

00:12:04.680 --> 00:12:06.160
Вам доведеться зробити це вручну.

00:12:06.320 --> 00:12:07.320
Отже, підсумуємо.

00:12:07.460 --> 00:12:08.740
Якщо ви починаєте з нуля сьогодні,

00:12:08.820 --> 00:12:10.060
використовуйте External ID.

00:12:10.240 --> 00:12:12.280
Немає жодних причин навіть дивитися на B2C.

00:12:12.440 --> 00:12:14.000
Якщо у вас вже є орендар B2C,

00:12:14.100 --> 00:12:15.600
починайте планувати міграцію зараз.

00:12:15.720 --> 00:12:17.240
У вас є час до 2030 року,

00:12:17.320 --> 00:12:18.700
але якщо чекати до останнього моменту,

00:12:18.760 --> 00:12:20.580
вам доведеться поспіхом виконувати складну міграцію,

00:12:20.660 --> 00:12:22.280
одночасно підтримуючи роботу наявних програм.

00:12:22.580 --> 00:12:23.500
Починайте з малого.

00:12:23.500 --> 00:12:25.720
Оберіть одну програму, перенесіть її, протестуйте,

00:12:25.900 --> 00:12:28.040
засвоїте отриманий досвід, а потім переходьте до інших.

00:12:28.180 --> 00:12:29.500
Досвід розробника та автоматизація.

00:12:30.220 --> 00:12:31.820
Microsoft дійсно зосередилася на тому,

00:12:31.940 --> 00:12:34.120
щоб зробити External ID зручним для розробників,

00:12:34.180 --> 00:12:36.800
і це значна відмінність від старих спеціальних політик B2C.

00:12:36.920 --> 00:12:38.180
Пам'ятаєте ті XML-файли,

00:12:38.280 --> 00:12:39.620
що розтягувалися на сотні рядків

00:12:39.620 --> 00:12:41.280
і ламалися через одну загублену дужку?

00:12:41.440 --> 00:12:42.460
Цього більше немає.

00:12:42.640 --> 00:12:44.440
Існує розширення для Visual Studio Code

00:12:44.440 --> 00:12:46.420
під назвою Microsoft Entra External ID.

00:12:46.420 --> 00:12:48.280
Після автентифікації ви можете переглядати

00:12:48.280 --> 00:12:49.880
свого орендаря, потоки користувачів,

00:12:49.980 --> 00:12:51.620
завантажувати їх як JSON-файли

00:12:51.620 --> 00:12:53.100
і навіть попередньо переглядати брендинг,

00:12:53.200 --> 00:12:54.120
не виходячи з редактора.

00:12:54.260 --> 00:12:56.240
Ви бачите, як виглядає сторінка входу

00:12:56.240 --> 00:12:57.440
ще до її публікації.

00:12:57.640 --> 00:12:59.580
Крім того, є Microsoft Graph ARI.

00:12:59.740 --> 00:13:01.400
Майже кожен ресурс External ID,

00:13:01.560 --> 00:13:03.340
потоки користувачів, реєстрації програм

00:13:03.340 --> 00:13:05.000
і брендинг можна керувати програмно.

00:13:05.160 --> 00:13:06.640
Це означає, що ви можете автоматизувати

00:13:06.640 --> 00:13:08.000
налаштування орендаря у своїх CI,

00:13:08.000 --> 00:13:09.500
CD-конвоєрах за допомогою Павашел

00:13:09.500 --> 00:13:10.400
або РЕСТ-запитів.

00:13:10.520 --> 00:13:11.460
Створюйте новий клієнт,

00:13:11.540 --> 00:13:12.880
налаштовуйте потоки користувачів,

00:13:12.980 --> 00:13:14.600
реєструйте додаток, додавайте брендинг

00:13:14.600 --> 00:13:15.500
і все це через скрип.

00:13:15.620 --> 00:13:17.360
Якщо ви керуєте кількома середовищами,

00:13:17.460 --> 00:13:18.540
це значно економить час.

00:13:18.780 --> 00:13:20.580
Користувацькі розширення автентифікації

00:13:20.580 --> 00:13:21.520
це справжня сила.

00:13:21.700 --> 00:13:22.660
Замість складного XML

00:13:22.660 --> 00:13:24.380
ви розширюєте потоки автентифікації

00:13:24.380 --> 00:13:26.520
простими HTTP запитами до Azure Functions.

00:13:26.680 --> 00:13:28.720
Ви можете підключитися до чотирьох подій.

00:13:28.720 --> 00:13:30.400
Початок видачі токена дозволяє

00:13:30.400 --> 00:13:32.060
додавати до нього власні твердження,

00:13:32.200 --> 00:13:33.840
як от ролі чи рівень лояльності.

00:13:34.000 --> 00:13:35.780
Збір атрибутів, початок і надсилання

00:13:35.780 --> 00:13:37.460
дозволяє перевіряти, чи заповнювати

00:13:37.460 --> 00:13:39.720
дані реєстрації, викликаючи власний бекенд.

00:13:39.900 --> 00:13:41.260
А надсилання OOTP на пошту

00:13:41.260 --> 00:13:43.280
дає змогу налаштувати листи для верифікації.

00:13:43.460 --> 00:13:44.980
Це така ж гнучкість, як у B2C,

00:13:45.100 --> 00:13:47.000
але в моделі, зрозумілій будь-якому розробнику.

00:13:47.180 --> 00:13:48.760
Варто знати про певні обмеження.

00:13:48.900 --> 00:13:50.480
Поки немає сповіщень Microsoft Graph,

00:13:50.480 --> 00:13:52.140
тому ви не можете автоматично запускати

00:13:52.140 --> 00:13:54.060
робочий процес при реєстрації користувача.

00:13:54.180 --> 00:13:55.920
Деякі налаштування все ще потрібно робити

00:13:55.920 --> 00:13:57.560
вручну в центрі, і немає вбудованої

00:13:57.560 --> 00:13:58.860
сторінки редагування профілю.

00:13:59.000 --> 00:14:01.120
Якщо ви хочете, щоб користувачі оновлювали дані,

00:14:01.200 --> 00:14:02.420
створіть таку сторінку в додатку

00:14:02.420 --> 00:14:03.920
і викликайте граф АРІ самостійно.

00:14:04.040 --> 00:14:05.540
Але напрямок цілком зрозумілий.

00:14:05.660 --> 00:14:07.700
Microsoft прагне зробити зовнішні ідентифікатори

00:14:07.700 --> 00:14:08.800
повністю автоматизованими.

00:14:08.940 --> 00:14:11.080
Це значно полегшує керування в масштабах.

00:14:11.200 --> 00:14:12.320
Отже, тепер ви знаєте,

00:14:12.320 --> 00:14:14.280
Microsoft Entra External ID

00:14:14.280 --> 00:14:16.540
Це сучасна заміна Azure ADB2C

00:14:16.540 --> 00:14:18.140
об'єднана під брендом Entra.

00:14:18.300 --> 00:14:19.680
Три сценарії використання,

00:14:19.880 --> 00:14:21.280
ідентифікація клієнтів,

00:14:21.420 --> 00:14:23.920
співпраця з партнерами та взаємодія між машинами

00:14:23.920 --> 00:14:25.560
покривають майже всі потреби.

00:14:25.700 --> 00:14:28.460
Ключове рішення – використовувати корпоративний клієнт

00:14:28.460 --> 00:14:30.040
чи створити окремий зовнішній.

00:14:30.160 --> 00:14:31.920
Для додатків, орієнтованих на клієнтів,

00:14:32.020 --> 00:14:33.560
окремий клієнт майже завжди кращий.

00:14:33.800 --> 00:14:36.160
Ідентифікація – це вхідні двері до вашого додатка.

00:14:36.160 --> 00:14:38.000
Правильний, безпечний, брендований

00:14:38.000 --> 00:14:39.800
і простий підхід безпосередньо впливає

00:14:39.800 --> 00:14:41.900
на довіру користувачів та розвиток бізнесу.

00:14:42.080 --> 00:14:43.140
Ваше домашнє завдання –

00:14:43.140 --> 00:14:45.160
перейдіть на entra.microsoft.com,

00:14:45.300 --> 00:14:46.400
створіть зовнішній клієнт

00:14:46.400 --> 00:14:48.180
і спробуйте посібник для початку роботи.

00:14:48.340 --> 00:14:50.460
Він допоможе налаштувати демонстраційний додаток

00:14:50.460 --> 00:14:51.340
за лічені хвилини.

00:14:51.460 --> 00:14:53.260
Підписуйтесь, щоб дізнаватися про платформу

00:14:53.260 --> 00:14:55.200
ідентифікації Microsoft простою мовою.