WEBVTT

00:00:00.000 --> 00:00:03.460
На самом деле большинство людей считают, что учетные данные – это просто имя пользователя и пароль.

00:00:03.620 --> 00:00:05.580
Вводишь их, получаешь доступ и готово.

00:00:05.660 --> 00:00:09.260
Но когда вы – бизнес, работающий с клиентами, все становится намного сложнее.

00:00:09.460 --> 00:00:12.460
Что делать, если в приложении нужно зарегистрировать тысячи пользователей

00:00:12.460 --> 00:00:15.840
или дать им возможность войти через аккаунт Google, а не создавать очередной пароль?

00:00:15.940 --> 00:00:20.200
И как обеспечить безопасность данных клиентов, не смешивая их с каталогом сотрудников?

00:00:20.360 --> 00:00:23.700
Именно эту проблему призван решить Microsoft Intra External ID.

00:00:23.900 --> 00:00:26.980
Вот в чем суть. Он полностью заменяет Azure от B2C.

00:00:26.980 --> 00:00:30.380
К концу этого выпуска вы поймете, что такое External ID на самом деле,

00:00:30.600 --> 00:00:34.560
три основных способа его использования и почему это важно для любого клиентского приложения.

00:00:34.780 --> 00:00:37.820
Старый подход – отдельные изолированные системы идентификации.

00:00:37.980 --> 00:00:41.300
Представьте, что 20 лет назад вы создали приложение для клиентов.

00:00:41.460 --> 00:00:44.840
Тогда приходилось создавать систему входа с нуля, писать код для паролей,

00:00:45.000 --> 00:00:48.860
настраивать базу данных для их хранения, разрабатывать процесс восстановления пароля.

00:00:49.040 --> 00:00:51.680
Для небольшого приложения с сотней пользователей это работало,

00:00:51.880 --> 00:00:54.080
но с ростом популярности все быстро усложнялось.

00:00:54.080 --> 00:00:56.720
Компаниям нужно было разрешить вход через Google или Facebook.

00:00:56.960 --> 00:01:01.200
Требовалась многофакторная аутентификация и способность обрабатывать миллионы аккаунтов без сбоев.

00:01:01.360 --> 00:01:04.000
Создавать все это самостоятельно было настоящим кошмаром.

00:01:04.100 --> 00:01:06.580
Первым ответом Microsoft стал Azure от B2C.

00:01:06.780 --> 00:01:10.500
Это был сервис идентификации клиентов, который в то время решал реальную проблему.

00:01:10.660 --> 00:01:11.900
Но тут начались сложности.

00:01:12.120 --> 00:01:14.980
Главной проблемой были так называемые пользовательские политики,

00:01:15.160 --> 00:01:16.780
которые писались на языке XML.

00:01:17.020 --> 00:01:19.880
Если вы хоть раз работали с XML-файлами на сотни строк,

00:01:20.060 --> 00:01:21.800
вы знаете, насколько это болезненно.

00:01:21.800 --> 00:01:23.600
Трудно настроить, трудно отладить.

00:01:23.780 --> 00:01:26.120
А если что-то ломалось, удачи в поисках причины.

00:01:26.260 --> 00:01:30.280
Вдобавок, Azure от B2C был отделен от основной платформы идентификации Microsoft.

00:01:30.540 --> 00:01:34.400
Поэтому, если у вас уже был Microsoft 365 или Azure для сотрудников,

00:01:34.560 --> 00:01:37.680
B2C ощущался как совершенно новый продукт, который нужно учить с нуля.

00:01:37.800 --> 00:01:40.720
Как и следовало ожидать, IT-командам было сложно его поддерживать.

00:01:40.900 --> 00:01:42.300
Разработчики боялись с ним работать,

00:01:42.460 --> 00:01:45.640
а клиенты получали неудобный процесс регистрации, из-за которого уходили.

00:01:45.760 --> 00:01:49.060
В Microsoft поняли, что нужно что-то более простое и унифицированное.

00:01:49.060 --> 00:01:51.420
И именно это стало Microsoft Intra External ID.

00:01:51.420 --> 00:01:54.220
Что такое Microsoft Intra External ID на самом деле?

00:01:54.380 --> 00:01:56.880
Итак, что же такое Microsoft Intra External ID?

00:01:57.080 --> 00:01:58.540
Вот самое простое определение.

