Documentación de Oracle Cloud Infrastructure

Acerca de las políticas de proveedor de identidad

Acerca de las políticas de proveedor de identidad.

Una política de proveedor de identidad permite definir qué proveedores de identidad están visibles en la página Conectar cuando un usuario accede a una aplicación específica o intenta acceder a recursos protegidos por un dominio de identidad. Las políticas de proveedor de identidad también pueden decidir si los usuarios se autentican en un dominio de identidad mediante proveedores de identidad o con un factor de autenticación local.

El siguiente tipo de proveedores de identidad está disponible en un dominio de identidad:

  • Proveedor de identidad de SAML: este tipo de proveedor de identidad soporta el estándar SAML 2.0 (Lenguaje de marcado para confirmaciones de seguridad 2.0). Utilice un proveedor a nivel de identidad de SAML cuando desee establecer la confianza entre un proveedor a nivel de identidad compatible con SAML, como los servicios de federación de Active Directory, para que el usuario de una organización pueda acceder a recursos protegidos por el dominio de identidad.

    Si deseas que los usuarios se redirijan automáticamente a un proveedor para que puedan acceder a una aplicación, asegúrate de que la política de proveedores de identidad asociada a la aplicación solo tenga asignado el proveedor para la identidad SAML. Si se asignan muchos proveedores de identidad a la política de proveedores de identidad, se solicitará a los usuarios de la página Conectar que seleccionen uno de los proveedores de identidad.

  • Proveedor de identidad social: al enlazar una cuenta de usuario de dominio de identidad a las cuentas sociales de un usuario, el usuario puede acceder a un dominio de identidad mediante sus credenciales sociales, como Facebook, Google, LinkedIn, Microsoft y X (anteriormente Twitter).

  • Proveedor de autenticación sin contraseña: permite a los usuarios omitir la autenticación basada en formulario web estándar. La autentificación sin contraseña permite el acceso al recurso protegido sin necesidad de introducir el usuario y contraseña cada vez. Sin embargo, la primera vez Conectar utiliza el formulario estándar de conexión.

  • Proveedor de identidad local (IDP local): la autenticación en un dominio de identidad se produce localmente cuando el usuario proporciona sus credenciales (nombre de Usuario y contraseña) en la página Conectar.

Además de los proveedores de identidad, también puede utilizar los siguientes factores de autenticación local. Para que estos factores de autenticación local estén disponibles para que pueda asignarlos a políticas de proveedor de identidad, primero debe activarlos. Consulte la sección sobre configuración de factores de autenticación.
  • Correo electrónico: envía un código de acceso de un solo uso a la dirección de correo electrónico principal del usuario para su uso como método de verificación para autenticarse. La dirección de correo electrónico principal del usuario se define en la cuenta del usuario.
  • Notificaciones de aplicación móvil: envía una notificación push que contiene una solicitud de aprobación para permitir o denegar un intento de conexión. Las notificaciones push son una forma fácil y rápida de autenticarse. Una vez que el usuario introduce su Nombre de Usuario y Contraseña, se envía una solicitud para conectarse a la aplicación en su teléfono. El usuario pulsa Permitir para autenticarse.
  • Código de acceso de la aplicación portátil: una aplicación del autenticador como la aplicación Oracle Mobile Authenticator (OMA) genera un código de uso único. Este código de acceso se puede generar incluso cuando el dispositivo del usuario está fuera de línea. Una vez que el usuario introduce su usuario y contraseña, aparece una petición de Datos para el código de acceso. El usuario obtiene un código de acceso generado desde la aplicación y, a continuación, introduce el código.
  • Mensaje de Texto: una vez que el usuario introduce su Nombre de Usuario y Contraseña, se envía un código de entrada como mensaje del texto al dispositivo del usuario. El usuario introduce el código para completar la conexión.
  • nombre de usuario-Contraseña: el usuario se autentica proporcionando sus credenciales (nombre de Usuario y contraseña) en la página Conectar.

La política del proveedor de identidad le permite configurar si se muestra la autenticación local en la página Conectar para el usuario.

Por ejemplo, supongamos que ha creado varios Proveedores de Identidad Social y Proveedores de Identidad de SAML, y desea configurar cuál de estos Proveedores de Identidad aparecerá en la página Conectar cuando el usuario trate de autenticarse en el dominio de identidad mediante una aplicación concreta. Sin políticas de proveedor de identidad, no podría configurarlo. Por ello, si tuviera todos estos proveedores, tanto de identidad social como de SAML activados y configurados para que aparezcan en la página Conectar, se mostrarían todos ellos.

