Access Gateway et sessions

Types de sessions et cycles de vie

Access Gateway utilise trois types de sessions selon la nature des ressources auxquelles l'utilisateur accède :

• Session Okta : Okta crée une session lorsque l'utilisateur final s'authentifie directement auprès d'une org ou lorsqu'Access Gateway redirige une requête vers l'org. Les administrateurs peuvent configurer les conditions de ces sessions dans l'org Okta.

• Session Access Gateway : Access Gateway crée cette session lorsqu'un utilisateur a demandé à accéder à une app protégée et qu'Okta l'a authentifié. Les administrateurs gèrent ces sessions dans l'Console Access Gateway Admin UI. Consultez Paramètres avancés de l'application et Définir les comportements de l'application. Consultez Configurer les paramètres d'application avancés, qui inclut également des informations sur les valeurs et les limites valides pour la configuration de session. Access Gateway ne partage pas les informations de session entre les instances dans les clusters à haute disponibilité. Lorsque vous déployez des équilibreurs de charge en amont de votre cluster, vous devez spécifier l'affinité de session (également appelée « session permanente »). Vous garantissez ainsi que les requêtes suivantes seront acheminées vers la même instance d'Access Gateway.

• Session d'app : Access Gateway crée cette session après qu'Okta a authentifié l'utilisateur ou lorsque la requête est redirigée vers l'app protégée. Access Gateway modifie la requête Web en fournissant des champs d'en-tête, des cookies et d'autres informations requises, puis la transmet à l'app protégée. La ressource crée et gère ensuite son propre en-tête d'app. Les politiques de l'app régissent les paramètres de la session d'app.

Flux de session

Vous pouvez initier des sessions depuis Access Gateway ou depuis Okta.

Flux de session basé sur Access Gateway ou un fournisseur de services

Dans ce scénario, l'utilisateur final accède directement à une app. Il se voit accorder une session Okta unique et une session pour chaque app à laquelle il accède.

1. L'utilisateur tente d'accéder directement à une app protégée, sans passer par Okta.
2. Access Gateway intercepte la requête et la redirige vers Okta, qui exécute l'assertion SAML ( Security Assertion Markup Language ).
3. Le navigateur de l'utilisateur envoie une demande d'authentification SAML à Okta et se connecte à l'app. Si l'authentification réussit, Okta crée une session Okta.
4. Okta génère une assertion SAML pour Access Gateway.
5. Le navigateur de l'utilisateur présente l'assertion SAML à Access Gateway. Access Gateway crée un cookie de session Access Gateway.
6. Access Gateway effectue les tâches suivantes :
   1. Crée une session Access Gateway.
   2. Ajoute les améliorations d'apps obligatoires, telles que des attributs d'en-tête ou de cookie.
   3. Effectue les réécritures requises.
   4. Met la requête en proxy vers une ressource back-end protégée.
7. Une ressource Web protégée du back-end reçoit la requête, crée une session d'app, puis renvoie une réponse à Access Gateway.
8. Access Gateway effectue toutes les réécritures requises et renvoie la réponse.

Flux de session basé sur Okta ou un fournisseur d'identité

Dans ce scénario, l'utilisateur final accède à une app via Okta Dashboard. Il se voit accorder une session Okta unique, et une session pour chaque app à laquelle il accède.

1. L'utilisateur se connecte à Okta, et Okta crée une session Okta pour son compte.
2. L'utilisateur clique sur une vignette d'app dans son End-User Dashboard et est redirigé vers Access Gateway.
3. Access Gateway crée une session Access Gateway .
4. Access Gateway effectue les tâches suivantes :
   1. Ajoute les améliorations d'apps obligatoires, telles que des attributs d'en-tête ou de cookie.
   2. Effectue les réécritures requises.
   3. Redirige vers une ressource Web protégée en back-end.
5. Une ressource Web protégée du back-end reçoit la requête, crée des sessions d'app et renvoie une réponse à Access Gateway.
6. Access Gateway effectue toutes les réécritures requises et renvoie la réponse.

Déconnexion unique et Universal Logout

L'authentification fédérée Okta prend en charge deux types de flux de déconnexion :

• Déconnexion unique : vous pouvez utiliser la déconnexion unique (SLO) pour vous déconnecter simultanément des sessions d'app et des sessions Okta dans les flux initiés par le fournisseur de services. Lorsque la déconnexion unique est activée, Access Gateway agit en tant que fournisseur de services et Okta agit en tant que fournisseur d'identité.

• Universal Logout : les administrateurs peuvent configurer les flux de sorte à déconnecter l'utilisateur de l'app et d'Access Gateway simultanément. La fonction Universal Logout ne déconnecte pas l'utilisateur d'Okta.

Consultez Configurer la déconnexion unique dans les intégrations d'apps et Définir les comportements de l'application.