00:01:58.760 --> 00:02:03.320
Это облачный сервис идентификации для внешних пользователей, клиентов, партнеров и гостей, а не сотрудников.

00:02:03.440 --> 00:02:04.540
Посмотрите на это иначе.

00:02:04.640 --> 00:02:06.740
Представьте, что у вашей компании есть офисные здания.

00:02:06.900 --> 00:02:08.240
Это ваш арендатор для сотрудников.

00:02:08.360 --> 00:02:11.760
Это место, где работают ваши сотрудники, где стоят их столы и куда их пускают по пропускам.

00:02:11.900 --> 00:02:13.520
Intra ID управляет этим зданием.

00:02:13.520 --> 00:02:19.280
А теперь представьте, что вы открываете витрину для клиентов, отдельное пространство, свой вход, свои правила, своя безопасность.

00:02:19.400 --> 00:02:24.280
Клиенты не забредут в комнату отдыха для персонала, а сотрудники не получат случайный доступ к аккаунтам клиентов.

00:02:24.440 --> 00:02:25.700
Это и есть External ID.

00:02:25.940 --> 00:02:28.900
Это часть семейства Microsoft Intra, но с другой спецификой.

00:02:29.100 --> 00:02:35.260
Система создана для CIM, управления идентификацией и доступом клиентов и охватывает весь жизненный цикл внешнего пользователя.

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

00:02:40.180 --> 00:02:44.120
Она работает со стандартными протоколами, такими как у AT2, 0, OpenID Connect и SAML.

00:02:44.260 --> 00:02:46.180
Поэтому к ней можно подключить почти любое приложение.

00:02:46.320 --> 00:02:48.900
Но вот в чем главное отличие от старого Azure ADB2C.

00:02:49.060 --> 00:02:50.120
External ID проще.

00:02:50.360 --> 00:02:52.380
Больше никаких пользовательских XML-политик.

00:02:52.520 --> 00:02:55.440
Вместо этого вы настраиваете потоки пользователей прямо в центре администрирования.

00:02:55.560 --> 00:02:59.740
Или используете настраиваемые расширения аутентификации, которые подключаются к вашей существующей логике бэкенда.

00:02:59.820 --> 00:03:00.500
Та же мощность.

00:03:00.700 --> 00:03:01.580
Меньше головной боли.

00:03:01.680 --> 00:03:03.220
Три основных варианта использования.

00:03:05.260 --> 00:03:05.580
External ID.

00:03:05.820 --> 00:03:07.140
Существует три основных сценария.

00:03:07.340 --> 00:03:10.980
Они охватывают почти любую ситуацию, когда вам нужно управлять тем, кто не является сотрудником.

00:03:11.140 --> 00:03:12.500
Начнем с самого распространенного.

00:03:12.860 --> 00:03:14.420
Идентификация клиентов или B2C.

00:03:14.620 --> 00:03:17.080
Представьте, что вы создаете приложение для заказа пиццы.

00:03:17.240 --> 00:03:20.680
Вам нужно, чтобы люди регистрировались, делали заказы и возвращались на следующей неделе.

00:03:20.860 --> 00:03:24.160
Вы хотите, чтобы они входили через свой аккаунт Google, а не создавали новый пароль.

00:03:24.180 --> 00:03:27.100
И вам нужно собирать их имена, номера телефонов и предпочтения по доставке.

00:03:27.260 --> 00:03:29.000
External ID справляется со всем этим.

00:03:29.200 --> 00:03:31.620
Вы получаете готовые потоки регистрации и входа.

00:03:31.620 --> 00:03:36.000
Вы настраиваете атрибуты, которые нужно собрать, имя, телефон, все, что вам нужно.

00:03:36.160 --> 00:03:39.460
Вы настраиваете социальный вход через Google, Facebook или Apple.

00:03:39.640 --> 00:03:45.760
И когда пользователь проходит аутентификацию, External ID выдает токен вашему приложению, чтобы оно знало, кто этот человек.

00:03:45.920 --> 00:03:47.420
Это замена Azure at B2C.

00:03:47.660 --> 00:03:49.920
И именно с этого начинают большинство организаций.

00:03:50.080 --> 00:03:53.480
Еще один сценарий – это сотрудничество между компаниями или B2B.

00:03:53.480 --> 00:03:57.840
Это когда вам нужно предоставить партнерам или поставщикам доступ к вашим внутренним приложениям.

