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

Obecné OIDC

Cloudflare Access nabízí obecný konektor OpenID Connect (OIDC), pomocí kterého lze integrovat IdP, které ještě v Access nastavené nemáte.

1. Vytvořte aplikaci u vašeho poskytovatele identity

Přejděte ke svému poskytovateli identity a vytvořte klienta/aplikaci.
Při vytváření klienta/aplikace si váš IdP může vyžádat authorized redirect URI. Zadejte následující URL:
```
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
```
Název svého týmu najdete v Cloudflare dashboard ↗ v části Nastavení > Název a doména týmu > Název týmu.
Zkopírujte obsah těchto polí:
- Client ID
- Client secret
- Auth URL: Adresa URL, kterou authorization_endpoint URL adresa vašeho IdP
- Token URL: Adresa URL, kterou token_endpoint URL adresa vašeho IdP
- URL certifikátu: jwks_uri endpoint vašeho IdP, aby klíče IdP mohly podepisovat tokeny
Tyto hodnoty najdete u svého poskytovatele identity v OIDC discovery endpoint. Někteří poskytovatelé tomu říkají „well-known URL“.

2. Přidejte poskytovatele OIDC do Cloudflare One

V Cloudflare dashboard ↗, přejděte na Zero Trust > Integrace > Poskytovatelé identity.
V části Vaši poskytovatelé identity, vyberte Přidat nového poskytovatele identity.
Vyberte OpenID Connect.
Pojmenujte poskytovatele identity a vyplňte povinná pole údaji získanými od vašeho poskytovatele identity.
(Volitelné) Povolte Proof of Key Exchange (PKCE) ↗ pokud je protokol podporován vaším IdP. PKCE se provede při každém pokusu o přihlášení.
(Volitelné) Chcete-li povolit SCIM, přečtěte si Synchronizace uživatelů a skupin.
(Volitelné) V části Volitelné konfigurace, zadejte vlastní OIDC claimy které chcete přidat k identitě uživatelů. Tyto informace budou dostupné v endpoint uživatelské identity.
Vyberte Save.

Vytvořte POST požadavek na Poskytovatelé identity koncový bod:

Požadovaná oprávnění API tokenu

Alespoň jeden z následujících oprávnění tokenu je povinné:

Access: Organizations, Identity Providers, and Groups Write

Přidání poskytovatele identity pro 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"
				]
		}
	}'

Přidejte následující oprávnění do svého cloudflare_api_token ↗:
- Access: Organizations, Identity Providers, and Groups Write

Nakonfigurujte cloudflare_zero_trust_access_identity_provider ↗ prostředek:

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. Otestujte připojení

Chcete-li ověřit, že vaše připojení funguje, přejděte na Ověřování > Metody přihlášení a vyberte Test vedle metody přihlášení, kterou chcete otestovat. V případě úspěchu se zobrazí potvrzovací obrazovka.

Synchronizace uživatelů a skupin

Obecná integrace OIDC umožňuje synchronizovat uživatelské skupiny a automaticky provádět deprovisioning uživatelů pomocí SCIM.

SCIM ovlivňuje vyhodnocování zásad Access a Gateway odlišně.

Access vyhodnocuje identitu uživatele a členství ve skupinách na základě tvrzení SAML nebo tokenu OIDC vráceného poskytovatelem identity při ověřování. SCIM zobrazuje čitelné názvy skupin v tvůrci zásad Access, ale Access členství ve skupinách SCIM k vyhodnocení přihlášení nepoužívá. Pokud zapnete Povolte deprovisioning uživatelů, odebrání uživatele z aplikace SCIM odvolá jeho aktivní relace Access. SCIM můžete také nakonfigurovat tak, aby odvolávalo relace po změně členství ve skupině. Access vyhodnotí aktualizovaná data poskytovatele identity při příštím ověření uživatele.

Gateway vyhodnocuje zásady založené na identitě vůči User Registry identity. SCIM tuto identitu aktualizuje při každé změně uživatele nebo členství ve skupině, aniž by čekal, až se uživatel znovu ověří. Profily zařízení Cloudflare One Client používají stejnou synchronizovanou identitu.

Předpoklady

Váš poskytovatel identity musí podporovat SCIM verze 2.0.

1. Povolte SCIM v Cloudflare One

V Cloudflare dashboard ↗, přejděte na Zero Trust > Integrace > Poskytovatelé identity.
Najděte integraci IdP a vyberte Úprava.
Zapněte Povolení SCIM.
(Volitelné) Nakonfigurujte následující nastavení:

