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:

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.

Ambientación Qué es
DisplayNameEl nombre en el botón de inicio. Por defecto se asigna al nombre del proveedor.
AuthorityEl emisor del proveedor — la dirección bajo la que /.well-known/openid-configuration está. Obligatorio a menos que MetadataAddress se proporcione.
MetadataAddressLa dirección propia del documento de descubrimiento, para un proveedor que lo publica en otro lugar.
ClientId, ClientSecretEl ID de cliente del portal y el secreto en el proveedor. Obligatorio.
ScopesScopes para pedir además openidde , profile y email, que siempre se solicitan.
CallbackPathLa ruta del URI de redirección no /signin-{name} sirve.
TrustedEmailDomainsLos 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.
GetClaimsFromUserInfoEndpointSi 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)

  1. 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 .
  2. 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.
  3. La autoridad es el emisor de tu servidor de autorización, por ejemplo, https://contoso.okta.com/oauth2/default

Auth0

  1. Crea una aplicación del tipo Aplicación Web Regular.
  2. 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.
  3. La autoridad es el dominio de tu inquilino, por ejemplo, https://contoso.us.auth0.com/o tu dominio personalizado.

Microsoft Entra External ID

  1. 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.
  2. Crea un flujo de usuario de registro e inicio de sesión y añade la aplicación a él.
  3. 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, y TrustedEmailDomains puede 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:

  1. 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.
  2. La autoridad es https://login.microsoftonline.com/<their tenant id>/v2.0.
  3. 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.

Ambientación Qué es
DisplayNameEl nombre en el botón de inicio. Por defecto se asigna al nombre del proveedor.
MetadataAddressLa dirección de los metadatos del proveedor de identidad. Requerida, y debe ser https.
IdentityProviderEntityIdEl ID de entidad del proveedor de identidad, cuyas respuestas deben ser emitidas. Por defecto se asigna a aquel que sus metadatos nombran.
EntityIdEl 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, MetadataPathLas 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.
TrustedEmailDomainsLos 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.
AllowIdentityProviderInitiatedAcepta 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.
RequireHttpsMetadataSi 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)

  1. 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 .
  2. 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.
  3. 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)

  1. Crea una integración de aplicación de tipo SAML 2.0.
  2. 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 , firstName y lastName de atributo.
  3. Copia la URL de metadatos de la aplicación en MetadataAddress.

AD FS

  1. Añade un fideicomiso de la parte de confianza, importando los metadatos del portal desde su dirección.
  2. 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.
  3. MetadataAddress es https://<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.

¿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.

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
IconUn 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.
ButtonImageUna imagen mostrada en lugar del botón estándar: el propio proveedor de "Iniciar sesión con ..." botón.
ButtonImageDarkLa misma imagen para el tema oscuro. Sin ella, ButtonImage se usa en ambos.
OrderDó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.

El botón de cualquier otro proveedor, incluido el de Microsoft y el de Google, está modificado en el código:

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