00:03:57.920 --> 00:04:01.780
Может быть, у вас есть сайт SharePoint, который должен видеть ваш внешний логистический партнер.

00:04:01.820 --> 00:04:05.040
Или инструмент управления проектами, который используют ваши дизайнеры-фрилансеры.

00:04:05.200 --> 00:04:08.980
В этом сценарии вы приглашаете их в качестве гостевых пользователей в ваш рабочий клиент.

00:04:09.180 --> 00:04:12.460
External ID управляет электронным письмом с приглашением, процессом активации,

00:04:12.580 --> 00:04:16.380
когда они принимают приглашения и политиками доступа, контролирующими, что они могут видеть.

00:04:16.520 --> 00:04:20.720
Это на самом деле существует уже много лет как B2B сотрудничество внутри Azure at.

00:04:20.720 --> 00:04:24.300
Но теперь это часть экосистемы External ID, поэтому вы управляете ею из того же места,

00:04:24.480 --> 00:04:25.760
что и идентификаторами ваших клиентов.

00:04:25.960 --> 00:04:28.480
Далее идет взаимодействие машина-машина или M2M.

00:04:28.660 --> 00:04:31.360
Оно менее заметно для конечных пользователей, но не менее важно.

00:04:31.580 --> 00:04:34.500
Иногда вашему серверному приложению нужно взаимодействовать с другим API,

00:04:34.680 --> 00:04:37.800
платежным процессором, сервисом аналитики или внутренним микросервисом.

00:04:37.940 --> 00:04:41.100
Здесь не участвует человек, это просто вызов одного приложения другим.

00:04:41.240 --> 00:04:45.120
External ID использует поток предоставления учетных данных клиента у А2.0.

00:04:45.120 --> 00:04:48.880
Ваш сервис проходит аутентификацию с помощью идентификатора и секрета клиента,

00:04:48.880 --> 00:04:50.740
получая токен для вызова целевого API.

00:04:50.940 --> 00:04:54.340
Для этого требуется надстройка M2M Premium, что влечет за собой расходы,

00:04:54.440 --> 00:04:57.440
но если вам нужно защитить связь между API, это решение уже встроено.

00:04:57.560 --> 00:05:01.180
Эти три сценария охватывают практически все ситуации с внешними идентификаторами,

00:05:01.300 --> 00:05:02.340
с которыми вы столкнетесь.

00:05:02.480 --> 00:05:06.180
Но вам нужно принять важное решение, где именно будут находиться эти пользователи.

00:05:06.280 --> 00:05:08.940
Потому что External ID может работать в двух разных средах,

00:05:09.100 --> 00:05:11.140
в рабочем арендаторе или во внешнем арендаторе.

00:05:11.280 --> 00:05:12.780
Давайте разберем эти два варианта.

00:05:12.780 --> 00:05:15.920
External ID может работать внутри вашего существующего рабочего арендатора

00:05:15.920 --> 00:05:17.720
или как полностью отдельный внешний арендатор.

00:05:17.720 --> 00:05:21.120
Это не одно и то же, и неправильный выбор может вызвать проблемы в будущем.

00:05:21.280 --> 00:05:23.020
Начнем с варианта рабочего арендатора.

00:05:23.200 --> 00:05:26.140
У вашей компании уже есть арендатор интро-ID для сотрудников.

00:05:26.280 --> 00:05:27.800
Это и есть ваш рабочий арендатор.

00:05:27.960 --> 00:05:30.940
Если вы включите функцию самостоятельной регистрации гостевых пользователей,

00:05:31.060 --> 00:05:33.140
они смогут зарегистрироваться и попасть в тот же каталог,

00:05:33.380 --> 00:05:34.540
где находятся ваши сотрудники.

00:05:34.700 --> 00:05:37.800
Их учетные записи окажутся рядом с учетной записью вашего генерального директора.

00:05:38.000 --> 00:05:41.640
Для простых B2B-сценариев, таких как приглашение нескольких партнеров на сайт SharePoint,

00:05:41.900 --> 00:05:43.980
совместное размещение в одном каталоге вполне допустимо.

00:05:43.980 --> 00:05:47.060
Это просто настроить, и вам не нужно управлять отдельным арендатором.

00:05:47.160 --> 00:05:48.080
Но есть один нюанс.

00:05:48.300 --> 00:05:50.740
Если вы создаете клиентское приложение с тысячами пользователей,

