← Cloudflare One / cloudflare-one / integrations / identity-providers

Универсальный OIDC

В Cloudflare Access есть универсальный коннектор OpenID Connect (OIDC), который поможет интегрировать IdP, ещё не настроенные в Access.

1. Создайте приложение в своём поставщике идентификации

Перейдите к своему поставщику идентификации и создайте клиент/приложение.
При создании клиента или приложения ваш IdP может запросить authorized redirect URI. Введите следующий URL-адрес:
```
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
```
Имя вашей команды можно найти в Панель управления Cloudflare ↗ в разделе Настройки > Название и домен команды > Название команды.
Скопируйте содержимое этих полей:
- Client ID
- Секрет клиента
- Auth URL: URL-адрес, который authorization_endpoint URL-адрес вашего IdP
- Token URL: URL-адрес, который token_endpoint URL-адрес вашего IdP
- URL-адрес сертификата: сертификат jwks_uri конечную точку вашего IdP, чтобы разрешить ключам IdP подписывать токены
Эти значения вы можете найти у вашего поставщика идентификации в Конечная точка обнаружения OIDC. Некоторые провайдеры называют это «well-known URL».

2. Добавьте поставщика OIDC в Cloudflare One

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Интеграции > Поставщики удостоверений.
В разделе Ваши поставщики идентификации, выберите Добавить нового поставщика идентификации.
Выберите OpenID Connect.
Назовите поставщика идентификации и заполните обязательные поля данными, полученными от вашего поставщика идентификации.
(Необязательно) Включите Proof of Key Exchange (PKCE) ↗ если протокол поддерживается вашим IdP. PKCE будет выполняться при каждой попытке входа.
(Необязательно) Чтобы включить SCIM, обратитесь к Синхронизируйте пользователей и группы.
(Необязательно) В разделе Необязательные конфигурации, введите пользовательские утверждения OIDC который вы хотите добавить к идентификации пользователей. Эта информация будет доступна в конечная точка идентификации пользователя.
Выберите Save.

Сделайте POST запрос к Поставщики идентификации конечная точка:

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Organizations, Identity Providers, and Groups Write

Добавление поставщика идентификации (IdP) для Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/identity_providers" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Generic OIDC example",
		"type": "oidc",
		"config": {
				"client_id": "<your client id>",
				"client_secret": "<your client secret>",
				"auth_url": "https://accounts.google.com/o/oauth2/auth",
				"token_url": "https://accounts.google.com/o/oauth2/token",
				"certs_url": "https://www.googleapis.com/oauth2/v3/certs",
				"pkce_enabled": false,
				"email_claim_name": "email",
				"claims": [
						"employeeID",
						"groups"
				],
				"scopes": [
						"openid",
						"email",
						"profile"
				]
		}
	}'

Добавьте следующее разрешение в свой cloudflare_api_token ↗:
- Access: Organizations, Identity Providers, and Groups Write

Настройте cloudflare_zero_trust_access_identity_provider ↗ ресурс:

resource "cloudflare_zero_trust_access_identity_provider" "generic_oidc_example" {
	account_id = var.cloudflare_account_id
	name       = "Generic OIDC example"
	type       = "oidc"
	config 		 = {
		client_id = "<your client id>"
		client_secret = "<your client secret>"
		auth_url = "https://accounts.google.com/o/oauth2/auth"
		token_url = "https://accounts.google.com/o/oauth2/token"
		certs_url = "https://www.googleapis.com/oauth2/v3/certs"
		pkce_enabled = false
		email_claim_name = "email"
		claims = ["employeeID", "groups"]
		scopes = ["openid", "email", "profile"]
	}
}

3. Проверьте подключение

Чтобы проверить, что подключение работает, перейдите в Аутентификация > Login methods и выберите Тест рядом с методом входа, который вы хотите протестировать. В случае успеха отобразится экран подтверждения.

Синхронизируйте пользователей и группы

Стандартная интеграция OIDC позволяет синхронизировать группы пользователей и автоматически лишать их доступа с помощью SCIM.

SCIM по-разному влияет на оценку политик Access и Gateway.

Access оценивает личность пользователя и членство в группах на основании утверждения SAML или токена OIDC, возвращённого поставщиком идентификации во время аутентификации. SCIM предоставляет читаемые названия групп в конструкторе политик Access, но Access не использует членство в группах SCIM для оценки входа. Если вы включите Включить отключение учётных записей пользователей, удаление пользователя из приложения SCIM аннулирует его активные сессии Access. Вы также можете настроить SCIM так, чтобы сессии аннулировались после изменения членства в группе. Access оценивает обновлённые данные поставщика идентификации при повторной аутентификации пользователя.

Gateway оценивает политики на основе личности по отношению к User Registry identity. SCIM обновляет эту идентификационную информацию при изменении пользователей или членства в группах, не дожидаясь повторной аутентификации пользователя. Профили устройств Cloudflare One Client используют ту же синхронизированную идентификационную информацию.

Предварительные требования

Ваш поставщик идентификации должен поддерживать версию SCIM 2.0.

