Mejores prácticas para configuraciones de aplicaciones web y SaaS

El acceso a las aplicaciones publicadas y no publicadas depende de las aplicaciones y directivas de acceso configuradas en el servicio Secure Private Access.

Acceso a aplicaciones dentro de Secure Private Access para aplicaciones publicadas y no publicadas

• Acceso a aplicaciones web publicadas y dominios relacionados:

  • Cuando un usuario final accede a un FQDN asociado a una aplicación web publicada, el acceso solo se permite si se configura una directiva de acceso de forma explícita con la acción Permitir o Permitir con restricciones para el usuario.

    Nota:

    Se recomienda que varias aplicaciones no compartan el mismo dominio URL de la aplicación o dominios relacionados para obtener una coincidencia exacta. Si varias aplicaciones comparten el mismo dominio URL de la aplicación o dominios relacionados, el acceso se proporciona en función de la coincidencia exacta del FQDN y de la priorización de las directivas. Para más información, consulte Equiparación y priorización de directivas de acceso.

  • Si ninguna directiva de acceso coincide con la aplicación publicada o si una aplicación no está asociada a ninguna directiva de acceso, se deniega el acceso a la aplicación de forma predeterminada. Para obtener más información sobre las directivas de acceso, consulte Directivas de acceso.

• Acceso a aplicaciones web internas no publicadas y URL de Internet externas:

  Para habilitar la confianza cero, Secure Private Access niega el acceso a las direcciones URL de intranet o aplicaciones web internas que no estén asociadas a una aplicación y que no tengan una directiva de acceso configurada para la aplicación. Para permitir el acceso a usuarios específicos, asegúrese de tener una directiva de acceso configurada para las aplicaciones web de la intranet.

  Para cualquier URL que no esté configurada como una aplicación en Secure Private Access, el tráfico fluye directamente a Internet.

  • En estos casos, el acceso a los dominios URL de las aplicaciones web de la intranet se enruta directamente y, por lo tanto, se deniega el acceso (a menos que el usuario ya esté dentro de la intranet).
  • En el caso de las URL de Internet no publicadas, el acceso se basa en las reglas configuradas para las aplicaciones no autorizadas, si están habilitadas. De forma predeterminada, este acceso está permitido en Secure Private Access. Para obtener más información, consulte Configurar reglas para sitios web no autorizados.

Equiparación y priorización de directivas de acceso

Secure Private Access hace lo siguiente al hacer coincidir una solicitud de acceso:

1. Haga coincidir el dominio al que se accede con el dominio de la URL de la aplicación o con los dominios relacionados para obtener una coincidencia exacta.

2. Si se encuentra una aplicación de Secure Private Access configurada con un FQDN exacto, Secure Private Access evalúa todas las directivas configuradas para esa aplicación.

   • Las directivas se evalúan en orden de prioridad hasta que el contexto del usuario coincida. La acción (permitir/denegar) se aplica según la primera directiva que coincida en el orden de prioridad.
   • Si ninguna directiva coincide, se deniega el acceso de forma predeterminada.

3. Si no se encuentra una coincidencia exacta de FQDN, Secure Private Access busca el dominio basándose en la coincidencia más larga (por ejemplo, una coincidencia de caracteres comodín) para buscar las aplicaciones y las directivas correspondientes.

   Ejemplo 1: Tenga en cuenta las siguientes configuraciones de aplicaciones y directivas:

   Aplicación	URL de la aplicación	Dominio relacionado
   Intranet	https://app.intranet.local	*.cdn.com
   wiki	https://wiki.intranet.local	*.intranet.local

   Nombre de directiva	Prioridad	Aplicaciones de usuario y asociadas
   PolicyA	Alto	Eng-User5 (Intranet)
   PolicyB	Bajo	HR-User4 (Wiki)

   Si HR-User4 accede app.intranet.local, ocurre lo siguiente:

   1. Secure Private Access busca en todas las directivas una coincidencia exacta con el dominio al que se accede, app.intranet.local en este caso.
   2. Secure Private Access busca PolicyA y comprueba si las condiciones coinciden.
   3. Como las condiciones no coinciden, Secure Private Access se detiene aquí y no continúa comprobando las coincidencias de los comodines, aunque PolicyB habría coincidido (ya que app.intranet.local coincide en el dominio relacionado de la aplicación Wiki de *.intranet.local) y habría dado acceso.
   4. Por lo tanto, HR-User4 se niega el acceso a la aplicación Wiki.

   Ejemplo 2: Considere la siguiente configuración de aplicaciones y directivas en las que se usa el mismo dominio en varias aplicaciones:

   Aplicación	URL de la aplicación	Dominio relacionado
   App1	xyz.com	app.intranet.local
   App2	app.intranet.local	-

   Nombre de directiva	Prioridad	Aplicaciones de usuario y asociadas
   PolicyA	Alto	Eng-User 5 (Aplicación 1)
   PolicyB	Bajo	HR-User7 (Aplicación 2)

   Cuando el usuario Eng-User5 acceda a app.intranet.local, tanto la App1 como la App2 coincidirán en función de la coincidencia exacta del FQDN y, por lo tanto, el usuario Eng-User5 tendrá acceso a través de PolicyA.

   Sin embargo, si App1 tuviera *.intranet.local como dominio relacionado, se habría denegado el acceso para Eng-User5, ya que app.intranet.local habría coincidido exactamente con PolicyB, a la cual el usuario Eng-User5 no tiene acceso.

Mejores prácticas de configuración de aplicaciones

Los dominios IDP deben tener una aplicación propia