00:05:50.920 --> 00:05:54.100
вы вряд ли захотите, чтобы эти клиенты находились в одном каталоге с сотрудниками.

00:05:54.220 --> 00:05:55.420
Это риск для безопасности.

00:05:55.620 --> 00:05:58.060
Сотрудник может случайно получить доступ к данным клиентов.

00:05:58.200 --> 00:06:00.280
Изменение конфигурации, предназначенное для сотрудников,

00:06:00.460 --> 00:06:01.660
может повлиять на доступ клиентов.

00:06:01.820 --> 00:06:04.220
А брендирование страниц входа для клиентов будет привязано к тому,

00:06:04.400 --> 00:06:05.660
что вы настроили для своей компании.

00:06:05.840 --> 00:06:06.760
Это не лучший вариант.

00:06:07.140 --> 00:06:09.060
Альтернатива – вариант с внешним арендатором.

00:06:09.060 --> 00:06:12.480
Вы создаете новый изолированный каталог специально для идентификаторов клиентов.

00:06:12.660 --> 00:06:13.680
Здесь нет сотрудников.

00:06:13.840 --> 00:06:15.440
Это полностью обособленное пространство.

00:06:15.600 --> 00:06:17.480
Помните аналогию с офисным зданием изначало.

00:06:17.660 --> 00:06:19.560
Рабочий арендатор – это ваш головной офис.

00:06:19.740 --> 00:06:23.240
Внешний арендатор – это отдельный магазин, который вы открываете для своих клиентов.

00:06:23.400 --> 00:06:26.480
У них свой вход, свои правила и своя система безопасности.

00:06:26.680 --> 00:06:27.700
Ничего не смешивается.

00:06:27.940 --> 00:06:30.100
Итак, каковы преимущества внешнего арендатора?

00:06:30.240 --> 00:06:32.880
Во-первых, вы получаете изолированное хранилище пользователей.

00:06:33.100 --> 00:06:35.260
Данные клиентов полностью отделены от данных сотрудников,

00:06:35.500 --> 00:06:37.600
что снижает риски и упрощает соблюдение требований.

00:06:37.600 --> 00:06:39.840
Во-вторых, вы получаете отдельный брендинг.

00:06:39.940 --> 00:06:43.200
Вы можете настроить внешний вид страниц входа специально для своих клиентов,

00:06:43.400 --> 00:06:45.380
не затрагивая ничего в корпоративном клиенте.

00:06:45.480 --> 00:06:48.500
В-третьих, вы получаете собственные API-аутентификации для мобильных приложений,

00:06:48.600 --> 00:06:52.220
которые позволяют создавать полностью уникальные экраны входа в вашем приложении для iOS или Android.

00:06:52.340 --> 00:06:54.880
Никаких перенаправлений в браузер или неудобных веб-представлений.

00:06:55.020 --> 00:06:58.440
И в-четвертых, вы получаете ценообразование на основе MAU ежемесячно активных пользователей.

00:06:58.580 --> 00:07:01.820
Вы платите только за тех пользователей, которые действительно проходят аутентификацию в данном месяце,

00:07:01.820 --> 00:07:04.120
что естественным образом масштабируется с ростом вашей клиентской базы.

00:07:04.240 --> 00:07:05.600
Итак, когда и что выбирать?

00:07:05.760 --> 00:07:06.600
Все довольно просто.

00:07:06.820 --> 00:07:10.840
Если вы создаете B2C-приложение с тысячами клиентов, выбирайте внешний клиент – External Tenant.

00:07:10.960 --> 00:07:14.140
Это рекомендуемый подход, и именно для этого был разработан External ID.

00:07:14.380 --> 00:07:17.260
Если вы просто приглашаете партнеров для доступа к внутренним ресурсам,

00:07:17.400 --> 00:07:18.980
подойдет вариант с рабочим клиентом.

00:07:19.140 --> 00:07:21.880
Главное – понять разницу до того, как вы начнете разработку,

00:07:22.080 --> 00:07:25.080
поскольку перенос из одного в другой впоследствии – задача не из легких.

00:07:25.520 --> 00:07:27.620
Безопасность, MFA и условный доступ.

00:07:27.740 --> 00:07:29.560
Теперь давайте поговорим о безопасности.

00:07:29.560 --> 00:07:31.980
Если вы собираетесь пускать клиентов в свое приложение,