1. Включите SCIM в Cloudflare One

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Интеграции > Поставщики удостоверений.
Найдите интеграцию IdP и выберите Изменить.
Включите Включите SCIM.
(Необязательно) Настройте следующие параметры:

Включить отключение учётных записей пользователей: Отозвать активную сессию пользователя когда их удаляют из приложения SCIM в IdP. Это аннулирует все активные сессии Access и потребует повторной аутентификации для всех Политики сессий Cloudflare One Client.
Удалить место пользователя при deprovisioning: Удалите место пользователя из вашей учётной записи Cloudflare One, когда они удаляются из SCIM-приложения в IdP.
Поведение SCIM при обновлении удостоверений: Выберите, что произойдёт в Cloudflare One при обновлении удостоверения пользователя в IdP.
- Автоматическое обновление удостоверений: Автоматически обновляйте User Registry identity когда IdP передаёт обновлённые данные идентификации или членства в группе через SCIM. Эта идентификация используется для политик Gateway и Cloudflare One Client профили устройств; Access считывает обновлённое удостоверение пользователя при повторной аутентификации.
- Повторная аутентификация при изменении состава группы: Отозвать активную сессию пользователя когда их членство в группе меняется в IdP. Это аннулирует все активные сессии Access и потребует повторной аутентификации для всех Политики сессий Cloudflare One Client. Access считает обновленное членство пользователя в группах при повторной аутентификации.
- Нет действия: Обновляйте идентификационные данные пользователя при следующей повторной аутентификации в Access или Cloudflare One Client.

Выберите Пересоздать секрет. Скопируйте SCIM Endpoint и SCIM Secret. Эти значения нужно будет ввести в IdP.
Выберите Save.

Секрет SCIM никогда не истекает, но вы можете вручную перегенерировать его в любой момент.

2. Настройте SCIM в IdP

Инструкции по настройке зависят от поставщика идентификации. В своём поставщике идентификации вам нужно будет либо изменить исходное приложение SSO или создать новое приложение SCIM. Подробнее см. в документации вашего поставщика идентификации. Пример инструкций см. в нашей Okta или Jumpcloud руководства.

группы IdP

Чтобы создавать политики на основе групп IdP, выполните следующее:

Убедитесь, что ваш IdP отправляет groups поле. Название должно совпадать точно (без учёта регистра). Все остальные значения будут отправлены как утверждение OIDC.
Если ваш IdP требует создания нового приложения SCIM, убедитесь, что его группы совпадают с группами в исходное приложение SSO. Сопоставление групп обеспечивает синхронизацию идентификационных данных Gateway с группами, которые возвращает IdP при аутентификации пользователя в Access.

3. Проверьте подготовку через SCIM

Чтобы проверить, обновились ли идентификационные данные пользователей в Cloudflare One, просмотрите журналы подготовки SCIM.

Необязательные конфигурации

Собственные утверждения OIDC

Все интеграции OIDC IdP поддерживают использование собственных утверждений OIDC. После настройки Access добавит эти утверждения в Access JWT для использования вашими исходными сервисами. Вы можете ссылаться на пользовательские заявки OIDC в Политики доступа и Политики Gateway, предоставляя способ управления доступом пользователей к приложениям на основе пользовательских атрибутов идентификации.

Чтобы добавить пользовательское утверждение OIDC в интеграцию IdP:

У своего поставщика идентификации убедитесь, что пользовательское утверждение включено в ваш OIDC ID-токен.
В Панель управления Cloudflare ↗, перейдите в Zero Trust > Интеграции > Поставщики удостоверений.
В разделе Ваши поставщики идентификации, найдите вашего провайдера идентификации и выберите Изменить.
В разделе Утверждения OIDC, введите имя вашего пользовательского утверждения (например, oid).
Выберите Save.
Выберите Тест и убедитесь, что пользовательский claim отображается в oidc_fields. Например,
```
	"oidc_fields": {
		"oid": "54eb1ed2-7150-44e6-bbe4-ead24c132fd4"
	},
```

Теперь для этого пользовательского claim можно создать политику Access с помощью Утверждение OIDC или IdP OIDC Claim селектор. Также можно использовать пользовательские claims OIDC в качестве селекторы на основе идентификации в политиках Gateway. Пользовательское утверждение будет передано источникам за Access в JWT.

Email-claim

Можно указать пользовательский Email-claim имя, которое Access будет использовать для идентификации адресов электронной почты пользователей. Это полезно, если ваш IdP не возвращает стандартный email утверждение в OIDC ID-токене.

Утверждения OIDC с несколькими записями

Cloudflare Access расширяет поддержку многозаписных утверждений OIDC. Такие утверждения разбираются на отдельные записи, на каждую из которых можно ссылаться в политиках по отдельности. Это обеспечивает более детальное управление доступом и точную авторизацию пользователей в приложениях.

Cloudflare Access не поддерживает ссылки на частичные значения утверждений OIDC или OIDC scopes.

Поддерживаемые алгоритмы для универсальных токенов OIDC

Cloudflare поддерживает следующие алгоритмы для проверки стандартных токенов OIDC:

RS512
RS256
PS512
ES256
ES384
ES512