OpenID Connect e inicio de sesión SAML
Además de Microsoft, Google y Facebook, un portal puede iniciar sesión a las personas a través de cualquier proveedor de identidad OpenID Connect o SAML 2.0 : Okta, Auth0, Microsoft Entra External ID, el inquilino Entra propio de un cliente o socio, AD FS, Ping, Google Workspace. Cada proveedor que configures es un botón en la página de inicio de sesión y no necesita código.
Un inicio de sesión a través de uno de estos proveedores se empareja, vincula o registra como contacto exactamente igual que un inicio de sesión de Microsoft o Google. Los usuarios internos (usuarios del sistema) inician sesión con Microsoft — véase Configuración de Inicio de sesión de Entra ID.
Enciéndelo
Los proyectos creados a partir de las plantillas para usuarios externos ya tienen esto en Program.cs. Lee todos los proveedores configurados bajo Authentication:OpenIdConnect y Authentication:Saml2, y no añade ninguno hasta que uno está configurado:
builder.Services.AddAuthentication()
.AddOpenIdConnectProviders(builder.Configuration)
.AddSaml2Providers(builder.Configuration);
El SAML proviene del PowerPortalsPro.Identity.Saml2 paquete al que hacen referencia esos proyectos. Un proyecto creado antes de esta función necesita la llamada y el paquete añadido.
Direcciones para registrarse con el proveedor
Cada proveedor tiene un nombre — la clave de su sección de configuración, ContosoOkta en los ejemplos siguientes — y las direcciones a las que el proveedor envía personas de vuelta se forman a partir de él en minúsculas. Regístralas exactamente, una vez por cada host en el que se ejecuta el portal.
| ¿Qué | Dirección |
|---|---|
| URI de redirección OpenID Connect | https://your-portal.example.com/signin-{name} |
| Servicio de aserción SAML para consumidores (HTTP-POST) | https://your-portal.example.com/saml2/{name}/acs |
| ID de entidad SAML (audiencia) | https://your-portal.example.com/saml2/{name} |
| Los metadatos SAML del portal | https://your-portal.example.com/saml2/{name}/metadata |
Las direcciones son las mismas en todos los idiomas. Un inicio de sesión iniciado en una página en otro idioma — /es/… vuelve a través de la propia dirección del sitio y luego a la página en la que empezó, en ese idioma.
Proveedores OpenID Connect
Añade una sección para cada proveedor bajo Authentication:OpenIdConnect. Mantén el secreto del cliente en secretos de usuario localmente y en Key Vault una vez desplegado.
{
"Authentication": {
"OpenIdConnect": {
"ContosoOkta": {
"DisplayName": "Contoso",
"Authority": "https://contoso.okta.com/oauth2/default",
"ClientId": "0oa1b2c3d4e5f6g7h8i9",
"ClientSecret": "<in user secrets or Key Vault>",
"TrustedEmailDomains": [ "contoso.com" ]
}
}
}
}
| Ambientación | Qué es |
|---|---|
DisplayName | El nombre en el botón de inicio. Por defecto se asigna al nombre del proveedor. |
Authority | El emisor del proveedor — la dirección bajo la que /.well-known/openid-configuration está. Obligatorio a menos que MetadataAddress se proporcione. |
MetadataAddress | La dirección propia del documento de descubrimiento, para un proveedor que lo publica en otro lugar. |
ClientId, ClientSecret | El ID de cliente del portal y el secreto en el proveedor. Obligatorio. |
Scopes | Scopes para pedir además openidde , profile y email, que siempre se solicitan. |
CallbackPath | La ruta del URI de redirección no /signin-{name} sirve. |
TrustedEmailDomains | Los dominios de correo electrónico para los que este proveedor es de confianza — véase Qué direcciones son confiables más abajo. Vacío por defecto. En una configuración de servicio de aplicaciones, escríbelo separado por comas. |
GetClaimsFromUserInfoEndpoint | Si leer el perfil desde el punto final de información de usuario del proveedor así como el token ID. Activado por defecto, ya que algunos proveedores no ponen ningún correo electrónico en el token ID. |
El portal utiliza el flujo de códigos de autorización con PKCE, inicia sesión a través de la cookie externa de Identity y no guarda ningún token. Lee el id de la persona desde sub, y su dirección y nombre desde email, given_name y family_name.
Okta (OpenID Connect)
- Crea una integración de aplicación: OIDC - OpenID Connect, del tipo Aplicación Web, con la concesión de Código de Autorización .
- Añade el URI de redirección del portal como URI de redirección de inicio de sesión, asigna a las personas o grupos que pueden iniciar sesión y copia el id del cliente y el secreto.
- La autoridad es el emisor de tu servidor de autorización, por ejemplo,
https://contoso.okta.com/oauth2/default
Auth0
- Crea una aplicación del tipo Aplicación Web Regular.
- Añade el URI de redirección del portal a las URLs de Devolución de Llamada Permitidas, y copia el id del cliente y el secreto.
- La autoridad es el dominio de tu inquilino, por ejemplo,
https://contoso.us.auth0.com/o tu dominio personalizado.
Microsoft Entra External ID
- En el tenant externo, registra una aplicación con el URI de redirección del portal como URI de redirección web y añade un secreto del cliente.
- Crea un flujo de usuario de registro e inicio de sesión y añade la aplicación a él.
- La autoridad es
https://<tenant subdomain>.ciamlogin.com/<tenant id>/v2.0. Cuando el flujo de usuario verifica cada dirección antes de que se cree una cuenta — el correo electrónico con contraseña y el código de acceso de un solo uso, ambos lo hacen — este es un proveedor de identidad que gestionas para tus propios clientes, yTrustedEmailDomainspuede ser*.
Inquilino Entra de un cliente o socio
Para una organización cuyas personas deberían iniciar sesión con sus propias cuentas de trabajo, sin el botón de Microsoft multiusuario:
- En su tenant, registra una única aplicación de inquilino con el URI de redirección del portal como URI de redirección web y añade un secreto del cliente.
- La autoridad es
https://login.microsoftonline.com/<their tenant id>/v2.0. - Lista sus dominios en
TrustedEmailDomains; una dirección en cualquier otro lugar se confirma primero por correo electrónico. El ID de su inquilino llega a la sesión, igual que ocurre con el botón Microsoft. Las propias reclamaciones de verificación de Entra (xms_edov,verified_primary_email) no se toman de un proveedor: el tenant detrás de ellas administra las reclamaciones que envía.
Proveedores SAML 2.0
Añade una sección para cada proveedor bajo Authentication:Saml2. Los metadatos del proveedor proporcionan al portal su dirección de inicio de sesión y los certificados con los que están firmadas sus respuestas; se vuelve a leer cada día, por lo que se recoge un certificado que el proveedor revierte.
{
"Authentication": {
"Saml2": {
"Fabrikam": {
"DisplayName": "Fabrikam",
"MetadataAddress": "https://login.microsoftonline.com/<tenant id>/federationmetadata/2007-06/federationmetadata.xml?appid=<app id>",
"TrustedEmailDomains": [ "fabrikam.com" ]
}
}
}
}
| Ambientación | Qué es |
|---|---|
DisplayName | El nombre en el botón de inicio. Por defecto se asigna al nombre del proveedor. |
MetadataAddress | La dirección de los metadatos del proveedor de identidad. Requerida, y debe ser https. |
IdentityProviderEntityId | El ID de entidad del proveedor de identidad, cuyas respuestas deben ser emitidas. Por defecto se asigna a aquel que sus metadatos nombran. |
EntityId | El propio ID de entidad del portal. Por defecto se https://{host}/saml2/{name} asigna al host al que llegó la solicitud; configúralo cuando el portal responda en más de un host, para que compartan un registro en el proveedor. |
CallbackPath, MetadataPath | Las rutas del servicio de consumo y de los metadatos de la afirmación, cuándo /saml2/{name}/acs y /saml2/{name}/metadata cuándo no servirán. |
TrustedEmailDomains | Los dominios de correo electrónico para los que este proveedor es de confianza — véase Qué direcciones son confiables más abajo. Vacío por defecto. En una configuración de servicio de aplicaciones, escríbelo separado por comas. |
AllowIdentityProviderInitiated | Acepta inicios de sesión que el proveedor inicia — alguien abriendo el portal desde una casilla en el panel de control de su proveedor. Desactivado por defecto. Van a la página de inicio de sesión externo del portal y luego a una página local llamada por RelayState (/orders o ReturnUrl=/orders). Cada respuesta se acepta una vez por servidor. |
RequireHttpsMetadata | Si MetadataAddress debe ser https. Activado por defecto; desactivarlo solo para probar un proveedor que se ejecute en tu propia máquina. |
Las respuestas deben estar firmadas por un certificado en los metadatos del proveedor, emitido por su ID de entidad, para el ID de entidad del portal, enviado al servicio de aserción al consumidor y, en respuesta a la solicitud realizada por el mismo navegador. El NameID identifica la cuenta, por lo que debe ser persistente o la dirección de correo electrónico; se rechaza una cuenta temporal. La dirección y el nombre se leen de los atributos que los proveedores suelen usar: email, mail, emailaddress y los nombres de reclamación WS-Federation, y givenName , firstName y, surname o lastName.
Microsoft Entra ID (aplicación empresarial)
- Crea una aplicación empresarial, integra cualquier otra aplicación que no encuentres en la galería y elige inicio de sesión único SAML .
- Establece el Identificador (ID de la entidad) al ID de entidad del portal y la URL de respuesta a su servicio de aserción al consumidor.
- Copia la URL de metadatos de la Federación de Aplicaciones en
MetadataAddress, y asigna a los usuarios o grupos que puedan iniciar sesión.
Okta (SAML)
- Crea una integración de aplicación de tipo SAML 2.0.
- Establezca la URL de inicio de sesión único en el servicio de consumo de aserción y el URI de audiencia (ID de entidad SP) en el ID de entidad del portal; elige un formato de ID de nombre de Dirección Persistente o de Correo Electrónico , y añade
emaillas sentencias ,firstNameylastNamede atributo. - Copia la URL de metadatos de la aplicación en
MetadataAddress.
AD FS
- Añade un fideicomiso de la parte de confianza, importando los metadatos del portal desde su dirección.
- Añade reglas de emisión de reclamaciones que envíen la dirección de correo electrónico, nombre y apellido, y un ID de nombre persistente.
MetadataAddresseshttps://<your AD FS host>/FederationMetadata/2007-06/FederationMetadata.xml.
Solicitudes firmadas y aserciones cifradas
La mayoría de los proveedores no necesitan ninguno de los dos. Para uno que requiere solicitudes de autenticación firmadas o cifra sus aserciones, añade el proveedor en código junto con los certificados; ambos se publican en los metadatos del portal para que el proveedor los importe.
builder.Services.AddAuthentication().AddPortalSaml2(
"Fabrikam",
new Saml2ProviderSettings
{
DisplayName = "Fabrikam",
MetadataAddress = "https://sts.fabrikam.com/FederationMetadata/2007-06/FederationMetadata.xml",
TrustedEmailDomains = ["fabrikam.com"],
},
options =>
{
options.SigningCertificate = signingCertificate;
options.DecryptionCertificate = decryptionCertificate;
});
¿Qué direcciones son de confianza?
Un inicio de sesión cuya dirección confía el portal va directamente al contacto que la tiene, y una nueva cuenta comienza con esa dirección confirmada. Cualquier otra dirección se confirma primero por correo electrónico, una vez; después el enlace entre el inicio de sesión y el contacto es lo que la encuentra.
- Un proveedor solo es confiable para los dominios listados en su
TrustedEmailDomains, coincidido exactamente —contoso.comno cubremail.contoso.com. Lista los dominios cuyos buzones controla la organización detrás del proveedor. - Un proveedor que dice no haber verificado una dirección (el de
email_verifiedOpenID Connect sífalse) no es de fiar para ello, sea lo que sea que diga la lista. - Nada más lo está: un proveedor no puede avalar una dirección enviando las reclamaciones propias del portal, y un sistema de inicio de sesión añadido de otra forma nunca garantiza una.
Importante
*Confía en cada dirección que el proveedor solicita. Úsala solo para un proveedor de identidad que gestiones para tus propios usuarios y que verifique las direcciones antes de hacerlas reclamar. Nunca la utilices para un proveedor que administre un cliente o socio: cualquiera que la administre puede crear una cuenta con cualquier dirección, incluida una de contacto de otra organización, y iniciaría sesión como ese contacto.
Botones de inicio de sesión
Cada proveedor es un botón en la página de inicio de sesión, etiquetado con su nombre de visualización. Cuatro ajustes más en la sección de un proveedor cambian cómo se ve su botón y dónde se sitúa:
| Ambientación | Qué es |
|---|---|
Icon | Un pequeño logo mostrado antes del nombre en el botón estándar — por ejemplo, el logo propio del cliente en su inicio de sesión. |
ButtonImage | Una imagen mostrada en lugar del botón estándar: el propio proveedor de "Iniciar sesión con ..." botón. |
ButtonImageDark | La misma imagen para el tema oscuro. Sin ella, ButtonImage se usa en ambos. |
Order | Dónde está el botón: el botón más bajo viene primero, y los botones con el mismo orden mantienen el orden en el que se añadieron sus proveedores. 0 por defecto. |
Una imagen es un camino desde la raíz del sitio — un archivo en el wwwrootportal , como /images/contoso-logo.svg — o una https dirección. Se sirve un camino desde la raíz del sitio en cada página, en todos los idiomas. Cualquier otra cosa detiene el portal al inicio, nombrando la configuración.
"ContosoOkta": {
"DisplayName": "Contoso",
"Icon": "/images/contoso-logo.svg",
"Order": -1,
...
}
El botón de cualquier otro proveedor, incluido el de Microsoft y el de Google, está modificado en el código:
builder.Services.ConfigureSignInButton("Microsoft", button => button.Order = 1);
Microsoft, Google y Facebook muestran sus propios botones de "Iniciar sesión con ..." en versiones claras y oscuras, a menos que les pongas uno de estos.
Resolución de problemas
- El proveedor rechaza el URI de redirección o la URL de respuesta. Debe coincidir exactamente — esquema, host, puerto y ruta. Register
https://{host}/signin-{name}, o las direcciones SAML, para cada host en el que se ejecute el portal. - El portal no se inicia, nombrando una
Authentication:OpenIdConnectconfiguración de oAuthentication:Saml2. Un proveedor configurado carece de un valor requerido o tiene uno mal formado. El servidorcheck_setupMCP lista cada proveedor, lo que le falta y las direcciones que deben registrar. - Un inicio de sesión SAML falla con "La firma es inválida". La respuesta estaba firmada por un certificado que el portal no ha visto — normalmente porque el proveedor ha transferido su certificado. El portal vuelve a leer los metadatos en un día; reinícialo para leerlo ahora.
- "Validación de audiencia fallida" o "Emisor inválido". El ID de la entidad registrado en el proveedor no es el que usa el portal — configurado
EntityIdpara coincidir — o la respuesta provino de otra entidad que noIdentityProviderEntityIdsean los nombres. - Un inicio de sesión SAML falla porque el NameID es transitorio. Haz que el proveedor envíe un NameID persistente o la dirección de correo electrónico.
- Abrir el portal desde el panel de control de un proveedor vuelve a la página de inicio de sesión. El portal no pidió ese inicio de sesión. Configurado
AllowIdentityProviderInitiatedpara ese proveedor. - Cada primer inicio de sesión envía un correo de confirmación. El dominio de la dirección no está en el del proveedor
TrustedEmailDomains. Ese es el valor seguro por defecto; una vez confirmada la dirección, los inicios de sesión posteriores se introducen directamente.
