Uwierzytelnianie tenantów

Tenant SSO i odkrywanie tożsamości

Użytkownicy dashboardu tenant logują się przez jeden spokojny pierwszy krok: wpisanie adresu e-mail. Attesto wybiera potem właściwą ścieżkę password, community identity, organization SSO, invite albo signup bez pokazywania ściany enterprise providerów. Skonfigurowani community providers mogą też pojawić się jako convenience buttons pod email-first formularzem, nigdy nad nim i nigdy pomieszani z tenant enterprise SSO choices.

Scope

Ta strona opisuje main platform users na dashboard.attesto.eu. Marketplace developer accounts, auditor access oraz internal staff access są oddzielnymi powierzchniami tożsamości. Marketplace developer account nie daje dostępu do tenant dashboard, chyba że ta sama osoba jest także zaproszona jako tenant user.

Email discovery

Strona logowania zaczyna od pola e-mail. Backend zwraca rekomendowany następny krok, a dla nowego community signup może też zwrócić bezpieczne opcje availableProviders:

Password fallback dla istniejących password users.
Community identity, gdy istniejący user jest powiązany z Google, GitHub, GitLab albo LinkedIn.
Organization SSO, gdy domena e-mail pasuje do włączonego tenant provider.
Invite activation, gdy obecny jest invite token.
Signup albo trial onboarding dla nieznanych adresów e-mail.

User flow

Użytkownicy Enterprise SSO mogą też zacząć na auth.attesto.eu. Ta strona wykrywa tylko ścieżki tenant Entra/OIDC/SAML i odsyła użytkowników bez SSO do zwykłego logowania dashboard.

Tenant user nie wybiera między siedmioma providerami. Wpisuje służbowy e-mail, sprawdza wykrytą trasę i kontynuuje metodą skonfigurowaną dla tego adresu. Jeśli domena tenant jest kontrolowana przez organization SSO, przycisk mówi “Continue with your organization” albo pokazuje skonfigurowaną nazwę providera. Jeśli password fallback nadal jest dozwolony, istniejący password users mogą kontynuować przez password.

Otwórz dashboard.attesto.eu/login.
Wpisz adres e-mail tenanta.
Kontynuuj wykrytą ścieżką password, community identity, invite, signup albo organization SSO.
Wróć do dashboardu z istniejącą Attesto tenant session, ochroną CSRF i role checks.

Tenant owner setup

Tenant owners konfigurują enterprise identity providers w Settings → Identity Providers. Kreator przechowuje secrets po stronie serwera, pokazuje przeglądarce tylko zamaskowany status i generuje wartości callback albo metadata dla zewnętrznego providera. Provider setup należy przetestować zaproszonym userem, zanim SSO zostanie wymuszone dla domeny tenanta.

Provider	Kiedy używać	Attesto wymaga	Provider wymaga
Microsoft Entra ID	Enterprise workforce login	Domain, issuer, client id, encrypted client secret	Redirect URI i dozwolone users/groups
Generic OIDC	Okta, Keycloak, Ping, Auth0, ForgeRock albo custom OIDC	Domain, issuer URL, client id, encrypted client secret, scopes	Redirect URI i verified email claim
Generic SAML	Legacy enterprise SSO albo SAML-only IdPs	Domain, IdP entity id, SSO URL, signing certificate	SP Entity ID, ACS URL, signed response albo assertion

Providers

Community providers obsługują Google, GitHub, GitLab i LinkedIn. Enterprise providers obsługują Microsoft Entra ID, generic OIDC i generic SAML. Wybory enterprise providerów nie są pokazywane jako publiczna ściana przycisków; discovery rekomenduje właściwą tenant ścieżkę. Skonfigurowani community providers mogą pojawić się pod formularzem e-mail jako self-service shortcut. Katalog zawiera flagę configured, więc nieskonfigurowani providers są widoczni, ale inert, dopóki nie istnieją prawdziwe OAuth credentials.

