Autenticación de tenant

SSO tenant y descubrimiento de identidad

Los usuarios del dashboard tenant inician sesión con un primer paso sencillo: introducir una dirección de correo. Attesto selecciona después la ruta correcta de contraseña, identidad comunitaria, SSO de organización, invitación o signup sin mostrar un muro de botones de enterprise providers. Los community providers configurados también pueden aparecer como botones de conveniencia debajo del formulario email-first, nunca encima, y nunca mezclados con opciones tenant enterprise SSO.

Scope

Esta página cubre main platform users en dashboard.attesto.eu. Marketplace developer accounts, auditor access e internal staff access son superficies de identidad separadas. Un marketplace developer account no entra al tenant dashboard salvo que la misma persona también esté invitada como tenant user.

Email discovery

La página de login comienza con el campo de correo. El backend devuelve el siguiente paso recomendado y, para un nuevo community signup, también puede devolver opciones seguras availableProviders:

Password fallback para password users existentes.
Community identity cuando un user existente está vinculado a Google, GitHub, GitLab o LinkedIn.
Organization SSO cuando el dominio de correo coincide con un tenant provider habilitado.
Invite activation cuando hay un invite token presente.
Signup o trial onboarding para correos desconocidos.

User flow

Los usuarios de Enterprise SSO también pueden empezar en auth.attesto.eu. Esa página solo descubre rutas tenant Entra/OIDC/SAML y envía a los usuarios sin SSO al login normal del dashboard.

Un tenant user no elige entre siete providers. Introduce su correo de trabajo, revisa la ruta descubierta y continúa con el método configurado para esa dirección. Si el dominio tenant está controlado por organization SSO, el botón dice “Continue with your organization” o el nombre del provider configurado. Si password fallback sigue permitido, los password users existentes pueden continuar con password.

Abra dashboard.attesto.eu/login.
Introduzca la dirección de correo tenant.
Continúe con la ruta descubierta de password, community identity, invite, signup u organization SSO.
Vuelva al dashboard con la tenant session de Attesto, protección CSRF y role checks intactos.

Tenant owner setup

Los tenant owners configuran enterprise identity providers en Settings → Identity Providers. El asistente guarda secrets server-side, devuelve al navegador solo estado enmascarado y genera valores callback o metadata para el provider externo. El provider setup debe probarse con un user invitado antes de aplicar SSO a un dominio tenant.

Provider	Cuándo usarlo	Attesto necesita	El provider necesita
Microsoft Entra ID	Enterprise workforce login	Domain, issuer, client id, encrypted client secret	Redirect URI y users/groups permitidos
Generic OIDC	Okta, Keycloak, Ping, Auth0, ForgeRock o custom OIDC	Domain, issuer URL, client id, encrypted client secret, scopes	Redirect URI y verified email claim
Generic SAML	Legacy enterprise SSO o SAML-only IdPs	Domain, IdP entity id, SSO URL, signing certificate	SP Entity ID, ACS URL, signed response o assertion

Providers

Los community providers soportan Google, GitHub, GitLab y LinkedIn. Los enterprise providers soportan Microsoft Entra ID, OIDC genérico y SAML genérico. Las opciones enterprise provider no se muestran como un muro público de botones; discovery recomienda la ruta tenant correcta. Los community providers configurados pueden aparecer debajo del formulario de correo como shortcut self-service. El catálogo incluye un flag configured, por lo que providers sin configurar son visibles pero inertes hasta que existan credenciales OAuth reales.

Los community providers son útiles para evaluadores, developers, inversores y consultores. Los enterprise providers son tenant scoped: la coincidencia de dominio determina si un user debe ir a organization SSO. Marketplace developer accounts siguen separados de tenant dashboard identities.

Microsoft Entra ID

Use Microsoft Entra ID cuando un cliente quiera que el acceso al dashboard de Attesto siga su Microsoft workforce identity, Conditional Access, MFA y account lifecycle policies. En Entra, cree una web application registration para Attesto, añada la Attesto redirect URI del asistente del dashboard y cree un client secret. En Attesto, elija Entra e introduzca tenant domain, issuer/authority URL, client id y client secret.

El redirect type es web/confidential, no public SPA.
Los scopes deben incluir OpenID Connect identity claims como openid, email y profile.
Attesto exige verified email y comprueba issuer, audience, nonce, state y PKCE.
Use Conditional Access y MFA policies de Entra para enterprise assurance.

Generic OIDC

Generic OIDC cubre Okta, Keycloak, Ping, Auth0, ForgeRock y otros identity providers compatibles con estándares. El provider debe exponer issuer discovery metadata y signing keys, y devolver un subject estable más verified email claim. Attesto descubre los endpoints authorization, token, userinfo y JWKS desde el issuer cuando está soportado.

Cree una confidential/web OIDC app en el identity provider.
Pegue la dashboard-generated callback URL en el provider.
Configure allowed scopes, normalmente openid email profile.
Guarde issuer URL, client id y client secret en Attesto tenant settings.
Ejecute un login real con un user invitado antes de activar strict tenant policy.

