# Настройка единого входа > Раздел «Единый вход»: подключение по OIDC или SAML 2.0, данные для провайдера, метаданные SP, проверка входа. Примеры для Keycloak, AD FS и Entra ID. Всё настраивается в [Настройках](/docs/settings) → выбрать организацию → раздел **«Единый вход»**. Раздел доступен только **владельцу организации**. _Иллюстрация: Раздел «Единый вход»: протокол, поля провайдера, политика участников и — ниже — наши данные для настройки на стороне провайдера._ Настройка идёт в два шага, в любом порядке: зарегистрировать Buff **у провайдера** и указать данные провайдера **в Buff**. Данные для первого шага — блок **«Данные для настройки на стороне провайдера»** внизу раздела; каждое значение копируется одной кнопкой. ## OIDC Зарегистрируйте у провайдера **конфиденциальный клиент** (с секретом) для потока **Authorization Code**; PKCE (S256) Buff использует всегда — если провайдер требует включить его явно, включите. Укажите провайдеру: | Параметр у провайдера | Значение | | --- | --- | | Redirect URI (URI перенаправления, callback) | из блока «Данные для настройки» — вида `https://buff.systems/app/sso/callback` | | Grant / поток | Authorization Code | | PKCE | S256 | | Scopes | `openid email profile` | Затем в Buff: | Поле | Что указать | | --- | --- | | **Issuer URL** | адрес провайдера, по которому доступен `/.well-known/openid-configuration`. Buff читает документ автоматически: конечные точки, ключи подписи. | | **Client ID** | идентификатор зарегистрированного клиента | | **Client secret** | его секрет. Хранится в зашифрованном виде и **никогда не показывается** обратно; чтобы сменить — впишите новый, чтобы оставить — не трогайте поле | | **Scopes** | по умолчанию `openid email profile`; `openid` обязателен, `email` нужен, чтобы создавать аккаунты и привязывать существующие | При сохранении Buff обращается к провайдеру за документом обнаружения: недоступный адрес или неверный секрет вернут ошибку сразу, а не при первом входе сотрудника. _Иллюстрация: Подключение по OIDC сохранено: секрет не показывается, ниже — «Проверить вход» и данные для провайдера._ ### Keycloak Clients → Create client: тип **OpenID Connect**, Client authentication **On**, Standard flow **On**, Direct access grants **Off**. Valid redirect URIs — наш Redirect URI. Issuer URL для Buff — `https:///realms/`; Client secret — на вкладке Credentials. Во вкладке Advanced можно выставить Proof Key for Code Exchange Code Challenge Method = S256. ### Microsoft Entra ID App registrations → New registration; Redirect URI платформы **Web** — наш Redirect URI. Certificates & secrets → New client secret. Issuer URL — `https://login.microsoftonline.com//v2.0`, Client ID — Application (client) ID. Убедитесь, что в токене есть `email` (Token configuration → Add optional claim → ID → email), иначе Buff запросит его через userinfo. ### AD FS AD FS по умолчанию выдаёт минимальные ID-токены: удобнее подключаться по **SAML** (ниже). Для OIDC создайте Application Group типа Server application + Web API, разрешите scope `openid` и `email`, добавьте правила выпуска утверждений для email; Issuer URL — `https:///adfs`. ## SAML 2.0 Зарегистрируйте у провайдера **Service Provider** (Relying Party Trust в AD FS, SAML client в Keycloak, Enterprise application в Entra ID) с нашими данными: | Параметр у провайдера | Значение | | --- | --- | | Entity ID / Identifier / Audience | из блока «Данные для настройки» — вида `https://buff.systems/app/saml/<организация>` (у каждой организации свой) | | Assertion Consumer Service (ACS, Reply URL), binding **HTTP-POST** | из блока «Данные для настройки» — вида `https://buff.systems/app/sso/saml/acs` | | Подпись | **утверждение (Assertion) должно быть подписано**, алгоритм SHA-256. Подпись всего ответа не обязательна | | NameID | стабильный идентификатор — формат `persistent` (рекомендуется) или другой неизменяемый | | Атрибуты | `email` — обязательно (имя атрибута `email`, `mail` или стандартный URI-клейм); имя — по желанию | | Подпись запросов от Buff | не требуется (Buff не подписывает AuthnRequest) | Проще всего дать провайдеру готовый файл: после сохранения SAML-подключения в разделе появляется кнопка **«Скачать метаданные SP»** — XML с Entity ID и адресом ACS. Затем в Buff: | Поле | Что указать | | --- | --- | | **SSO URL провайдера** | адрес единого входа (SingleSignOnService с binding HTTP-Redirect), например `https:///realms//protocol/saml` или `https:///adfs/ls/` | | **Entity ID провайдера** | необязательно; если указан — проверяется издатель утверждения | | **Формат NameID** | какой формат запрашивать у провайдера; по умолчанию persistent | | **Сертификат подписи провайдера (PEM)** | сертификат, которым провайдер подписывает утверждения. Можно вставить несколько подряд — старый и новый на время ротации | _Иллюстрация: Подключение по SAML 2.0: адрес единого входа, сертификат провайдера; ниже — Entity ID, ACS и метаданные SP для провайдера._ ### Keycloak Clients → Create client: тип **SAML**, Client ID = наш Entity ID. Settings: Valid redirect URIs и Master SAML Processing URL = наш ACS; Name ID format = persistent; Force POST binding = On. Keys: Client signature required = **Off**. Signature and Encryption: **Sign assertions = On**, Signature algorithm RSA_SHA256. Client scopes → добавьте mapper типа User Property: Property `email`, SAML Attribute Name `email`, Name Format Basic. Сертификат подписи realm — Realm settings → Keys → RS256 → Certificate (это тело PEM без заголовков: добавьте строки `-----BEGIN CERTIFICATE-----` / `-----END CERTIFICATE-----`) или из `/realms//protocol/saml/descriptor`. ### AD FS Add Relying Party Trust → Enter data manually → Identifier = наш Entity ID; SAML 2.0 WebSSO, Relying party SAML 2.0 SSO service URL = наш ACS. Claim Issuance Policy: правило LDAP Attributes → E-Mail-Addresses → **E-Mail Address**; правило Transform → E-Mail Address → **Name ID** с форматом Persistent Identifier (или оставьте email как NameID — тогда выберите в Buff формат emailAddress). Сертификат — Service → Certificates → **Token-signing** → экспорт Base-64 X.509. SSO URL — `https:///adfs/ls/`. ### Microsoft Entra ID Enterprise applications → New application → Create your own → Integrate any other application (Non-gallery) → Single sign-on → SAML. Identifier = наш Entity ID, Reply URL = наш ACS. Attributes & Claims: Unique User Identifier — `user.objectid` или `user.mail`; добавьте клейм `email` = `user.mail`. SAML Signing Certificate → **Certificate (Base64)**. Login URL — в блок SSO URL провайдера. ## Проверить вход После сохранения ссылка **«Проверить вход»** открывает экран входа через SSO с уже заполненным именем организации в новой вкладке. Пройдите вход тестовым сотрудником: если провайдер вернул ошибку, она отобразится словами — см. [Устранение неполадок](/docs/sso/troubleshooting). Каждый шаг — настройка, начало входа, результат — виден в [журнале аудита](/docs/audit-log) организации. ## Смена провайдера и отключение Переключение протокола или провайдера — тем же разделом: сохраните новые данные, ранее созданные аккаунты останутся, но связи «сотрудник у провайдера ↔ аккаунт» установятся заново при следующем входе (по email — см. [Домены компании](/docs/sso/domains)). **«Отключить SSO»** удаляет подключение, подтверждённые домены и связи с провайдером. Аккаунты сотрудников остаются участниками организации; войти они смогут по паролю, установив его через «Забыли пароль?» (у созданных через SSO аккаунтов пароля не было).