Povolte deprovisioning uživatelů: Odvolat aktivní relaci uživatele při jejich odebrání z aplikace SCIM v IdP. Tím dojde k invalidaci všech aktivních relací Access a k výzvě k opětovnému ověření u všech Zásady relací Cloudflare One Client.
Odebrat licenční místo uživatele při deprovisioningu: Odeberte licenční místo uživatele z vašeho účtu Cloudflare One, jakmile jsou odebráni z aplikace SCIM v IdP.
Chování při aktualizaci identity SCIM: Vyberte, co se stane v Cloudflare One, když se aktualizuje identita uživatele v IdP.
- Automatické aktualizace identity: Automaticky aktualizovat User Registry identity při odeslání aktualizované identity nebo členství ve skupině prostřednictvím SCIM ze strany IdP. Tato identita se používá pro zásady Gateway a Cloudflare One Client profily zařízení; Access přečte aktualizovanou identitu uživatele, jakmile se znovu ověří.
- Opětovné ověřování při změně členství ve skupině: Odvolat aktivní relaci uživatele při změně jejich členství ve skupině v IdP. Tím dojde k invalidaci všech aktivních relací Access a k výzvě k opětovnému ověření u všech Zásady relací Cloudflare One Client. Access při opětovném ověření uživatele načte jeho aktualizované členství ve skupině.
- Žádná akce: Aktualizujte identitu uživatele při jeho příštím opětovném ověření v Access nebo Cloudflare One Client.

Vyberte Regenerate Secret. Zkopírujte SCIM Endpoint a SCIM Secret. Tyto hodnoty budete muset zadat do IdP.
Vyberte Save.

Platnost tajného klíče SCIM nikdy nevyprší, ale kdykoli ho můžete ručně vygenerovat znovu.

2. Nakonfigurujte SCIM v IdP

Pokyny k nastavení se liší podle poskytovatele identity. U svého poskytovatele identity budete muset buď upravit původní aplikace SSO nebo vytvořit novou aplikaci SCIM. Podrobnosti najdete v dokumentaci vašeho poskytovatele identity. Příklad postupu najdete v naší Okta nebo Jumpcloud průvodci.

skupiny IdP

Pokud chcete vytvářet zásady na základě skupin IdP:

Ujistěte se, že váš IdP odesílá groups pole. Název musí přesně odpovídat (nerozlišují se velká a malá písmena). Všechny ostatní hodnoty budou odeslány jako OIDC claim.
Pokud váš IdP vyžaduje novou aplikaci SCIM, ujistěte se, že její skupiny odpovídají skupinám v původní aplikace SSO. Shoda skupin udržuje identitu Gateway synchronizovanou se skupinami, které vrátí IdP při ověření uživatele v Access.

3. Ověřte zajišťování SCIM

Chcete-li zkontrolovat, zda byly identity uživatelů v Cloudflare One aktualizovány, zobrazte si Protokoly zřizování SCIM.

Volitelné konfigurace

Vlastní OIDC claims

Všechny integrace OIDC IdP podporují vlastní deklarace OIDC. Po nakonfigurování Access tyto deklarace přidá do Access JWT pro potřeby vašich originových služeb. Vlastní OIDC claims můžete odkazovat v Zásady Access a Zásady Gateway, což nabízí způsob, jak řídit přístup uživatelů k aplikacím na základě vlastních atributů identity.

Přidání vlastního OIDC claimu do integrace IdP:

U svého poskytovatele identity zajistěte, aby vlastní claim byl součástí vašeho OIDC ID tokenu.
V Cloudflare dashboard ↗, přejděte na Zero Trust > Integrace > Poskytovatelé identity.
V části Vaši poskytovatelé identity, najděte svého poskytovatele identity a vyberte Úprava.
V části OIDC Claims, zadejte název svého vlastního claimu (například oid).
Vyberte Save.
Vyberte Test a ověřte, že se vlastní claim zobrazuje v oidc_fields. Například,
```
	"oidc_fields": {
		"oid": "54eb1ed2-7150-44e6-bbe4-ead24c132fd4"
	},
```

Nyní můžete pro vlastní claim sestavit zásadu Access pomocí OIDC Claim nebo IdP OIDC Claim selektor. Vlastní OIDC claimy můžete použít i jako selektory založené na identitě v zásadách Gateway. Vlastní claim se předá origin serverům za Access v JWT.

Email claim

Můžete zadat vlastní Email claim název, který Access použije k identifikaci e-mailů uživatelů. To je užitečné, pokud váš IdP nevrací standardní email claim v OIDC ID tokenu.

Vícezáznamové OIDC claims

Cloudflare Access rozšiřuje podporu o vícezáznamové OIDC claimy. Ty se rozpracují na jednotlivé položky, na které lze v zásadách odkazovat samostatně. Díky tomu lze v aplikacích nastavit podrobnější řízení přístupu a přesnější autorizaci uživatelů.

Cloudflare Access nepodporuje odkazy na částečné hodnoty OIDC claimů ani OIDC scopes.

Podporované algoritmy pro obecné tokeny OIDC

Cloudflare pro ověřování obecných tokenů OIDC podporuje následující algoritmy:

RS512
RS256
PS512
ES256
ES384
ES512