00:07:32.160 --> 00:07:34.100
нужно убедиться, что туда не попадут посторонние.

00:07:34.240 --> 00:07:37.720
External ID включает в себя те же функции безопасности корпоративного уровня,

00:07:37.780 --> 00:07:39.420
что и IntraID предлагает для сотрудников.

00:07:39.560 --> 00:07:43.980
Это означает многофакторную аутентификацию, условный доступ и политики на основе рисков.

00:07:44.140 --> 00:07:45.980
Для MFA у вас сейчас есть два варианта.

00:07:46.140 --> 00:07:48.560
Одноразовый пароль по электронной почте предоставляется бесплатно.

00:07:48.720 --> 00:07:51.920
Система отправляет код на электронную почту пользователя, он вводит его, и все готово.

00:07:52.040 --> 00:07:54.480
Одноразовый SMS-пароль работает так же, но приходит на телефон,

00:07:54.680 --> 00:07:56.320
и здесь учитываются затраты оператора связи.

00:07:56.320 --> 00:07:59.240
Стоит отметить, что поддержки Microsoft Authenticator пока нет.

00:07:59.560 --> 00:08:02.480
Это текущее ограничение, над которым Microsoft, вероятно, работает,

00:08:02.660 --> 00:08:04.160
но пока это только email или SMS.

00:08:04.400 --> 00:08:07.360
Условный доступ – это то, где начинаются самые интересные возможности.

00:08:07.520 --> 00:08:09.820
Вы можете задать правила, например, требовать MFA,

00:08:10.040 --> 00:08:11.840
если уровень риска входа средний или выше,

00:08:12.040 --> 00:08:14.520
или блокировать доступ из стран, с которыми вы не работаете.

00:08:14.760 --> 00:08:17.920
Система оценивает каждую попытку входа в режиме реального времени.

00:08:18.160 --> 00:08:21.700
Если кто-то пытается войти из места или с устройства, которые выглядят подозрительно,

00:08:21.920 --> 00:08:24.520
система может автоматически повысить требования безопасности,

00:08:24.520 --> 00:08:26.780
не заставляя вас самостоятельно внедрять эту логику.

00:08:26.780 --> 00:08:30.380
Но есть одна функция, которая действительно выделяется – пошаговая аутентификация.

00:08:30.560 --> 00:08:31.380
Вот как это работает.

00:08:31.580 --> 00:08:34.200
Представьте, что пользователь входит в ваше приложение только с паролем,

00:08:34.360 --> 00:08:35.640
чтобы просмотреть каталог продукции.

00:08:35.800 --> 00:08:37.540
Это подходит для действий с низким уровнем риска,

00:08:37.700 --> 00:08:40.580
но когда пользователь пытается просмотреть историю платежей или скачать счет,

00:08:40.740 --> 00:08:42.120
вам требуется дополнительная проверка.

00:08:42.300 --> 00:08:44.520
Благодаря поэтапной аутентификации вы можете требовать MFA

00:08:44.520 --> 00:08:46.400
только для определенных разделов вашего приложения.

00:08:46.560 --> 00:08:48.060
Пользователю не будет приходить запрос до тех пор,

00:08:48.200 --> 00:08:50.140
пока он не попытается получить доступ к конфиденциальным данным.

00:08:50.140 --> 00:08:52.560
Все это обрабатывается external ID в фоновом режиме

00:08:52.560 --> 00:08:54.980
с использованием так называемого контекста аутентификации.

00:08:55.160 --> 00:08:58.340
Вы определяете, какие части вашего приложения требуют повышенной защиты,

00:08:58.540 --> 00:08:59.840
а система берет на себя остальное.

00:09:00.000 --> 00:09:02.360
Пользователь получает удобство при обычном просмотре,

00:09:02.560 --> 00:09:04.740
но конфиденциальные данные остаются под защитой.

00:09:04.920 --> 00:09:06.440
Брендинг и пользовательский опыт.

00:09:06.660 --> 00:09:08.620
Контроль над брендингом – одна из главных причин,

00:09:08.800 --> 00:09:12.640
по которой организации выбирают external ID вместо создания собственной системы входа.

00:09:12.760 --> 00:09:15.700
Вы получаете полный контроль над внешним видом страниц регистрации и входа.

00:09:15.700 --> 00:09:17.580
Можете загрузить логотип, задать светофона,