Generic SAML

Generic SAML soporta entornos enterprise que usan SAML 2.0 en lugar de OIDC. Attesto expone SP metadata y ACS URLs desde el asistente de tenant settings. El IdP externo debe firmar la response o assertion y enviar un subject estable más email attribute para el tenant user invitado.

Copie Attesto SP metadata o introduzca manualmente Entity ID y ACS URL en el IdP.
Copie IdP Entity ID, SSO URL y signing certificate de vuelta en Attesto.
Mantenga las assertions de corta duración e incluya audience, recipient e InResponseTo values.
Reject unsigned, expired, replayed, wrong-audience o wrong-recipient assertions.

Enterprise SSO

Enterprise SSO es tenant scoped. Una configuración de provider vincula un dominio tenant a un provider Entra, OIDC o SAML habilitado. Durante discovery se evalúan primero invite token e identity links existentes, después tenant domain provider rules, y luego password o signup fallback. Esto evita la elección aleatoria de providers y mantiene simple la pantalla de login.

Los tenant owners configuran enterprise SSO en los settings del dashboard bajo Identity Providers. Los providers OIDC y Entra usan issuer metadata, client id, client secret cifrado, redirect allowlists estrictas, PKCE, state, nonce, issuer, audience y verified-email checks. Los providers SAML usan signed responses o assertions, validación de audience y recipient, InResponseTo replay protection y clock skew corta.

El dashboard muestra valores callback generados para que los tenant owners puedan copiarlos al identity provider externo:

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}

La documentación pública no documenta internal staff admin procedures. Esta página es para tenant-owned identity configuration y developer integration con los tenant authentication endpoints.

Invites

Invite acceptance usa el mismo discovery model. Si el correo de la invitación pertenece a un dominio tenant con required organization SSO, la invitación puede continuar mediante ese provider. Si no se requiere provider, el user todavía puede establecer password mediante la ruta de invitación existente.

API contract

Estos endpoints son dashboard tenant-auth endpoints. Frontend clients nunca reciben 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": "/"
}

Una discovery response indica al frontend qué único siguiente paso renderizar. Provider secrets, client secrets, SAML certificates, tokens y assertions nunca se devuelven al navegador.

{
  "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 devuelve solo labels non-secret de community providers y estado de configuración para los botones debajo del formulario de correo. POST /v1/auth/external/start puede llamarse solo con providerId para global community signup, pero tenant enterprise providers siempre requieren un discovery result respaldado por email o invite.

Security

External login solo se permite cuando el provider devuelve verified email y la identity puede vincularse a un tenant user existente, una invite aceptada o una signup/trial creation explícita. Provider secrets, SAML private settings, tokens, assertions y raw callbacks se quedan server-side. Audit events registran discovery, provider start, success, failure, provider changes e identity linking sin registrar raw secrets.

Control	Qué aplica Attesto
OAuth/OIDC state	Los short-lived state, nonce y PKCE records son single-use.
OIDC token validation	Issuer, audience, JWKS signature, nonce y verified email se comprueban.
SAML replay protection	InResponseTo, audience, recipient, signature y clock skew se validan.
Identity linking	Solo verified emails pueden vincularse a users existentes, accepted invites o explicit signup/trial creation.
Secret handling	Provider secrets se cifran server-side y se enmascaran en tenant settings.
Surface separation	Tenant dashboard users, marketplace developer accounts, auditors e internal staff auth siguen siendo superficies separadas.

Troubleshooting

Síntoma	Causa probable	Solución
User enviado a password en vez de SSO	Domain provider disabled, domain mismatch o existing password identity con precedence.	Revise tenant domain, provider enabled state y ortografía de invite email.
OIDC callback falla	Redirect URI, issuer, audience, nonce o verified email claim no coincide.	Copie exactamente el generated callback y revise issuer/client configuration.
SAML assertion rechazada	Unsigned, expired, replayed, wrong audience, wrong recipient o falta email attribute.	Active signed responses/assertions y compare Entity ID, ACS URL y attributes.
Community provider button deshabilitado	El provider está en el catálogo pero `configured` es false.	Añada el OAuth client id/secret real antes de habilitar esa ruta para users.
User autentica pero no entra en tenant	La external identity no está vinculada a un tenant user invitado o existente.	Invite primero al user o use el explicit signup/trial path para un nuevo tenant.

Rollout checklist

Configure el provider domain y los issuer values en tenant settings.
Copie la URL callback, ACS o metadata generada en el provider externo.
Invite a un tenant user con ese dominio y complete un login real.
Confirme que el provider externo devuelve el verified email claim o SAML email attribute esperado.
Verifique que password fallback sigue funcionando para users que lo necesitan.
Documente tenant-side MFA y access policy ownership con el cliente.
Revise audit events y tenant session behavior antes de imponer una SSO policy.