Jednotné přihlášení

Jednotné přihlášení nechá externího poskytovatele identity (IdP) rozhodnout, kdo se smí přihlásit k tvému serveru Control Center. Podporované protokoly jsou dva — SAML 2.0 a OpenID Connect — a oba skončí na stejném místě: čerstvě vystavený přihlašovací údaj zařízení, který je ve všech navazujících vrstvách k nerozeznání od pozvánky nebo párování přes QR.

Jak přihlášení vypadá

Přihlášení přes SAML zprostředkovává prohlížeč. IdP se k tvému serveru nikdy sám nepřipojí; všechno nese prohlížeč uživatele:

browser ──> /saml/login ──> IdP ──POST SAMLResponse──> /saml/acs
                                                          │  verify
                                                          ▼
                                              provision user (maybe)
                                                          │
                                                          ▼
                                  browser handoff: device PSK in the URL
                                  fragment (never a query parameter)

Protože kurýrem je prohlížeč, server za NAT na přihlášení stačí: localhost, LAN, Tailscale, VPN i tunel poslouží a stačí, aby prohlížeč uživatele dosáhl na ACS URL. WebSocket relé, které používá vzdálené ovládání z telefonu, HTTP cestu tam a zpět unést neumí, a proto vstupní body SSO vždy míří na HTTP origin serveru.

OpenID Connect má stejný tvar, s oběhem authorization-code + PKCE. Claimy se čtou z token endpointu vydavatele přes TLS, takže údaje o identitě prohlížeč vůbec nedodává.

Adaptéry

Control Center tu odpovědnost schválně dělí:

Součást	Kde	Má na starosti
nativní cc_saml	packages/cc_natives/native/saml/	ověření XML-DSig, kanonikalizace, validace profilu SAML — předané připnutému crate saml v čistém Rustu za bezstavovým C ABI
SamlService / OidcService	cc_server_core	stav přihlášení (sledování čekajících požadavků, deduplikace přehrání), páčky politiky ověření, sdílené volání provisioningu
SsoProvisioner	cc_server_core	najde nebo založí uživatele, připne subjekt poskytovatele, udělí členství podle politiky automatického členství
ScimService	cc_server_core	plocha SCIM 2.0, na kterou IdP tlačí (životní cyklus provisioningu a deprovisioningu)
SsoSettingsService	cc_server_core	uložené řádky připojení, živé opětovné uplatnění, token SCIM

Schválně tu není kryptografický fallback pro SAML v čistém Dartu: ručně psané XML-DSig a kanonikalizace jsou přesně to místo, kde žijí zranitelnosti obalení podpisu, a chybějící knihovna cc_saml proto odmítne přihlášení přes SAML i start serveru. Nativní kód je schválně bezstavový — stav napříč požadavky žije ve službách v Dartu, jednorázově a krátce.

Co přihlášení ověřuje

V ověřeném nativním kódu a ve službě, v tomhle pořadí:

1. podpis assertion (vždy povinný; podpis obálky odpovědi je podle konfigurace volitelný) — strukturálně odolný proti obalení podpisu, protože ověřený obsah je vázaný na ověřený element,
2. vydavatel se shoduje s nakonfigurovaným IdP,
3. audience jmenuje tohoto poskytovatele služeb,
4. cíl je naše ACS URL,
5. InResponseTo se shoduje s čekajícím AuthnRequest, který jsme vydali (nevyžádané, IdP-iniciované odpovědi jsou ve výchozím stavu vypnuté),
6. okna životnosti drží v rámci odchylky hodin (výchozích 90 s) a
7. id assertion se tu ještě neobjevilo (cache proti přehrání).

Selhání se vracejí jako typované kódy — signature, expired, audience, destination, issuer, request-match — a endpointy odpovídají obecnou chybou, takže útočník se nedozví, proč padělek selhal.

Účty a připnutí subjektu

První přihlášení přes SSO připne neměnný subjekt poskytovatele (issuer plus SAML NameID / OIDC sub, nebo SCIM externalId) k účtu. Od té chvíle přihlášení určuje subjekt, ne e-mail. Když později někdo jiný předloží stejný e-mail od téhož nebo od jiného IdP, připnutý účet ho odmítne. Recyklovaný e-mail u poskytovatele se tak nestane převzetím účtu.

Provisioning a deprovisioning

JIT provisioning proběhne při přihlášení (SsoProvisioner). SCIM je samostatná plocha, na kterou IdP tlačí (ScimService): připne k řádku uživatele stejný subjekt a členství v pracovních prostorech neuděluje. Deprovisioning — SCIM active: false nebo DELETE — účet odmítne, když je vlastník pracovního prostoru (vlastnictví nejdřív předej). Jinak nejdřív odvolá každý přihlašovací údaj zařízení (relace spadnou během sekund přes sledování zařízení), odebere každé členství v pracovním prostoru a účet označí jako deaktivovaný. Řádek uživatele zůstane: atribuce je trvalá. Reaktivace obnoví přihlášení a členství znovu neudělí.

Co zůstává mimo

• Mapování skupina→role proběhne při přihlášení z atributů SAML a claimů OIDC — skupiny natlačené přes SCIM se neukládají.
• Role vlastníka je ze SSO nedosažitelná — ani jako výchozí role, ani přes mapování skupin.
• WebSocket relé nikdy není kanál SSO. Telefon, který se k serveru dostane jen přes relé, proti němu cestu prohlížeče tam a zpět nedokončí.