00:09:17.720 --> 00:09:19.120
добавить фавикон для вкладки браузера,

00:09:19.120 --> 00:09:23.620
а также настроить верхний и нижний колонн титулы со ссылками на политику конфиденциальности и условия использования.

00:09:23.800 --> 00:09:25.200
Если вам нужно еще больше контроля,

00:09:25.300 --> 00:09:29.040
вы можете загрузить собственный CSS-файл для изменения шрифтов, цветов кнопок и макета.

00:09:29.180 --> 00:09:30.580
Это ваш бренд, ваши цвета.

00:09:30.760 --> 00:09:31.760
Вы все решаете сами.

00:09:31.880 --> 00:09:33.400
А вот здесь начинаются сложности.

00:09:33.600 --> 00:09:36.640
Брендинг настраивается глобально для арендатора, а не для каждого приложения отдельно.

00:09:36.700 --> 00:09:38.080
Поэтому, если у вас несколько приложений,

00:09:38.180 --> 00:09:39.760
например, клиентский портал и мобильное приложение,

00:09:39.880 --> 00:09:41.800
все они будут использовать одни и те же брендированные страницы.

00:09:41.920 --> 00:09:44.200
Вы не можете придать каждому приложению свой уникальный стиль.

00:09:44.200 --> 00:09:47.460
Старый Azure AdBad 2C позволял настраивать брендинг для каждого приложения,

00:09:47.660 --> 00:09:49.340
но External ID пока это не поддерживает.

00:09:49.460 --> 00:09:52.860
Еще одно ограничение — сообщение об ошибках на страницах входа нельзя настроить.

00:09:53.020 --> 00:09:55.060
Если пользователь введет несуществующий адрес электронной почты,

00:09:55.160 --> 00:09:58.200
он увидит что-то вроде «Мы не смогли найти учетную запись с этим адресом электронной почты».

00:09:58.200 --> 00:09:59.660
И вы не можете изменить этот текст.

00:09:59.860 --> 00:10:01.340
Для некоторых организаций это нормально,

00:10:01.500 --> 00:10:03.880
но для других, особенно работающих в регулируемых отраслях

00:10:03.880 --> 00:10:06.240
или имеющих строгий фирменный стиль, это настоящая проблема.

00:10:06.460 --> 00:10:08.420
Для мобильных приложений есть вариант получше.

00:10:08.580 --> 00:10:11.980
External ID имеет API для нативной аутентификации в iOS и Android.

00:10:11.980 --> 00:10:14.600
Вместо перенаправления пользователей на страницу входа в браузере,

00:10:14.680 --> 00:10:17.700
вы можете создать полностью кастомные экраны входа прямо внутри приложения.

00:10:17.860 --> 00:10:20.500
Никаких перенаправлений в браузер или неуклюжих веб-представлений.

00:10:20.660 --> 00:10:24.040
Пользователь остается внутри вашего приложения, и вы контролируете каждый пиксель.

00:10:24.180 --> 00:10:26.640
Это гораздо более плавный опыт, и это одна из функций,

00:10:26.760 --> 00:10:28.680
которой никогда не было в Azure AdBad 2C.

00:10:28.960 --> 00:10:30.620
Миграция с Azure AdBad 2C.

00:10:30.780 --> 00:10:32.660
Если вы уже используете Azure AdBad 2C,

00:10:32.860 --> 00:10:34.860
вам наверняка интересно, что это значит для вас.

00:10:35.000 --> 00:10:35.700
Вот в чем суть.

00:10:35.860 --> 00:10:39.120
Microsoft продолжит поддерживать B2C как минимум до 2030 года.

00:10:39.120 --> 00:10:41.680
Так что ваши текущие арендаторы не перестанут работать завтра,

00:10:41.820 --> 00:10:43.060
но новых функций больше не будет.

00:10:43.180 --> 00:10:45.680
Все инновации, ключи доступа, нативная аутентификация,

00:10:45.880 --> 00:10:48.180
защита от мошенничества доступны только в External ID.

00:10:48.380 --> 00:10:50.820
Вы находитесь на платформе, которая по сути заморожена.

00:10:50.960 --> 00:10:53.760
Microsoft выпустила официальные инструменты и руководство по миграции,

00:10:53.960 --> 00:10:55.900
предлагающие два пути в зависимости от масштаба.

