Обзор аутентификации на порталах Power Apps
Примечание
Действует с 12 октября 2022 г, в качестве порталов для Power Apps используется Power Pages. Дополнительная информация: Microsoft Power Pages теперь доступен для всех (блог)
Скоро мы мигрируем и объединим документацию порталов Power Apps с документацией Power Pages.
На порталах Power Apps каждый аутентифицированный пользователь портала связан с записью контакта в Microsoft Dataverse. Пользователям портала должны быть назначены веб-роли, чтобы они могли получить более широкие разрешения, чем пользователи, которые не прошли проверку подлинности. Чтобы настроить разрешения для веб-роли, настройте для нее правила управления доступом к веб-страницам доступом к веб-сайтам. Порталы позволяют пользователям портала входить в систему, выбирая внешнюю учетную запись на основе идентификатора ASP.NET. Хотя это и не рекомендуется, порталы также позволяют пользователям входить в локальную учетную запись на основе членства в контактах.
Примечание
Power Pages также позволяет производителям настраивать аутентификацию. Дополнительные сведения: Что такое Power Pages
Примечание
Пользователи портала должны иметь уникальный адрес электронной почты. Если две или более записей контактов (включая деактивированные записи контактов) имеют один и тот же адрес электронной почты, контакты не смогут пройти аутентификацию на портале.
В следующей таблице перечислены общие поставщики удостоверений для порталов, протокол, который может использоваться с поставщиком, и соответствующая документация.
Важно!
Информация о конфигурации общих поставщиков для таких протоколов, как OpenID Connect и SAML 2.0, приведена в качестве примеров. Вы можете использовать этого поставщика по вашему выбору для данного протокола и выполнить аналогичные шаги для настройки вашего поставщика.
| Поставщик | Протокол | Документация |
|---|---|---|
| Azure Active Directory (Azure AD) | OpenID Connect | Azure AD с OpenID Connect |
| Azure AD | SAML 2.0 | Azure AD с SAML 2.0 |
| Azure AD | WS-Federation | Azure AD с WS-Federation |
| Azure AD B2C | OpenID Connect | Azure AD B2C с OpenID Connect Azure AD B2C с OpenID Connect (ручная настройка) |
| Службы федерации Azure Directory (AD FS) | SAML 2.0 | AD FS с SAML 2.0 |
| AD FS | WS-Federation | AD FS с WS-Federation |
| Microsoft | OAuth 2.0 | Корпорация Майкрософт |
| OAuth 2.0 | ||
| OAuth 2.0 | ||
| OAuth 2.0 | ||
| OAuth 2.0 | Twitter Примечание. Аутентификация Twitter для порталов временно недоступна из-за проблем с совместимостью. |
|
| Локальная проверка подлинности (не рекомендуется) |
Неприменимо | Локальная проверка подлинности |
Если вы уже используете существующего поставщика удостоверений и хотите перенести свой портал на использование другого поставщика удостоверений, ознакомьтесь с разделом Перенос поставщиков удостоверений. В этом примере показано, как перенести существующего поставщика удостоверений на Azure AD B2C, хотя вы можете использовать поставщика по вашему выбору для перехода на него.
Открытая регистрация
У администраторов порталов имеется несколько вариантов управления поведением регистрации учетной записи. Открытая регистрация — это наименее ограничивающая конфигурация регистрации, в которой портал позволяет регистрировать учетную запись пользователя, указав идентификатор пользователя. Альтернативные конфигурации могут требовать ,чтобы пользователь предоставил код приглашения или действительный адрес электронной почты для регистрации на портале. Независимо от конфигурации регистрации, локальные и внешние учетные записи участвуют в бизнес-процессе регистрации на равных правах. Пользователи могут выбрать, какой тип учетной записи они хотят зарегистрировать.
Во время регистрации пользователь имеет возможность выбрать внешнее удостоверение из списка поставщиков удостоверений или — в нерекомендуемом подходе — создать локальную учетную запись (указав имя пользователя и пароль). Если выбрано внешнее удостоверение, пользователь должен выполнить вход через выбранного поставщика удостоверений, чтобы доказать, что он является владельцем этой внешней учетной записи. Как в случае с внешним, так и с локальным поставщиком удостоверений пользователь немедленно регистрируется и аутентифицируется на портале. Новая запись контакта создается в среде Dataverse при регистрации.
Если включена открытая регистрация, пользователям не требуется предоставлять код приглашения, чтобы завершить процесс регистрации.
Следующий шаг
Начало работы с настройкой аутентификации для вашего портала
См. также
Настройка поставщика Azure AD B2C для порталов
Настройка поставщика OAuth 2.0 для порталов
Настройка поставщика OpenID Connect для порталов
Настройка поставщика SAML 2.0 для порталов
Настройка поставщика WS-Federation для порталов
Аутентификация и управление пользователями на порталах Power Apps
Примечание
Каковы ваши предпочтения в отношении языка документации? Пройдите краткий опрос (обратите внимание, что этот опрос представлен на английском языке).
Опрос займет около семи минут. Личные данные не собираются (заявление о конфиденциальности).
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по