Configuración de clientes STS
Utilice el cliente STS (Security Token Service) para intercambiar señales. Siga las especificaciones para el intercambio de token OAuth cuando cree y administre sus clientes STS en IBM® Verify. Puede validar sus aplicaciones de terceros con OAuth como recurso protegido.
Antes de empezar
- Inicie sesión en la consola de administración de IBM Verify como administrador.
- Cree los tipos de señal personalizados que utilizará el cliente STS. Consulte Gestión de tipos de tokens personalizados.
Acerca de esta tarea
Configure un cliente STS para el intercambio de señales. Un cliente solicita una señal de seguridad al punto final de señal del servidor de autorización utilizando el mecanismo de tipo de otorgamiento de extensión de señal. Las aplicaciones externas creadas utilizando Verify como proveedor de identidad pueden aceptar las solicitudes API REST autenticadas con un token de acceso OAuth 2.0 y diferentes métodos de autenticación. Para obtener más información, consulte https://www.rfc-editor.org/rfc/rfc8693.html.
Procedimiento
- Seleccione Aplicaciones > Clientes STS.
- Seleccione Añadir cliente STS.
- Proporcione la información general.
- Opcional: Proporcione un ID de cliente.Si no proporciona un ID de cliente, se crea un ID al completar la configuración.
- Proporcione un nombre exclusivo para el cliente STS.
- Mantener el recuadro de selección Habilitado seleccionado.Puede habilitar o inhabilitar este cliente STS.
- Permitir el intercambio de señales de acceso para la sesión SSO. Si se selecciona Valor predeterminado , los valores generales de la aplicación OIDC determinan si las señales de acceso se pueden intercambiar para la sesión SSO.
- Opcional: Proporcione un ID de cliente.
- Seleccione Siguiente.
- Seleccione el método de autenticación de cliente.El valor determina cómo se autentica el cliente.
- Para los métodos Predeterminado, Secreto de cliente básico y Secreto de cliente POST, el secreto de cliente se genera automáticamente al completar la configuración.
- Para el método JWT de clave privada, debe seleccionar un algoritmo de firma de aserción de cliente y claves de verificación de firma permitidas. También puede seleccionar Validar JTI de aserción de cliente para validar la aserción de cliente.
- Para el método «Mutual TLS », debe proporcionar el atributo de autenticación de cliente « TLS » y el valor del atributo de autenticación de cliente « TLS ».
- Si está editando un cliente STS existente, puede utilizar las siguientes opciones de secreto de cliente:
- Seleccione
para ver el secreto de cliente.
- Seleccione
para ocultar el secreto de cliente.
- Seleccione
para copiar el ID del cliente o el secreto al portapapeles.
- Seleccione
para ver los secretos de cliente rotados.
- Seleccione uno o varios secretos de cliente rotados de la lista y haga clic en Eliminar para eliminarlos.
- Seleccione
para generar un nuevo secreto de cliente. Utilice esta opción si piensa que el secreto de cliente está comprometido. Si vuelve a generar el secreto de cliente, debe actualizar el secreto de cliente en todos los clientes
OAuth de la aplicación.- Seleccione la casilla de verificación Conservar el secreto actual para añadir el secreto de cliente actual a la lista de secretos de cliente rotados.
- Si la casilla Conservar secreto actual está seleccionada, elija la descripción del secreto del cliente y la hora de caducidad (en la hora local del navegador). Si no se selecciona ningún tiempo de caducidad, se aplicará la duración del secreto rotado del inquilino establecida en la configuración de la aplicación.
- Los secretos de cliente rotados se someten a un proceso de hash y ya no se pueden recuperar en texto sin formato, pero se pueden seguir utilizando hasta la fecha de caducidad seleccionada.
- Tras la confirmación, el secreto del cliente se rota inmediatamente. El nuevo secreto de cliente se muestra en la pantalla.
- Seleccione
Nota: El método de autenticación de cliente predeterminado esdefault.Si se deja como valor predeterminado, se permiten tanto el secreto de cliente básico como POST. Si este cliente es un cliente público, el secreto de cliente básico y POST no están permitidos. Si la parte dependiente la soporta, utilice JWT de clave privada o TLS mutuo como configuración. Para obtener más información sobre la autenticación TLS mutuo de cliente, consulte Autenticación de cliente TLS mutuo de OpenID Connect y señal de acceso enlazada a certificado.
- Seleccione Siguiente.
- Seleccione los tipos de señal permitidos para la señal de asunto y la señal solicitada.
- Opcional: Seleccione los tipos de tokens permitidos para el token de actor.
Para crear un tipo de token personalizado que se utilice para el cliente, consulta «Creación de tipos de token personalizados ».Tabla 1. Intercambio de tokens Campo Descripción Señal de asunto El tipo de señal de la señal de asunto, que representa la identidad de la parte en nombre de la cual se solicita la señal. Señal de actor El tipo de señal de la señal de actor, que representa la identidad de la parte a la que se delegan los derechos de acceso de la señal emitida. Señal solicitada El tipo de señales que se puede solicitar que se generen como parte del intercambio de señales. Grupos de clientes La lista de grupos de clientes de OpenID Connect. Las señales generadas por este cliente se pueden utilizar como la señal de asunto para el intercambio de señales en el mismo grupo. Si esta lista está vacía, cualquier cliente puede utilizar las señales generadas a partir de este cliente como la señal de asunto para el intercambio de señales. Requerir token de actor Solicitar el token de actor como parte de la solicitud de intercambio de tokens. Esta acción aplica el escenario de delegación y rechaza el escenario de suplantación de identidad. - Seleccione Siguiente.
- Seleccione o especifique los valores de señal solicitados.
Tabla 2. Configuración de token solicitada Campo Descripción Formato de la señal de acceso: Especifica el formato de la señal de acceso. Las siguientes opciones están disponibles: Valor predeterminado
JWT
Caducidad de señal de acceso (seg) Establece la longitud del tiempo en segundos transcurrido el cual la señal de acceso caduca.
Establezca una caducidad de señal de acceso para limitar el tiempo en que un atacante puede acceder al recurso con la señal robada cuando la aplicación cliente está comprometida.
Solo se permiten enteros positivos.
El valor predeterminado es 3600 segundos. El valor mínimo permitido es 1 y el máximo es 2147483647 segundos.
Algoritmo de firma El algoritmo que Verify utiliza para firmar la señal de ID. El algoritmo debe coincidir con el que la entidad de confianza ha registrado con Verify. Elija uno para verificar la firma entre los siguientes algoritmos hash: - RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- ES256
- ES384
- ES512
Nota:- Si se selecciona el algoritmo de firma ES256, el certificado debe ser ECDSA con P-256.
- Si se selecciona el algoritmo de firma ES384, el certificado debe ser ECDSA con P-384.
- Si se selecciona el algoritmo de firma ES512, el certificado debe ser ECDSA con P-521.
Certificado de firma Seleccione el certificado que se utiliza para firmar la señal de ID. La selección predeterminada se refiere al valor predeterminado que ha configurado en Seguridad > Certificados.
.Algoritmo de cifrado El algoritmo criptográfico que se utiliza para cifrar o determinar el valor de la clave de cifrado de contenido (CEK). Se da soporte a los algoritmos siguientes. - Ninguna
- RSA-OAEP
- RSA-OAEP-256
Algoritmo de contenido El algoritmo de cifrado de contenido que se utiliza para autenticar el cifrado en el texto sin formato para producir el texto cifrado y la etiqueta de autenticación. Se da soporte a los algoritmos siguientes: - Ninguna
- A128GCM
- A192GCM
- A256GCM
Certificado de cifrado Especifique un valor o seleccione en la lista de certificados de firmante que ya ha cargado en el arrendatario. Nota: Para obtener instrucciones sobre cómo cargar certificados de firmante, consulte Administración de certificados.URI JWKS El URI donde el emisor de señal o la parte dependiente publica sus claves públicas en formato JWKS (JSON Web Keys Set). Este URI se utiliza para la verificación de firmas JWT o el cifrado. El sistema puede rechazar un URI de JWKS no alcanzable o que no responde. El sistema también puede rechazar el URI de JWKS si el tamaño de JWKS es demasiado grande. Si el emisor de señal no publica un URI de JWKS, se puede añadir una clave pública, con el formato de un certificado X509 , al sistema. Consulte Gestión de certificados. El 'Nombre descriptivo' que está asociado con el certificado público es el valor de la cabecera de ID de clave (kid) de JWT. Por ejemplo: https://{yourDomain}/.well-known/jwks.json - Seleccione Siguiente .
- Marque los recuadros de selección para los valores de prueba de posesión.
Tabla 3. Configuración de la prueba de posesión Campo Descripción Señales de acceso con certificado enlazado Indica si las señales generadas están enlazadas a certificados. Para obtener más información sobre las señales de acceso enlazadas a certificado, consulte Autenticación de cliente TLS mutuo de OpenID Connect y señal de acceso enlazada a certificado. Hacer cumplir DPoP-bound fichas de acceso. Indica si la cabecera DPoP es necesaria para las solicitudes de señal. Validar JTI de JWT de DPoP Indica si el JTI en el JWT DPoP se valida para un solo uso. Algoritmo de firma para JWT de DPoP El algoritmo de firma esperado para el JWT DPoP .
Elija entre los algoritmos siguientes.
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- ES256
- ES384
- ES512
- Seleccione Siguiente.
- Configure las correlaciones de solicitud y respuesta para cada uno de los puntos finales.
- Configure la correlación de introspección para añadir y modificar atributos devueltos desde el punto final de introspección.
- Configure la información de usuario y la correlación de atributos de señal de ID para añadir y modificar atributos devueltos desde el punto final
userinfoy en la señal de ID.
- Seleccione Siguiente.
- Restringir ámbitos personalizados.Los ámbitos personalizados pueden ser solicitados por un cliente OIDC / OAuth en los flujos de concesión OIDC / OAuth compatibles. Si Restringir ámbitos personalizados está habilitado, que es el valor predeterminado, los ámbitos otorgados al cliente al final del flujo se limitan a los ámbitos especificados en esta sección. Si Restringir ámbitos personalizados no está disponible, los ámbitos personalizados solicitados se otorgan cuando se completa el flujo.Nota: Los ámbitos estándar openid, profile, email, phoney address no se pueden restringir.
- Asegúrese de que el recuadro de selección Restringir ámbitos personalizados esté seleccionado.
- Escriba el nombre del ámbito personalizado que desea otorgar y una descripción.El nombre de ámbito es el ámbito OAuth2/OIDC solicitado por una entidad de confianza/cliente. La descripción es una explicación descriptiva del ámbito.Se muestra otro conjunto de campos de ámbito.
- Repita el paso anterior para cada ámbito personalizado que desee otorgar.
- Seleccione los permisos de usuario y no usuario que desea otorgar a la señal de acceso.Restringir el acceso a la API es el valor predeterminado. Para otorgar titularidades para el acceso de API, realice los pasos siguientes. Si desmarca el recuadro Restringir acceso de API, se otorga a la señal un conjunto predeterminado de titularidades. Consulte Derechos de API de token de inicio de sesión predeterminado.
- Seleccione Completar configuración.