Community providers są przydatni dla evaluatorów, developerów, inwestorów i konsultantów. Enterprise providers są tenant scoped: dopasowanie domeny określa, czy user ma trafić do organization SSO. Marketplace developer accounts pozostają oddzielone od tenant dashboard identities.

Microsoft Entra ID

Użyj Microsoft Entra ID, gdy klient chce, aby dostęp do dashboardu Attesto wynikał z Microsoft workforce identity, Conditional Access, MFA i account lifecycle policies. W Entra utwórz web application registration dla Attesto, dodaj Attesto redirect URI z kreatora dashboardu i utwórz client secret. W Attesto wybierz Entra, wpisz tenant domain, issuer/authority URL, client id i client secret.

Redirect type to web/confidential, nie public SPA.
Scopes powinny zawierać OpenID Connect identity claims, takie jak openid, email i profile.
Attesto wymaga verified email i sprawdza issuer, audience, nonce, state oraz PKCE.
Użyj Entra Conditional Access i MFA policies dla enterprise assurance.

Generic OIDC

Generic OIDC obejmuje Okta, Keycloak, Ping, Auth0, ForgeRock i innych standards-compliant identity providers. Provider musi wystawiać issuer discovery metadata i signing keys oraz zwracać stabilny subject i verified email claim. Attesto odkrywa authorization, token, userinfo i JWKS endpoints z issuer, gdy jest to wspierane.

Utwórz confidential/web OIDC app w identity provider.
Wklej dashboard-generated callback URL w providerze.
Skonfiguruj allowed scopes, zwykle openid email profile.
Zapisz issuer URL, client id i client secret w Attesto tenant settings.
Wykonaj jeden prawdziwy login zaproszonym userem przed włączeniem strict tenant policy.

Generic SAML

Generic SAML obsługuje środowiska enterprise używające SAML 2.0 zamiast OIDC. Attesto pokazuje SP metadata i ACS URLs z kreatora tenant settings. Zewnętrzny IdP musi podpisać response albo assertion oraz wysłać stabilny subject i email attribute dla zaproszonego tenant user.

Skopiuj Attesto SP metadata albo ręcznie wpisz Entity ID i ACS URL w IdP.
Skopiuj IdP Entity ID, SSO URL i signing certificate z powrotem do Attesto.
Utrzymuj assertions krótkotrwałe i zawierające audience, recipient oraz InResponseTo values.
Reject unsigned, expired, replayed, wrong-audience albo wrong-recipient assertions.

Enterprise SSO

Enterprise SSO jest tenant scoped. Konfiguracja providera wiąże jedną domenę tenant z jednym włączonym providerem Entra, OIDC albo SAML. Podczas discovery najpierw oceniane są invite token i istniejące identity links, potem tenant domain provider rules, a potem password albo signup fallback. To zapobiega losowemu wyborowi providera i utrzymuje ekran logowania prosty.

Tenant owners konfigurują enterprise SSO w ustawieniach dashboard w sekcji Identity Providers. Providerzy OIDC i Entra używają issuer metadata, client id, zaszyfrowanego client secret, strict redirect allowlists, PKCE, state, nonce, issuer, audience i verified-email checks. Providerzy SAML używają signed responses albo assertions, audience i recipient validation, InResponseTo replay protection oraz krótkiego clock skew.

Dashboard pokazuje wygenerowane wartości callback, aby tenant owners mogli skopiować je do zewnętrznego identity provider:

OAuth/OIDC callback:
https://auth.attesto.eu/v1/auth/external/callback/{provider_id}

SAML ACS:
https://auth.attesto.eu/v1/auth/saml/acs/{provider_id}

SAML metadata:
https://auth.attesto.eu/v1/auth/saml/metadata/{provider_id}

Publiczne docs celowo nie dokumentują internal staff admin procedures. Ta strona jest dla tenant-owned identity configuration i developer integration z tenant authentication endpoints.

Invites

Invite acceptance używa tego samego discovery model. Jeśli e-mail z invite należy do domeny tenant z required organization SSO, invite może kontynuować przez tego providera. Jeśli provider nie jest wymagany, user nadal może ustawić password przez istniejącą ścieżkę invite.