En lugar de agregar dominios de IDP como dominios relacionados en las configuraciones de las aplicaciones de intranet, le recomendamos lo siguiente:

• Cree aplicaciones independientes para todos los dominios de IDP.
• Cree una directiva para permitir el acceso a todos los usuarios que necesitan acceder a la página de autenticación de IDP y mantenga la directiva como la máxima prioridad.
• Oculte esta aplicación (seleccionando la opción No mostrar el icono de la aplicación a los usuarios) de la configuración de la aplicación para que no aparezca en el espacio de trabajo. Para obtener más información, consulte Configurar los detalles de la aplicación.

Nota:

La configuración de esta aplicación solo permite el acceso a la página de autenticación de IDP. El acceso adicional a las aplicaciones individuales sigue dependiendo de las configuraciones de las aplicaciones individuales y de sus respectivas directivas de acceso.

Ejemplo de configuración:

1. Configure todos los FQDN comunes en sus propias aplicaciones, agrupándolos cuando corresponda.

   Por ejemplo, si tiene algunas aplicaciones que usan Azure AD como IdP y necesita configurar login.microsoftonline.com y otros dominios relacionados (*.msauth.net), haga lo siguiente:

   • Cree una única aplicación común con https://login.microsoftonline.com como URL de la aplicación y *.login.microsoftonline.com y *.msauth.net como dominios relacionados.
2. Seleccione la opción No mostrar el icono de la aplicación a los usuarios al configurar la aplicación. Para obtener más información, consulte Configurar los detalles de la aplicación.
3. Cree una directiva de acceso para la aplicación común y permita el acceso a todos los usuarios. Para obtener más información, consulte Configurar una directiva de acceso.
4. Asigne la máxima prioridad a la directiva de acceso. Para obtener más información, consulte Orden prioritario.
5. Verifique los registros de diagnóstico para confirmar que el FQDN coincide con la aplicación y que la directiva se aplica según lo previsto.

Los mismos dominios relacionados no deben formar parte de varias aplicaciones

El dominio relacionado debe ser exclusivo de una aplicación. Las configuraciones conflictivas pueden provocar problemas de acceso a las aplicaciones. Si se configuran varias aplicaciones con el mismo FQDN o alguna variación del FQDN comodín, es posible que surjan los siguientes problemas:

• Los sitios web dejan de cargarse o pueden mostrar una página en blanco.
• La página Acceso bloqueado puede aparecer al acceder a una URL.
• Es posible que la página de inicio de sesión no se cargue.

Por lo tanto, recomendamos tener un dominio relacionado único para configurarlo en una sola aplicación.

Ejemplos de configuración incorrectos:

• Ejemplo: dominios relacionados duplicados en varias aplicaciones

  Supongamos que tiene 2 aplicaciones en las que ambas necesitan acceder a Okta (example.okta.com):

  Aplicación	dominio URL de la aplicación	Dominio relacionado
  App1	https://code.example.net	example.okta.com
  App2	https://info.example.net	example.okta.com

  Nombre de directiva	Prioridad	Aplicaciones de usuario y asociadas
  Denegar App1 a HR	Alto	Grupo de usuarios HR para App1
  Otorgar a todos el acceso a la aplicación 1	Medio	Habilitar el acceso al grupo de usuarios Everyone to App1
  Otorgue a todos el acceso a App2	Bajo	Habilitar el acceso al grupo de usuarios “Todos” a App2

  Problema con la configuración: aunque la intención era dar acceso a todos los usuarios a App2, el grupo de usuarios HR no puede acceder a App2. El grupo de usuarios HR se redirige a Okta, pero se bloquea debido a la primera directiva que denegó el acceso a la App1 (que también tiene el mismo dominio relacionado example.okta.com que App2).

  Este escenario es muy común para los proveedores de identidad como Okta, pero también puede ocurrir con otras aplicaciones estrechamente integradas con dominios relacionados comunes. Para obtener más información sobre la coincidencia y priorización de directivas, consulte Equiparación y priorización de directivas de acceso.

  Recomendación para la configuración anterior:

  1. Elimine example.okta.com como dominio relacionado de todas las aplicaciones.
  2. Crea una nueva aplicación solo para Okta (con la URL de la aplicación https://example.okta.com y un dominio relacionado de *.okta.com).
  3. Oculta esta aplicación del espacio de trabajo.
  4. Asigne la máxima prioridad a la directiva para eliminar cualquier conflicto.

  Práctica óptima:

  • Los dominios relacionados de una aplicación no deben superponerse con los dominios relacionados de otra aplicación.
  • Si esto ocurre, se debe crear una nueva aplicación publicada para cubrir el dominio relacionado compartido y después el acceso debe configurarse en consecuencia.
  • Los administradores deben evaluar si este dominio relacionado compartido debe aparecer como una aplicación real en Workspace.
  • Si la aplicación no debe aparecer en Workspace, al publicarla, seleccione la opción No mostrar el icono de la aplicación a los usuarios para ocultarla de Workspace.

URL de enlace profundo

Para las URL de enlace profundo, se debe agregar el dominio URL de la aplicación de intranet como dominio relacionado:

Ejemplo:

La aplicación de intranet tiene una URL configurada con https://example.okta.com/deep-link-app-1 como dominio URL de la aplicación principal y el dominio relacionado tiene el dominio URL de la aplicación de intranet, es decir, *.issues.example.net.

En este caso, cree por separado una aplicación de IdP con la URL https://example.okta.com y después el dominio relacionado como *.example.okta.com.