00:10:56.020 --> 00:10:59.060
Для тенантов, содержащих менее 5 миллионов объектов каталога,

00:10:59.160 --> 00:11:01.260
пользователей, групп, пользовательских атрибутов,

00:11:01.400 --> 00:11:02.960
стандартная миграция довольно проста.

00:11:03.120 --> 00:11:05.100
Она работает как перенос между тенантами.

00:11:05.100 --> 00:11:09.300
Вы создаете новый тенант External ID, переносите пользователей и их учетные данные,

00:11:09.460 --> 00:11:11.180
а затем переключаете свои приложения.

00:11:11.320 --> 00:11:15.020
Microsoft предоставляет инструменты для массового экспорта и импорта пользователей,

00:11:15.160 --> 00:11:18.660
а также миграцию паролей по запросу, чтобы минимизировать перебой в работе.

00:11:18.800 --> 00:11:21.240
Для крупных тенантов с более чем 5 миллионами объектов

00:11:21.240 --> 00:11:24.160
существует режим высокомаштабируемой совместимости – HSC.

00:11:24.360 --> 00:11:28.940
В этом режиме Azure Red B2C и External ID работают параллельно в одном и том же тенанте.

00:11:29.140 --> 00:11:32.080
Ваши существующие конечные точки B2C остаются активными,

00:11:32.080 --> 00:11:33.980
пока вы постепенно переносите приложение.

00:11:34.120 --> 00:11:38.100
Он предназначен для организаций, которые не могут перенести миллионы пользователей за одну ночь,

00:11:38.260 --> 00:11:39.260
но требует компромиссов.

00:11:39.360 --> 00:11:41.400
Отсутствие социальных провайдеров, ключей доступа,

00:11:41.500 --> 00:11:44.440
ограниченный условный доступ и некоторые другие функции просто недоступны.

00:11:44.580 --> 00:11:47.360
Рассматривайте это как промежуточную стратегию, а не постоянное решение.

00:11:47.500 --> 00:11:48.660
Теперь о важном изменении.

00:11:48.940 --> 00:11:50.440
Пользовательские политики исключены.

00:11:50.620 --> 00:11:53.820
Если вы создавали сложные процессы аутентификации на базе XML фреймворка

00:11:53.820 --> 00:11:55.520
Identity Experience в Azure Red B2C,

00:11:55.680 --> 00:11:57.040
они не будут работать в External ID.

00:11:57.220 --> 00:11:59.580
Вам придется перестроить эту логику с помощью потоков пользователей

00:11:59.580 --> 00:12:01.220
и пользовательских расширений аутентификации.

00:12:01.400 --> 00:12:04.340
Не существует волшебного инструмента, который преобразует ваш XML в новый формат.

00:12:04.440 --> 00:12:06.320
Вам просто придется выполнить эту работу самостоятельно.

00:12:06.440 --> 00:12:07.640
Итак, к чему все сводится?

00:12:07.820 --> 00:12:10.200
Если вы начинаете с нуля сегодня, используйте External ID.

00:12:10.420 --> 00:12:12.140
Нет причин даже рассматривать B2C.

00:12:12.320 --> 00:12:15.700
Если у вас есть существующий тенант B2C, начните планировать миграцию прямо сейчас.

00:12:15.860 --> 00:12:18.880
У вас есть время до 2030 года, но если откладывать на последний момент,

00:12:19.040 --> 00:12:22.500
придется спешно выполнять сложную миграцию, параллельно поддерживая работу текущих приложений.

00:12:22.660 --> 00:12:23.500
Начните с малого.

00:12:23.700 --> 00:12:26.940
Выберите одно приложение, перенесите его, протестируйте, извлеките уроки,

00:12:26.940 --> 00:12:28.100
а затем сделайте остальное.

00:12:28.320 --> 00:12:30.080
Опыт разработчиков и автоматизация

00:12:30.080 --> 00:12:33.660
Microsoft уделила много внимания удобству External ID для разработчиков,

00:12:33.760 --> 00:12:36.860
и это огромный шаг вперед по сравнению со старыми политиками B2C.

00:12:37.020 --> 00:12:41.480
Помните те XML-файлы, которые растягивались на сотни строк и ломались из-за одной пропущенной скобки?

00:12:41.620 --> 00:12:42.400
Этого больше нет.

00:12:42.560 --> 00:12:46.460
Появилось расширение для Visual Studio Code под названием Microsoft Intra External ID.

