Access Gateway and sessions
- Service provider based flow
- Identity provider (Okta) based flow
- Understanding session lifecycle
When working with Access Gateway there are three session types:
- Okta session - When a end user logs into their Okta org and accesses an application, or when a request is redirected to an Okta org from Access Gateway, an Okta session is created. Okta sessions are managed in an Okta org and subject to the settings associated with that org. An Okta session is created when the user has been successfully authenticated within Okta. Okta Administrators can manage various session timeouts and other details.
- Access Gateway session - When a user requests access to a protected web resource, Access Gateway creates a session for the application request. Timeouts and other behaviors are application specific. See About advanced application settings for more information.
Note, an Access Gateway application session is created after a user has been successfully authenticated within their Okta org and only if they are allowed access to the underlying protected resource. .
- Application session - Application sessions are created after a user has been authenticated, has access to the protected resource within Access Gateway, and the request is redirected to underlying protected web resource.
The following user information is used when creating a session:
||The user can connect to and authenticate within Okta. Typically this involves a username/password and one or more additional MFA factors as required by the Okta Org. Once authenticated, application access requests result in the creation of an Okta session. Okta sessions are subject to the settings, policies and controls defined within the originating Okta org.|
|Access Gateway application specific session||
||The user, as identified to Access Gateway by email address or other identifier, is a member of the group associated with the requested protected web resource. Once identified, Access Gateway creates an application specific session associated with the authenticated users request. The Access Gateway application setting is subject to the settings and policies associated with the application definition. See the Define application behaviors for details of managing application specific settings and behaviors.|
||Access Gateway proxies the protected web resource request to the underling protected resource. Included with the request are header fields, cookies, and any other information required by the application. The application specific request are then provided to the application which creates and manages its own application specific header. See the documentation of the protected web application for details of the life cycle, timeout and other behaviors specific to the application session.|
Service provider based flows:
Service provider based flow
Note, in the service provider based flow example, any number of applications may be involved.
These are represented by the steps 6(ab), 7(ab) and 8(ab).
At the Okta level the end user would have a single session.
At the Access Gateway and backing application level, there would be as many sessions as there are applications being accessed.
- User requests application access.
- Access Gateway intercepts request and redirects to Okta for SAML assertion.
- User (browser) sends SAML AuthN request to Okta, logs into Okta following Okta policies.
On success, Okta creates Okta session.
- Okta Generates a SAML assertion for Access Gateway.
- User (browser) presents SAML assertion to Access Gateway.
Access Gateway creates an Access Gateway session cookie.
- Access Gateway creates Access Gateway session, adds any required application enhancements (header or cookie attributes etc), performs any required rewrites and proxies request to backing protected resource.
- Backing protected web resource receives request, creates application session, and returns response to Access Gateway.
- Access Gateway performs any required rewrites and returns response.
Identify provider based flows:
- User logins to Okta. Okta session is created.
- User selects application from Okta dashboard and is redirected to Access Gateway. Access Gateway creates Access Gateway session
- Access Gateway adds any required application enhancements (header or cookie attributes etc),
performs any required rewrites and redirects to backing protected web resource.
- Backing protected web resource receives request, creates application sessions, and returns response to Access Gateway.
- Access Gateway performs any require rewrites and returns response.
Its important to understand that each session has a distinct lifecycle.
- Each Okta org login has a single session, governed and controlled by the policies of the Okta org. These policies define session creation, time out, log out and invalidation.
- Each Access Gateway application has its own distinct session, governed and controlled by the associated application definition and associated behavior. See Define application behaviors for additional details.
Access Gateway sessions and high availability
Access Gateway does not share session information between instances in high availability clusters. When defining clusters which are front ended by load balancers, session affinity, often referred to as 'sticky sessions', must be specified to ensure that subsequent requests are routed to the same Access Gateway instance.
- Each application session is governed by the policies of the application. See the application specific documentation for more information.
Single logout in applications
Okta federated authentication supports a featured known as "Single Logout in applications", or SLO. With SLO, service provider initiated flows can be configured to sign out of both the application and Okta sessions at the same time. When SLO is enabled, Access Gateway acts as the service provider and Okta as the identity provider.
When an end user logs out of Access Gateway, they are then automatically logged out of Okta as well.
For more information and configuration details see, Configure Single Logout in app integrations.
See also Logout in Define application behaviors.