Authentication flow with Access

The following describe the authentication flow with Access.

•Managed non-AppConnect app using Tunnel

•AppConnect apps with Access enabled (Core only)

This section is not applicable if you are deploying Access + Standalone Sentry.

Managed non-AppConnect app using Tunnel

The following describes the authentication flow when a managed non-AppConnect app accesses a enterprise cloud service.

Authentication flow for a managed non-appconnect app

A managed app triggers Tunnel.

If the device is in compliance, Tunnel establishes a secure connection with Access.

The managed app connects to the service provider (SP) through Tunnel.

Split Tunneling is enabled: If split tunneling is enabled, and the split tunneling does not require tunneled connection to the service provider, the app connects directly with the service provider.

If the managed app does not have a valid session token, the SP issues a SAML 2.0 AuthN Request to the app and redirects the app to Access.

Access issues a secondary SAML AuthN Request based on the AuthN Request in step 4. The AuthN Request is issued via SAML and points the user to the identity provider (IdP).

If the user does not have a current valid session token, the identity provider (IdP) requests the user’s credentials. If the credentials match, the IdP issues a SAML Assertion to the user. The SAML Assertion identifies the user and redirects the user to Access.

The user presents the SAML Assertion to Access. If conditional rules for access control allow, Access issues a secondary SAML Assertion to the user. The secondary SAML Assertion identifies the user and redirects the user to the cloud service (SP).

The user presents the secondary SAML Assertion to the cloud service (SP). The SP verifies the secondary SAML Assertion and creates a session token to the app. The session token gives the user access to the SP.

AppConnect apps with Access enabled (Core only)

AppConnect apps with Access enabled automatically use HTTP tunnel to Access.