00:12:46.660 --> 00:12:50.140
После аутентификации вы можете просматривать свой тенант, потоки пользователей,

00:12:50.340 --> 00:12:54.020
скачивать их в формате JSON и даже проверять брендинг, не выходя из редактора.

00:12:54.020 --> 00:12:57.480
Вы видите, как выглядит страница входа еще до ее публикации.

00:12:57.620 --> 00:12:59.660
Кроме того, есть Microsoft Graph API.

00:12:59.840 --> 00:13:05.220
Почти каждым ресурсом External ID, потоками пользователей, регистрацией приложений, брендингом можно управлять программно.

00:13:05.320 --> 00:13:10.460
Это означает, что вы можете автоматизировать настройку тенанта в своих CI, CD-конвейерах с помощью PowerShell или REST-запросов.

00:13:10.560 --> 00:13:15.520
Создавайте новый клиент, настраивайте потоки пользователей, регистрируйте приложения и брендинг – все с помощью скрипта.

00:13:15.660 --> 00:13:18.460
Если вы управляете несколькими средами, это экономит массу времени.

00:13:18.660 --> 00:13:21.700
Пользовательские расширения аутентификации – вот где кроется настоящая сила.

00:13:21.700 --> 00:13:26.280
Вместо сложного XML вы расширяете потоки аутентификации простыми HTTP вызовами Azure Functions.

00:13:26.460 --> 00:13:28.880
Существует четыре события, к которым можно подключиться.

00:13:29.060 --> 00:13:34.100
Начало выдачи токена позволяет добавлять в токены пользовательские утверждения, такие как роли или уровень лояльности.

00:13:34.280 --> 00:13:39.800
Начало и отправка сбора атрибутов позволяют проверять или предзаполнять данные регистрации, обращаясь к вашему бэкенту.

00:13:39.880 --> 00:13:43.280
А отправка одноразового пароля по почте позволяет настроить письма для верификации.

00:13:43.460 --> 00:13:47.000
Это та же гибкость, что была в B2C, но в модели, с которой справится любой разработчик.

00:13:47.140 --> 00:13:48.920
Есть ограничения, о которых стоит знать.

00:13:48.920 --> 00:13:54.100
Уведомлений Microsoft Graph пока нет, поэтому вы не можете автоматически запустить рабочий процесс при регистрации нового пользователя.

00:13:54.300 --> 00:13:58.920
Некоторые настройки все еще нужно выполнять вручную в центре, и встроенной странице редактирования профиля нет.

00:13:59.040 --> 00:14:04.220
Если нужно, чтобы пользователи обновляли информацию, создайте эту страницу в приложении и вызывайте Graph API самостоятельно.

00:14:04.300 --> 00:14:05.440
Но направление очевидно.

00:14:05.560 --> 00:14:08.840
Microsoft стремится к тому, чтобы External ID можно было полностью автоматизировать.

00:14:09.000 --> 00:14:11.060
Это упрощает управление при масштабировании.

00:14:11.260 --> 00:14:18.060
Теперь вы знаете, Microsoft Intra External ID – это современная замена Azure Red B2C, объединенная под брендом Intra.

00:14:18.060 --> 00:14:25.060
Три сценария – идентификация клиентов, сотрудничество с партнерами и взаимодействие между машинами – покрывают почти все внешние потребности.

00:14:25.800 --> 00:14:30.040
Ключевое решение – использовать корпоративный клиент или создать отдельный внешний клиент.

00:14:30.200 --> 00:14:33.540
Для приложений, ориентированных на клиентов, отдельный клиент почти всегда лучше.

00:14:33.840 --> 00:14:36.220
Идентификация – это парадная дверь вашего приложения.

00:14:36.360 --> 00:14:42.020
Правильная, безопасная, брендированная и простая настройка напрямую влияет на доверие пользователей и рост бизнеса.

00:14:42.020 --> 00:14:45.400
Ваши домашние задания – перейдите на intro.microsoft.com.

00:14:45.600 --> 00:14:48.300
Создайте внешний клиент и попробуйте руководство по началу работы.

00:14:48.480 --> 00:14:51.320
Оно поможет вам настроить пример приложения за считанные минуты.

00:14:51.420 --> 00:14:55.140
Подписывайтесь, чтобы получать больше простых разборов платформы и идентификации Microsoft.