API contract

Te endpointy są dashboard tenant-auth endpoints. Frontend clients nigdy nie otrzymują provider secrets.

POST /v1/auth/discover
GET /v1/auth/providers
POST /v1/auth/external/start
GET /v1/auth/external/callback/{provider_id}
POST /v1/auth/saml/acs/{provider_id}
GET /v1/auth/saml/metadata/{provider_id}

{
  "email": "user@company.com",
  "returnTo": "/"
}

Discovery response mówi frontendowi, który pojedynczy następny krok wyrenderować. Provider secrets, client secrets, SAML certificates, tokens i assertions nigdy nie są zwracane do przeglądarki.

{
  "email": "user@company.com",
  "action": "organization_sso",
  "buttonLabel": "Continue with your organization",
  "providerId": "idp_...",
  "providerType": "oidc",
  "allowPassword": false,
  "allowSignup": false,
  "availableProviders": []
}

GET /v1/auth/providers zwraca tylko non-secret community provider labels i configuration state dla przycisków pod formularzem e-mail. POST /v1/auth/external/start może zostać wywołany tylko z providerId dla global community signup, ale tenant enterprise providers zawsze wymagają email- albo invite-backed discovery result.

Security

External login jest dozwolony tylko wtedy, gdy provider zwraca verified email, a identity może zostać powiązana z istniejącym tenant user, accepted invite albo explicit signup/trial creation. Provider secrets, SAML private settings, tokens, assertions i raw callbacks pozostają server-side. Audit events zapisują discovery, provider start, success, failure, provider changes i identity linking bez logowania raw secrets.

Control	Co wymusza Attesto
OAuth/OIDC state	Short-lived state, nonce i PKCE records są single-use.
OIDC token validation	Issuer, audience, JWKS signature, nonce i verified email są sprawdzane.
SAML replay protection	InResponseTo, audience, recipient, signature i clock skew są walidowane.
Identity linking	Tylko verified emails mogą linkować do istniejących users, accepted invites albo explicit signup/trial creation.
Secret handling	Provider secrets są szyfrowane server-side i maskowane w tenant settings.
Surface separation	Tenant dashboard users, marketplace developer accounts, auditors i internal staff auth pozostają oddzielnymi surfaces.

Troubleshooting

Objaw	Prawdopodobna przyczyna	Naprawa
User trafia do password zamiast SSO	Domain provider jest disabled, domain mismatch albo existing password identity ma precedence.	Sprawdź tenant domain, provider enabled state i pisownię invite email.
OIDC callback fails	Redirect URI, issuer, audience, nonce albo verified email claim nie pasuje.	Skopiuj generated callback dokładnie i sprawdź issuer/client configuration.
SAML assertion rejected	Unsigned, expired, replayed, wrong audience, wrong recipient albo brak email attribute.	Włącz signed responses/assertions i porównaj Entity ID, ACS URL oraz attributes.
Community provider button jest disabled	Provider jest w katalogu, ale `configured` ma wartość false.	Dodaj prawdziwy OAuth client id/secret zanim włączysz tę ścieżkę dla users.
User uwierzytelnia się, ale nie wchodzi do tenant	External identity nie jest powiązana z zaproszonym albo istniejącym tenant user.	Najpierw zaproś usera albo użyj explicit signup/trial path dla nowego tenanta.

Rollout checklist

Skonfiguruj provider domain i issuer values w tenant settings.
Skopiuj wygenerowany callback, ACS albo metadata URL do zewnętrznego providera.
Zaproś tenant user z tą domeną i wykonaj jeden prawdziwy login.
Potwierdź, że zewnętrzny provider zwraca oczekiwany verified email claim albo SAML email attribute.
Sprawdź, że password fallback nadal działa dla users, którzy go potrzebują.
Udokumentuj tenant-side MFA i access policy ownership z klientem.
Sprawdź audit events i tenant session behavior przed wymuszeniem SSO policy.