El dominio de identidad proporciona una política de proveedor de identidad por defecto que contiene una regla de proveedor de identidad por defecto. Esta regla tiene asignado el factor nombre de usuario-contraseña de autenticación local. De esta forma, como mínimo, los usuarios pueden autenticarse con sus nombres de usuario y contraseñas. Sin embargo, puede agregar otras reglas de proveedor de identidad a esta política por defecto. Al agregar estas reglas, puede evitar que algunos de los proveedores de identidad estén disponibles para los usuarios para autenticarse en el dominio de identidad. O bien, puede permitirle que otros proveedores de identidad estén disponibles solo para aquellos usuarios que accedan al dominio de identidad desde una dirección IP incluida en uno de las perímetros. Tanto la consola Mi perfil como la consola de administración utilizan las reglas del proveedor de identidad que están asignadas a la política del proveedor de identidad.

Supongamos que una compañía tiene restricciones sobre quién puede conectarse al dominio de identidad localmente (proporcionando sus nombres de usuarios y contraseñas) y quién debe utilizar un proveedor externo de identidad. Los empleados deben autenticarse mediante el uso de los servicios de federación de Active Directory (AD FS), los contratista y el partner deben utilizar sus propios proveedores de identidad SAML y todos el resto de usuarios (como los consumidores) pueden utilizar sus nombre de usuarios y contraseñas o un proveedor de identidad social.

Para lograr este objetivo, puede crear dos reglas de proveedor de identidad para la política de proveedor de identidad por defecto. La primera regla solo se aplica a los empleados de la compañía. Estos usuarios deben conectarse a AD FS, que es el proveedor de identidad del empleado. La segunda regla solo se aplica a los usuarios que tienen nombres que terminan en @partner1.com. Pueden conectarse con el proveedor de identidad de SAML del partner 1. La tercera regla solo se aplica a los usuarios que tengan nombres de usuario que terminan en @partner2.com. Pueden conectarse con el proveedor de identidad de SAML del partner 2. La regla final es una regla de tipo capturar todo para todos los usuarios (consumidores). Estos usuarios pueden utilizar sus contraseñas locales o un proveedor de identidad social.

Puesto que puede definir varias reglas de proveedor de identidad para una política de proveedor de identidad, el dominio de identidad debe conocer el orden en el que se van a evaluar las reglas. Para ello, puede definir la prioridad de las reglas. En el ejemplo anterior, puede hacer que se evaluara primero la regla de empleado de la compañía. Si un usuario cumple los criterios de esta regla (es decir, el usuario es un empleado), el usuario debe autenticarse con AD FS. Los usuarios que no son empleados no cumplen los criterios de esta regla de proveedor de identidad, por lo que se evalúa la regla con la siguiente prioridad más alta. Para este ejemplo, esta es la regla del partner 1, en la que el nombre de usuario del usuario debe terminar en @partner1.com. Estos usuarios deben autenticarse mediante el proveedor de identidad de SAML del partner 1. Para los usuarios que no son empleados o que no tienen nombres de usuario que terminan en @partner1.com, el dominio de identidad evalúa la regla con el siguiente número de prioridad más alto: la regla del partner 2, en la que el nombre de usuario debe terminar en @partner2.com. Estos usuarios deben utilizar el proveedor de identidad de SAML del partner 2 para autenticarse. Todos los demás usuarios cumplen los criterios de la regla de tipo capturar todo, por lo que pueden utilizar sus contraseñas locales o un proveedor de identidad social para conectarse.

Además de la política de proveedor de identidad por defecto, puede crear políticas de proveedor de identidad y asociarlas a aplicaciones específicas. Supongamos que tiene varias aplicaciones y que desea asignar diferentes proveedores de identidad a cada aplicación. Por ejemplo, puede que tenga dos aplicaciones y que desee que los usuarios se autenticen desde Facebook o LinkedIn. Por lo tanto, puede tener una política de proveedor de identidad para una aplicación y el proveedor de identidad social Facebook, y otra política de proveedor de identidad solo para la segunda aplicación y el proveedor de identidad social LinkedIn.

Un dominio de identidad muestra un máximo de cuatro proveedores de identidad en la página Conectar. Si asigna más de cuatro proveedores de identidad a una política de proveedor de identidad, aparecerá el enlace Ver todo en la página. Seleccione el enlace y aparecerán todos los proveedores de identidad asociados a la política.