Integración de la aplicación (parte confidente)
casso127figsbres
HID_application-integration
El cuadro de diálogo Integración de la aplicación le permite configurar cómo gestiona el sistema de federación las tareas siguientes:
- Cómo dirigir usuarios a la aplicación de destino en la parte confidente.
- Cómo asignar atributos de aserción a atributos que utiliza la aplicación de destino.
- Cómo una aplicación de aprovisionamiento de terceros establece cuentas de usuarios.
- Cómo se redirigen los usuarios cuando se produce un error en la autenticación.
Configuración de aplicación de destino (SAML y WSFED)
En la sección Aplicación de destino se especifica la aplicación de destino y cómo se dirigen usuarios a la aplicación de destino.
- Modo de redirecciónIndica el método por el cual la parte confidente redirige el usuario al recurso de destino.Valor predeterminado: Sin datosLas opciones para este campo son como se muestra a continuación:
- Sin datos (valor predeterminado)El usuario se redirige a la aplicación de destino con una redirección HTTP 302 con una cookie de sesión, pero no otros datos.
- Datos de la cookieSe vuelve a dirigir al usuario a la aplicación de destino mediante un mensaje de error HTTP 302. Esta redirección incluye una cookie de sesión y datos de la cookie adicionales que se configuran en la parte asertiva.Para SAML 1.1 y 2.0, al habilitar esta opción se mostrará el siguiente campo adicional:La dirección URL codifica los datos de la cookie del atributo.Indica que el atributo enviado en la cookie es una dirección URL codificada. El atributo está codificado con una URL porque los caracteres de la dirección URL sirven para un fin único, distinto al normal para una dirección URL. Esta configuración es solamente válida con la opción Datos de la cookie como el modo de redirección.Si se especifica cualquier carácter especial en la tabla de atributos de aplicación, seleccione esta opción. Por ejemplo, revise esta configuración para los atributos con caracteres japoneses. Se pueden agregar caracteres especiales de la lista desplegable o introducirlos manualmente. Por otro lado, la aplicación de destino debe descodificar mediante URL el nombre y el valor del atributo de la aplicación recibido.
- Cookie de formato abiertoEl usuario se redirige a la aplicación de destino con una redirección HTTP 302 con la cookie de formato abierto, pero no otros datos. La aplicación del cliente descifra la cookie cifrada para obtener la información del usuario.Si la parte confidente recibe una aserción con distintos valores de atributo, transfiere todos los valores a la aplicación de destino.
- Publicación de cookie de formato abiertoEl usuario se redirige a la aplicación de destino con una redirección HTTP 302 con la cookie de formato abierto, pero los datos se envían en una solicitud HTTP-POST. Si está preocupado por si se pierden los datos debido a la limitación de la longitud de los datos de las cookies, seleccione esta opción.Si se selecciona la opción de cookie de formato abierto o la opción de publicación de cookie de formato abierto, la UI muestra los campos adicionales siguientes:
- Nombre de la cookie de formato abiertoEspecifica el nombre de la cookie de formato abierto.
- Transformación del cifradoIndica el algoritmo de cifrado que cifra la cookie de formato abierto.Si se selecciona uno de los algoritmos compatibles con FIPS (algoritmos de AES), el sistema de destino debe utilizar un SDK deCA SiteMinder® Federationpara consumir la cookie. El SDK debe estar en el mismo servidor que la aplicación de destino.Si está utilizando el SDK .NET para consumir la cookie, utilice el algoritmo de cifrado AES128/CBC/PKCS5Padding.
- Contraseña de cifradoIndica la contraseña que se utiliza para cifrar la cookie. Es obligatorio especificar los campos Contraseña de cifrado y Contraseña de confirmación para la cookie de formato abierto, pero la contraseña es opcional para la cookie heredada.Importante:Si se proporciona una contraseña para la cookie heredada, defina el mismo valor para el SDK de Java deCA SiteMinder® Federation. La contraseña permite que el SDK descifre la cookie. Los valores se comparten en una comunicación fuera de banda.
- Confirmar contraseñaConfirma la entrada de la contraseña de cifrado.
- Habilitar HMACIndica que se genera un código de autenticación de mensaje de hash (HMAC) mediante la contraseña de cifrado de este cuadro de diálogo.Los códigos de autenticación de mensaje (MAC) pueden verificar la integridad de la información que se envía entre dos partes. Las dos partes comparten una clave secreta para el cálculo y la verificación de los valores de autenticación del mensaje. Un código de autenticación de mensaje de hash (HMAC) es un mecanismo de MAC que está basado en funciones de hash de cifrado. Los HMAC tienen una entrada de mensaje y una clave secreta que conoce solamente el creador del mensaje y el receptor al que va destinado.Si se selecciona la casilla de verificación Habilitar HMAC, el sistema genera un valor de HMAC para su la cookie de formato abierto. El valor de HMAC precede al valor de la cookie de formato abierto que luego cifra toda la cadena. El sistema coloca la cadena cifrada en la cookie de formato abierto, que, a continuación, se transfiere a la aplicación de destino.
- Habilitar cookie entrecomilladaEspecifica que el valor de la cookie de formato abierto se encierra en comillas dobles. Esta especificación permite el procesamiento de la cookie en casos en los que se incluyen caracteres no compatibles en el valor de la cookie.
- Encabezados HTTP (SAML 1.1 y 2.0 solamente)El usuario se redirige a la aplicación de destino con encabezados de HTTP, pero no otros datos. El servidor de políticas puede proporcionar varios valores de atributo en un único encabezado separando cada valor con una coma.
- Atributos persistentesSe redirige el usuario mediante una redirección HTTP 302 y una cookie de sesión, pero no otros datos. Este modo además indica al Servidor de políticas que almacene los atributos que se extrajeron de una aserción en el almacén de sesiones.CA Single Sign-onpuede proporcionar a continuación los atributos como variables de encabezado HTTP.Para ver esta opción, habilite el almacén de sesiones mediante la Consola de gestión del Servidor de políticas.Si selecciona Atributos persistentes y la aserción contiene atributos en blanco, se escribe un valor de NULO en el almacén de sesiones. Este valor NULO sirve como marcador de posición para el atributo en blanco y se transfiere a cualquier aplicación mediante el atributo.
- casso127figsbresRedirección del servidorIndica al sistema de la federación que se deben pasar los atributos de encabezado y de cookies recibidos en la aserción a la aplicación de destino. El servicio que consume las aserciones recopila las credenciales de usuario y, a continuación, transfiere el usuario a la dirección URL de la aplicación de destino mediante una redirección del servidor de Java.Para utilizar este modo, siga estos requisitos:
- Todos los archivos de la aplicación de destino deben estar en el directorio raíz de la aplicación. Este directorio puede ser:
- Agente web:directorio_principal_agente_web\webagent\affwebservices
- Puerta de enlace de la federación de SPS:directorio_principal_sps\secure-proxy\Tomcat\webapps\affwebservices
- La dirección URL de destino especificada debeestar relacionadacon el contexto del servlet que consume la aserción. El contexto es/affwebservices/public/y el directorio raíz del contexto es/affwebservices/, que es el directorio raíz de la aplicación Servicios web de la federación. No se debe incluir el contexto en la dirección URL. Por ejemplo, la dirección URL de destino puede ser/applications/doc1.html.
- Defina los territorios, reglas y políticas para proteger los recursos de destino. Los territorios deben contener como mínimo el valor /affwebservices/ en el filtro de recursos.
- Instale una aplicación personalizada de Java o JSP en el servidor que está ejecutando la aplicación de los servicios web de la federación. El Pack de opciones del Agente web o la puerta de enlace de la federación del SPS instalan los servicios web de la federación.La tecnología de servlet de Java admite que las aplicaciones transfieran información entre dos solicitudes de recurso mediante el método setAttribute de la interfaz ServletRequest.El servicio que consume las aserciones envía los atributos de usuario a la aplicación de destino antes de redirigir el usuario al destino. El servicio envía los atributos al crear un objeto java.util.HashMap. El atributo que contiene el HashMap de los atributos de SAML es “Netegrity.AttributeInfo”.El servicio que consume aserciones transfiere los otros dos atributos de Java.lang.String a la aplicación personalizada:
- El atributo Netegrity.smSessionID representa el ID de la sesión.
- El atributo Netegrity.userDN representa el nombre distintivo del usuario.
La aplicación de destino lee estos objetos de la solicitud HTTP y utiliza los datos encontrados en los objetos hashmap.
- DestinoEspecifica la dirección URL de la aplicación de destino en la parte confidente. El valor que se introduce aquí se convierte en el recurso de destino predeterminado. Esta dirección URL debe contener un nombre de dominio totalmente cualificado, a menos que se seleccione Redirección del servidor como modo de redirección. Para la redirección del servidor, la dirección URL de destino debe estarrelacionadacon el contexto del servlet que consume la aserción. El contexto es/affwebservices/public/. No se debe incluir el contexto en la dirección URL. Por ejemplo, la dirección URL de destino puede ser/applications/doc1.html.Si un proxy se coloca frente al servidor con el recurso de destino, introduzca la dirección URL del host del proxy. El proxy gestiona todas las solicitudes de federación de forma local. El host del proxy puede ser cualquier sistema que se coloca frente al servidor de destino. El host del proxy también puede ser el mismo sistema deSingle Sign-On, siempre que se esté accediendo a este directamente desde Internet. En el fondo, cuando se trabaja con un proxy, la dirección URL que se especifica como el destino debe pasar porSingle Sign-On. Por ejemplo, si la dirección URL base es fed.demo.com y el recurso del servidor back-end es mytarget/target.jsp, el valor para este campo es http://fed.demo.com:5555/mytarget/target.jsp.Para SAML 2.0, se puede dejar este campo vacío si se anula con el parámetro de la consulta RelayState. El parámetro de la consulta RelayState puede partir de la dirección URL que activa el inicio de sesión único. Para permitir esta anulación, seleccione la casilla de verificación El estado de transmisión invalida el destino.
- Tiempo de espera de la inactividadDetermina la cantidad de tiempo de que la sesión de un usuario autorizado puede permanecer inactiva antes de que el agente termine la sesión. Si le preocupa que los usuarios dejen sus estaciones de trabajo después de haber accedido a un recurso protegido, establezca el tiempo de espera de la inactividad a un período de tiempo más corto. Si la sesión finaliza, los usuarios deben volver a autenticarse antes de acceder de nuevo a los recursos.Este ajuste está activado de forma predeterminada. Si no se desea especificar ningún tiempo de espera de la inactividad, desactive la casilla de verificación. El tiempo de espera de la inactividad predeterminado es de una hora.NotaEn realidad, la sesión caduca en un determinado período de tiempo de mantenimiento después del valor de tiempo de espera de la inactividad especificado. El número de segundos especificados en la siguiente clave de registro determina el período de tiempo:HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\CA Single Sign-on\CurrentVersion\SessionServer\MaintenancePeriodPor ejemplo, se establece que el tiempo de espera de la inactividad es de hasta 10 minutos. También se establece que el registro para MaintenancePeriod al valor predeterminado. El período más largo antes de que una sesión finalice por inactividad es 11 minutos (tiempo de espera + período mantenimiento).Para utilizar esta función con el esquema de autenticación Básica, habrá que configurar el Agente web para que para exija cookies.Hay que tener en cuenta los problemas siguientes:
- Para sesiones persistentes, habilite el tiempo de espera de la inactividad y establecerlo con un valor superior al especificado en el Período de validación.
- Puede anular esta configuración global si usa el atributo de respuesta WebAgent-OnAuthAccept-Session-Idle-Timeout. Un valor de cero indica que la sesión no termina por inactividad.
Valor predeterminado: 60 segundosHorasEspecifica el número de horas para el período de tiempo de espera de la inactividad.MinutosEspecifica el número de minutos para el período de tiempo de espera de la inactividad.Tiempo de espera máximoDetermina la cantidad máxima de tiempo que la sesión de un usuario puede estar activa antes de que el agente pida al usuario que se vuelva a autenticar.Este ajuste está activado de forma predeterminada. Si no se desea especificar ninguna duración máxima de sesión, desactive la casilla de verificación. La duración máxima de sesión predeterminada es de dos horas.- HorasEspecifica el número de horas para la duración de sesión máxima.
- MinutosEspecifica el número de minutos para la duración de sesión máxima.
Para utilizar esta función con el esquema de autenticación Básico, configure el Agente web para que exija cookies.NotaSe puede anular esta configuración mediante el atributo de respuesta WebAgent-OnAuthAccept-Session-Max-Timeout. - El estado de transmisión invalida el destino (solo SAML 2.0)(Opcional) Sustituye el valor del campo de destino con el valor del parámetro de la consulta Relay State en la solicitud que inicia el inicio de sesión único. Si se selecciona esta opción, se tiene más control sobre el destino porque mediante el parámetro de la consulta Relay State se puede definir dinámicamente el destino.
- Validar dominio de la dirección URL de destino(Solo SAML 2.0) Indica al servidor de políticas que compare el valor del campo Destino o el destino del parámetro de la consulta RelayState con el parámetro ValidFedTargetDomain en el Objeto de configuración del agente. Esta configuración contribuye a garantizar que la parte confidente permite el acceso al dominio de destino solicitado.
- Persistir las variables de la sesión de autenticaciónPermite que la información de una aserción se guarde en el almacén de sesiones y se escriba en el contexto de sesión. Al guardar información de aserción en el almacén de sesiones puede utilizar la información para funciones, como respuestas activas y expresiones de política. Si se selecciona esta casilla de verificación, la información de aserción que se almacena incluye valores de NameID, NameIDFormat, ProviderID y AuthnContext.Esta configuración difiere de la opción Atributos persistentes para el modo de redirección a la aplicación de destino. Cuando se persisten las variables de la sesión de autenticación, el uso de la información está disponible como más que simples encabezados HTTP.Importante: Para ver esta casilla de verificación, habilite el almacén de sesiones mediante la Consola de gestión del Servidor de políticas. También, puede seleccionar la casilla de verificación Utilizar sesión persistente en los valores de configuración de Inicio de sesión único de la configuración de la asociación.
- El parámetro de la consulta invalida el destino predeterminado (solo SAML 1.1)(Opcional) Sustituye el valor del campo de destino con el valor del parámetro de la consulta Target en la solicitud que inicia el inicio de sesión único. Si se selecciona esta opción, se tiene más control sobre el destino porque mediante el parámetro de la consulta puede definir dinámicamente el destino.
- Período de validez de la cookieIndica la cantidad de tiempo que la cookie de formato abierto es válida. El período de validez se coloca en la cookie, para que la aplicación de destino pueda verificar que la cookie es válida antes de consumir los datos. Se puede establecer este valor para la cookie de formato abierto y los modos de redirección de encabezados HTTP (los encabezados HTTP usan la cookie de formato abierto). Para la cookie de formato abierto, la aplicación determina qué hacer cuando caduca la cookie. Para encabezados HTTP,CA Single Sign-ondeja de enviar la cookie caducada.Introduzca el tiempo en horas, minutos y segundos. El valor 00:00:00 indica que la cookie no caduca nunca.
Configuración de aplicación de destino (OAuth)
En la sección Aplicación de destino se especifica la aplicación de destino y cómo se dirigen usuarios a la aplicación de destino.
- Modo de redirecciónIndica el método por el cual la parte confidente redirige el usuario al recurso de destino. Los valores posibles son los siguientes:
- Sin datosEspecifica que se redirija al usuario a la aplicación de destino con una redirección HTTP 302 con una cookie de sesión, pero no con otros datos.
- Datos de la cookieEspecifica que se redirija al usuario a la aplicación de destino a través de una redirección HTTP 302 con una cookie de sesión y datos adicionales de la cookie que está configurada en la parte que afirma. Si se selecciona esta opción, la siguiente se encuentra disponible:
- La dirección URL codifica los datos de la cookie del atributo.Indica que el atributo enviado en la cookie es una dirección URL codificada. La designación de dirección URL codificada es necesaria porque los caracteres de la dirección URL sirven para un fin único, distinto al normal para una dirección URL. Esta configuración es solamente válida con la opción Datos de la cookie como el modo de redirección. Si los datos de la cookie incorporan reclamaciones con varios valores, se debe seleccionar esta opción.Si se especifica cualquier carácter especial en la tabla de atributos de aplicación, seleccione esta opción. Por ejemplo, seleccione esta configuración para los atributos con caracteres japoneses. Se pueden agregar caracteres especiales de la lista desplegable o introducirlos manualmente. Por otro lado, la aplicación de destino debe descodificar mediante URL el nombre y el valor del atributo de la aplicación recibido.
- Cookie de formato abiertoEspecifica que se redirija al usuario a la aplicación de destino con una redirección HTTP 302 con la cookie de formato abierto, pero no otros datos. La aplicación del cliente descifra la cookie cifrada para obtener la información del usuario.Si la parte confidente recibe una reclamación con distintos valores de atributo, transfiere todos los valores a la aplicación de destino.
- Publicación de cookie de formato abiertoEl usuario se redirige a la aplicación de destino con una redirección HTTP 302 con la cookie de formato abierto, pero los datos se envían en una solicitud HTTP-POST. Si está preocupado por si se pierden los datos debido a la limitación de la longitud de los datos de las cookies, seleccione esta opción.
- Nombre de la cookie de formato abiertoEspecifica el nombre de la cookie de formato abierto.
- Transformación del cifradoIndica el algoritmo de cifrado que se va a utilizar para cifrar la cookie de formato abierto.Si se selecciona uno de los algoritmos compatibles con FIPS (algoritmos de AES), el sistema de destino debe utilizar un SDK de sistema para consumir la cookie. El SDK debe estar en el mismo servidor que la aplicación de destino.Si está utilizando el SDK .NET para consumir la cookie, utilice el algoritmo de cifrado AES128/CBC/PKCS5Padding.
- Contraseña de cifradoIndica la contraseña que se utiliza para cifrar la cookie.
- Confirmar contraseñaConfirma la entrada de la contraseña de cifrado.
- Habilitar HMACIndica que se genera un código de autenticación de mensaje de hash (HMAC) mediante la contraseña de cifrado de este cuadro de diálogo.Los códigos de autenticación de mensaje (MAC) pueden verificar la integridad de la información que se envía entre dos partes. Las dos partes comparten una clave secreta para el cálculo y la verificación de los valores de autenticación del mensaje. Un código de autenticación de mensaje de hash (HMAC) es un mecanismo de MAC que está basado en funciones de hash de cifrado. Los HMAC tienen una entrada de mensaje y una clave secreta que conoce solamente el creador del mensaje y el receptor al que va destinado.Si se selecciona la casilla de verificación Habilitar HMAC, el sistema genera un valor de HMAC para su la cookie de formato abierto. El valor de HMAC precede al valor de la cookie de formato abierto que luego cifra toda la cadena. El sistema coloca la cadena cifrada en la cookie de formato abierto, que, a continuación, se transfiere a la aplicación de destino.
- Habilitar cookie entrecomilladaEspecifica que el valor de la cookie de formato abierto se encierra en comillas dobles. Esta especificación permite el procesamiento de la cookie en casos en los que se incluyen caracteres no compatibles en el valor de la cookie.
- Período de validez de la cookieIndica la cantidad de tiempo que la cookie de formato abierto es válida. El período de validez se coloca en la cookie, para que la aplicación de destino pueda verificar que la cookie es válida antes de consumir los datos. La aplicación decide qué hacer cuando caduca la cookie.Introduzca el tiempo en horas, minutos y segundos.
- Encabezados HTTP (solo modo Proxy)El usuario se redirige a la aplicación de destino con encabezados de HTTP, pero no otros datos.
- Reclamaciones persistentes realizadas en el almacén de la sesiónSe redirige el usuario mediante una redirección HTTP 302 y una cookie de sesión, pero no otros datos. Este modo además indica al Servidor de políticas que almacene los atributos que se extrajeron de una aserción en el almacén de sesiones. A continuación, el sistema puede proporcionar los atributos como variables del encabezado HTTP.NotaSe puede seleccionar PersistAttributes y la aserción contiene atributos que se dejan en blanco. En este caso, se escribe un valor NULO en el almacén de sesiones. Este valor sirve como marcador de posición para el atributo vacío y se transfiere a cualquier aplicación mediante el atributo.
- DestinoEspecifica la dirección URL de la aplicación de destino en la parte confidente. El valor que se introduce aquí se convierte en el recurso de destino predeterminado. La dirección URL debe contener un nombre de dominio totalmente cualificado.Si un proxy se coloca frente al servidor con el recurso de destino, introduzca la dirección URL del host del proxy. El proxy gestiona todas las solicitudes de federación de forma local. El host del proxy puede ser cualquier sistema que se coloca frente al servidor de destino. El host del proxy puede ser también el propio sistema, siempre que se esté accediendo a tal sistema directamente desde Internet. En el fondo, cuando se trabaja con un proxy, la dirección URL que se especifica como el destino debe pasar por el sistema de federación. Por ejemplo, si la dirección URL base es fed.demo.com y el recurso del servidor back-end es mytarget/target.jsp, el valor para este campo es http://fed.demo.com:5555/mytarget/target.jsp.Deje vacío este campo si lo invalida con el parámetro de la consulta RelayState. El parámetro de la consulta RelayState puede partir de la dirección URL que activa el inicio de sesión único. Para permitir esta anulación, seleccione la casilla de verificación El estado de transmisión invalida el destino.
- Tiempo de espera de la inactividadDetermina la cantidad de tiempo que la sesión de un usuario autorizado puede permanecer inactiva antes de que el sistema de federación finalice la sesión. Si le preocupa que los usuarios dejen sus estaciones de trabajo después de haber accedido a un recurso protegido, establezca el tiempo de espera de la inactividad a un período de tiempo más corto. Si la sesión finaliza, los usuarios deben volver a autenticarse antes de acceder de nuevo a los recursos.Este ajuste está activado de forma predeterminada. Si no se desea especificar ningún tiempo de espera de la inactividad, desactive la casilla de verificación. El tiempo de espera de la inactividad predeterminado es de una hora.NotaPara sesiones persistentes, habilite la opción Tiempo de espera de inactividad y defínalo como un valor superior al especificado en Período de validación.Valor predeterminado: 1 horaHorasEspecifica el número de horas para el período de tiempo de espera de la inactividad.MinutosEspecifica el número de minutos para el período de tiempo de espera de la inactividad.Tiempo de espera máximoDetermina la cantidad máxima de tiempo que la sesión de un usuario puede estar activa antes de que el sistema de federación pida al usuario que se vuelva a autenticar.Este ajuste está activado de forma predeterminada. Si no se desea especificar ninguna duración máxima de sesión, desactive la casilla de verificación.Valor predeterminado: 2 horas
- HorasEspecifica el número de horas para la duración de sesión máxima.
- MinutosEspecifica el número de minutos para la duración de sesión máxima.
- El estado de transmisión invalida el destino(Opcional) Sustituye el valor del campo de destino con el valor del parámetro de la consulta Relay State en la solicitud que inicia el inicio de sesión único. Si se selecciona esta opción, se tiene más control sobre el destino porque mediante el parámetro de la consulta Relay State se puede definir dinámicamente el destino.
- Validar dominio de la dirección URL de destinoIndica al sistema de federación que compare el valor del campo Destino o el destino especificado en el parámetro de la consulta RelayState con el parámetro ValidFedTargetDomain en el Objeto de configuración del agente. Esta configuración contribuye a garantizar que la parte confidente permite el acceso al dominio de destino solicitado.
Asignación a los atributos de aplicación (SAML y WSFED)
La sección Asignar a los atributos de aplicación determina cómo asignar atributos de aserción a atributos que la aplicación de destino utiliza.
- Asignar a los atributos de aplicaciónIndica que la asignación de atributos atributo está habilitada. Si se selecciona la casilla de verificación Enable Application Attributes (Habilitar atributos de la aplicación), aparece la tabla Definiciones del atributo de la aplicación. Esta tabla le permite especificar cómo se asigna los atributos de la aplicación a atributos de aserción.Es obligatorio introducir un valor en las siguientes columnas de la tabla:Atributo de la aplicaciónMuestra el atributo que la aplicación de destino utiliza. De forma predeterminada, el nombre del atributo de la aplicación es el mismo que el nombre del atributo de la aserción. Se puede cambiar el nombre del atributo de la aplicación por cualquier nombre que necesite la aplicación.Atributo de aserciónEspecifica los atributos de la aserción que se desean utilizar como la base para asignar un atributo de la aplicación.Si se selecciona el botón <<, aparece el campo Anexar. En la lista desplegable Anexar, se pueden seleccionar atributos de aserción disponibles y caracteres especiales para incluirlos en la regla de asignación.
Asignación a los atributos de aplicación (OAuth)
La sección Asignación a los atributos de aplicación determina cómo asignar atributos de reclamación a atributos que utiliza la aplicación de destino.
- Asignar a los atributos de aplicaciónIndica que la asignación de atributos atributo está habilitada. Si se selecciona la casilla de verificación Habilitar asignación de atributos, se mostrará la tabla Definición de atributos de la aplicación. Esta tabla le permite especificar cómo se asigna los atributos de la aplicación a atributos de aserción.Es obligatorio introducir un valor en las siguientes columnas de la tabla:Atributo de la aplicaciónMuestra el atributo que la aplicación de destino utiliza. De forma predeterminada, el nombre del atributo de la aplicación es el mismo que el nombre del atributo de la aserción. Se puede cambiar el nombre del atributo de la aplicación por cualquier nombre que necesite la aplicación.Atributos de reclamaciónEspecifica los atributos de las reclamaciones que se desean utilizar como la base para asignar un atributo de la aplicación.Si se selecciona el botón <<, aparece el campo Anexar. En la lista desplegable Anexar, se pueden seleccionar caracteres especiales para incluirlos en la regla de asignación.
Aprovisionamiento de usuarios (SAML y WSFED)
La sección Aprovisionamiento de usuarios le permite determinar cómo una aplicación de aprovisionamiento de terceros establece las cuentas de usuario.
- Aprovisionamiento de usuariosEsta sección le permite determinar cómo funciona el aprovisionamiento de usuarios.
- Tipo de aprovisionamientoIndica si una aplicación de aprovisionamiento remota establece cuentas de usuario. Si el Servidor de políticas está funcionando con una aplicación de aprovisionamiento, seleccione Remoto.Predeterminado: NingunoOpciones: Ninguno, RemotoNotaSe puede seleccionar Remoto como el Tipo de aprovisionamiento. En este caso, configure una opción de entrega que transfiere los datos de la aserción a la aplicación de aprovisionamiento.
- Opción de entrega(Aprovisionamiento remoto solamente) Define cómo el explorador se vuelve a dirigir con los datos de aserción a la aplicación de aprovisionamiento. Los datos de aserción se pueden transferir en una cookie o en encabezados HTTP.Opciones:
- Cookie de formato abiertoProporciona información sobre la aserción de SAML en una cookie de formato abierto. Si se utiliza una cookie de formato abierto, la aplicación de aprovisionamiento puede leer la cookie sin utilizar un SDK. Si la aplicación de aprovisionamiento utiliza .NET, el SDK de .NET se puede instalar en el servidor de aprovisionamiento y utilizarse para leer la cookie de formato abierto.
- Publicación de cookie de formato abiertoProporciona la información de la aserción en una cookie de formato abierto, pero los datos se envían en una solicitud HTTP-POST. Si está preocupado por si se pierden los datos debido a la limitación de la longitud de los datos de las cookies, seleccione esta opción.
- Encabezados HTTPEl Servidor de políticas transfiere datos de aserción en encabezados HTTP.
- Dirección URL del servidor de aprovisionamientoIdentifica la dirección URL del servidor de terceros que aloja la aplicación de aprovisionamiento.Valor: una dirección URL válida
Si se selecciona cualquiera de las opciones de las cookies de formato abierto, complete los campos opcionales siguientes:
Nombre de la cookie de formato abierto
Especifica el nombre de la cookie de formato abierto.
- Transformación del cifradoIndica el algoritmo de cifrado que cifra la cookie de formato abierto.
- Contraseña de cifradoIndica la contraseña que se utiliza para cifrar la cookie. Es obligatorio especificar los campos Contraseña de cifrado y Contraseña de confirmación para la cookie de formato abierto, pero los parámetros son opcionales para la cookie heredada.Importante: Si se proporciona una contraseña a la cookie heredada, utilice el mismo valor para el SDK de Java deCA SiteMinder® Federation. El SDK necesita la contraseña para descifrar la cookie. Los valores se comparten en una comunicación fuera de banda.
- Confirmar contraseñaConfirma la entrada de la contraseña de cifrado.
- Habilitar HMACIndica que el sistema genera un código de autenticación de mensaje de hash (HMAC) mediante la contraseña de cifrado de este cuadro de diálogo.Los códigos de autenticación de mensaje (MAC) pueden verificar la integridad de la información que se envía entre dos partes. Las dos partes comparten una clave secreta para el cálculo y la verificación de los valores de autenticación del mensaje. Un código de autenticación de mensaje de hash (HMAC) es un mecanismo de MAC que está basado en funciones de hash de cifrado. Los HMAC tienen una entrada de mensaje y una clave secreta que conoce solamente el creador del mensaje y el receptor al que va destinado.Si se selecciona la casilla de verificación Habilitar HMAC, el sistema genera un valor de HMAC para su la cookie de formato abierto. El valor de HMAC precede al valor de la cookie de formato abierto que luego cifra toda la cadena.CA Single Sign-oncoloca la cadena cifrada en la cookie de formato abierto que, a continuación, se transfiere a la aplicación de destino.
- Habilitar cookie entrecomilladaEspecifica que el valor de la cookie de formato abierto se encierra en comillas dobles. Esta especificación permite el procesamiento de la cookie en casos en los que se incluyen caracteres no compatibles en el valor de la cookie.
Período de validez de la cookie
Indica la cantidad de tiempo que la cookie de formato abierto es válida. El período de validez se coloca en la cookie, para que la aplicación de destino pueda verificar que la cookie es válida antes de consumir los datos. Se puede establecer este valor para la cookie de formato abierto y los modos de redirección de encabezados HTTP (los encabezados HTTP usan la cookie de formato abierto). Para la cookie de formato abierto, la aplicación determina qué hacer cuando caduca la cookie. Para los encabezados HTTP, el agente deja de enviar la cookie caducada.
Introduzca el tiempo en horas, minutos y segundos.
Aprovisionamiento de usuarios (OAuth)
La sección Aprovisionamiento de usuarios le permite determinar cómo una aplicación de aprovisionamiento de terceros establece las cuentas de usuario.
- Tipo de aprovisionamientoIndica si una aplicación de aprovisionamiento remota establece cuentas de usuario.
- Opción de entregaDefine cómo se redirige un explorador con los datos del usuario a la aplicación de aprovisionamiento. El sistema de federación puede transferir los datos del usuario mediante una cookie o encabezados HTTP. Las opciones posibles se enumeran a continuación:
- Cookie de formato abiertoProporciona información sobre el usuario de OAuth en una cookie de formato abierto. Si se utiliza una cookie de formato abierto, la aplicación de aprovisionamiento puede leer la cookie sin utilizar un SDK. Si la aplicación de aprovisionamiento utiliza .NET, instale el SDK de .NET en el servidor de aprovisionamiento; este se utiliza para leer la cookie de formato abierto.
- Publicación de cookie de formato abiertoProporciona la información del usuario de OAuth en una cookie de formato abierto, pero los datos se envían en una solicitud HTTP-POST. Si está preocupado por si se pierden los datos debido a la limitación de la longitud de los datos de las cookies, seleccione esta opción.
- Nombre de la cookie de formato abiertoEspecifica el nombre de la cookie de formato abierto.
- Transformación del cifradoIndica el algoritmo de cifrado para cifrar la cookie de formato abierto.
- Contraseña de cifrado y Contraseña de confirmaciónIndica la contraseña que se utiliza para cifrar la cookie. Los campos Contraseña de cifrado y Contraseña de confirmación son obligatorios para la cookie de formato abierto.
- Habilitar HMACIndica que se genera un código de autenticación de mensaje de hash (HMAC) mediante la contraseña de cifrado de este cuadro de diálogo.Los códigos de autenticación de mensaje (MAC) pueden verificar la integridad de la información que se envía entre dos partes. Las dos partes comparten una clave secreta para el cálculo y la verificación de los valores de autenticación del mensaje. Un código de autenticación de mensaje de hash (HMAC) es un mecanismo de MAC que está basado en funciones de hash de cifrado. Los HMAC tienen una entrada de mensaje y una clave secreta que conoce solamente el creador del mensaje y el receptor al que va destinado.Si se selecciona la casilla de verificación Habilitar HMAC, el sistema genera un valor de HMAC para su la cookie de formato abierto. El valor de HMAC precede al valor de la cookie de formato abierto que luego cifra toda la cadena. El sistema de federación coloca la cadena cifrada en la cookie de formato abierto, que, a continuación, se transfiere a la aplicación de destino.
- Habilitar cookie entrecomilladaEspecifica que el valor de la cookie de formato abierto se encierra en comillas dobles. Esta especificación permite el procesamiento de la cookie en casos en los que se incluyen caracteres no compatibles en el valor de la cookie.
Encabezados HTTP (solo modo Proxy)
- Si el sistema funciona en el modo Proxy, transferirá los datos de aserción en encabezados HTTP.
- Dirección URL del servidor de aprovisionamientoIdentifica la dirección URL del servidor de terceros que aloja la aplicación de aprovisionamiento.
- Período de validez de la cookieIndica la cantidad de tiempo que la cookie de formato abierto es válida. El período de validez se coloca en la cookie, para que la aplicación de destino pueda verificar que la cookie es válida antes de consumir los datos. Se puede establecer este valor para los modos de redirección de encabezados HTTP y cookie de formato abierto. Los encabezados HTTP utilizan la cookie de formato abierto. Para la cookie de formato abierto, la aplicación determina qué hacer cuando caduca la cookie. Para los encabezados HTTP, el sistema deja de enviar la cookie caducada.
Direcciones URL de redirección de estados (SAML y WSFED)
La sección Dirección URL de redirección de estados le permite determinar cómo
CA Single Sign-on
redirige a un usuario cuando se produce un error en la autenticación.La autenticación basada en la aserción puede producir un error en el sitio que consume aserciones. Si se produce un error en la autenticación, el sistema de federación proporciona la funcionalidad para dirigir el usuario a aplicaciones diferentes (direcciones URL) para el procesamiento posterior. Por ejemplo, cuando se produce un error en la desambiguación de un usuario, se puede configurar
CA Single Sign-on
para enviar el usuario a un sistema de aprovisionamiento. El sistema de aprovisionamiento puede crear una cuenta de usuario basada en la información encontrada en la aserción de SAML.Se pueden configurar uno o más de estas opciones. Si se produce la condición que ha provocado el error,
CA Single Sign-on
redirige al usuario a la dirección URL configurada.Nota
: El redireccionamiento del error solamente se produce cuando el sistema puede analizar la solicitud correctamente y obtener la información necesaria para identificar los partners confidentes y asertivos.Los valores de configuración son los siguientes:
- No se ha encontrado al usuario.Identifica la dirección URL a la que el sistema redirige al usuario en una de las condiciones siguientes:
- El mensaje de inicio de sesión único no tiene un LoginID
- El directorio de usuarios no contiene el LoginID con la cadena de búsqueda definida.
- Mensaje de inicio de sesión único no válidoIdentifica la dirección URL a la queCA Single Sign-onredirige al usuario en una de las condiciones siguientes:
- El mensaje de inicio de sesión único no es válido según las reglas que de los esquemas de SAML.
- El consumidor requiere una aserción cifrada pero el mensaje de inicio de sesión único no contiene una aserción cifrada.
- No se aceptan las credenciales del usuario (mensaje de inicio de sesión único)Identifica la dirección URL a la queCA Single Sign-onredirige al usuario en la mayoría de las condiciones de error. Algunas condiciones de error representan una excepción, como cuando un usuario no se encuentra o el mensaje de inicio de sesión único no es válido. La aserción puede ser válida, peroCA Single Sign-onno acepta el mensaje por varios motivos, como:
- Se produce un error en la validación de la firma electrónica XML
- (SAML 2.0) Se produce un error en la operación de descifrado XML
- Se produce un error en la validación XML de condiciones, como un mensaje caducado o un error de coincidencia de público.
- Ninguna de las aserciones del mensaje de inicio de sesión único contiene una declaración de autenticación.
- 302 No hay datos (valor predeterminado)Redirige el usuario mediante una redirección HTTP 302 con una cookie de sesión, pero no otros datos.
- Método HTTP PostRedirige el usuario mediante el protocolo Método HTTP Post.
Direcciones URL de redirección adicionales para SAML 2.0
Para un Proveedor de servicios de SAML 2.0, se puede especificar direcciones URL de redirección para errores HTTP 500, 400 y 405. Seleccione las opciones de redirección que se deseen habilitar y, a continuación, introduzca una dirección URL asociada. Las opciones disponibles son:
- Habilitar redirección de errores del servidorURL de error del servidor: especifica la dirección URL a la que se redirige el usuario cuando se produce un error HTTP 500 Server. Un usuario puede encontrar un error 500 porque una condición inesperada impide al servidor web que cumpla la solicitud del cliente. Si este tipo de error ocurre, el usuario se envía a la dirección URL especificada para que continúe el procesamiento.Por ejemplo: http://www.redirectmachine.com/error_pages/server_error.html
- Habilitar redirección de solicitudes inválidasDirección URL de la solicitud no válida: especifica la dirección URL a la que redirige el usuario cuando se produce un error HTTP 400 Bad Request o 405 Method Not Allowed. Un usuario puede encontrar un error 400 porque una solicitud está mal formada. Un usuario puede encontrarse también con un error 405 porque el servidor web no permite llevar a cabo un método o acción en concreto. Si se producen estos tipos de errores, el usuario se envía a la dirección URL especificada para que continúe con el procesamiento.Por ejemplo: http://www.redirectmachine.com/error_pages/invalidreq_error.html
- Habilitar redirección de accesos no autorizadosDirección URL del acceso no autorizado: especifica la dirección URL a la que se redirige el usuario cuando se produce un error HTTP 403 Forbidden. Un usuario puede encontrarse con un error 403 porque la dirección URL de una solicitud está señalando el destino incorrecto, como un directorio en lugar de un archivo. Si este error ocurre, el usuario se envía a la dirección URL especificada para que continúe el procesamiento.Por ejemplo: http://www.redirectmachine.com/error_pages/unauthorized_error.html
Direcciones URL de redirección de estados (OAuth)
La sección Dirección URL de redirección de estados le permite determinar cómo
CA Single Sign-on
redirige a un usuario cuando se produce un error en la autenticación.La autenticación basada en la aserción puede producir un error en el sitio que consume aserciones. Si se produce un error en la autenticación, CA Federation Standalone proporciona la funcionalidad para dirigir el usuario a aplicaciones diferentes (direcciones URL) para el procesamiento posterior. Por ejemplo, cuando se produce un error en la desambiguación de un usuario, se puede configurar
CA Single Sign-on
para enviar el usuario a un sistema de aprovisionamiento. El sistema de aprovisionamiento puede crear una cuenta de usuario basada en la información encontrada en la aserción de SAML.Se pueden configurar uno o más de estas opciones. Si se produce la condición que ha provocado el error,
CA Single Sign-on
redirige al usuario a la dirección URL configurada.Los valores de configuración son los siguientes:
- Se ha producido un error en el servidor remoto
- OAuth 2.0Identifica la dirección URL donde el sistema dirige al usuario en los siguientes errores especificados de OAuth 2.0:
- El servidor de autorización encontró una condición inesperada que le impide cumplir la solicitud del usuario.
- El servidor de autorización no puede procesar la solicitud del usuario debido a una sobrecarga temporal o al mantenimiento del servidor.
- OAuth 1.0aIdentifica la dirección URL donde el sistema dirige al usuario cuando el servidor de autorización envía un error 500 de HTTP.
- Mensaje de solicitud no válido
- OAuth 2.0Identifica la dirección URL donde el sistema dirige al usuario en los siguientes errores especificados de OAuth 2.0:
- La solicitud del usuario tiene una sintaxis incorrecta.
- El ámbito solicitado del usuario no es válido, se desconoce o tiene un formado incorrecto.
- El servidor de autorización no es compatible con la obtención de un código de autorización en el método especificado.
- OAuth 1.0aIdentifica la dirección URL donde el sistema dirige al usuario cuando el servidor de autorización envía un error 400 o 404 de HTTP.
- Credenciales del usuario que no se aceptan
- OAuth 2.0Identifica la dirección URL a la que CACA Single Sign-onFederation Standalone dirige al usuario bajo los siguientes errores especificados de OAuth 2.0:
- El cliente no tiene autorización para solicitar un código de autorización mediante el método especificado.
- El servidor de autorización ha denegado la solicitud.
- OAuth 1.0aIdentifica la dirección URL donde el sistema dirige al usuario cuando el servidor de autorización envía un error 401 o 403 de HTTP.
- 302 No hay datos (valor predeterminado)Redirige el usuario mediante una redirección HTTP 302 con una cookie de sesión, pero no otros datos.
- Método HTTP PostRedirige el usuario mediante el protocolo Método HTTP Post.