After you’ve set up explicit proxy, here’s
how it works. Follow along to see the path traffic takes:
The mobile user browses the Internet or accesses
the SaaS application by entering the URL or IP address using a web
browser.
The browser on the mobile users’ endpoint checks for
the PAC file.
This PAC file specifies that the URL or SaaS request should
be forwarded to
Prisma Access
explicit proxy.
The HTTPS client (the browser on the mobile user’s endpoint)
forwards the URL request to the proxy URL.
The traffic is redirected to the explicit proxy, and
the proxy decrypts the traffic.
The proxy inspects the traffic and checks for the authentication
cookie set up by the
Prisma Access
explicit proxy.
The cookie contains information that identifies the mobile
user, and uses the cookie to authenticate the user.
If, upon inspection of the cookie,
Prisma Access
determines
that the user has not been authenticated, it redirects the user
for authentication.
After the IdP authenticates the user,
Prisma Access
stores
the authentication state of the user in the Authentication Cache
Service (ACS). The validity period of the authentication is based
on the
Cookie Lifetime
value you specify
during explicit proxy configuration.
The explicit proxy checks for the presence and validity
of our cookie. If the cookie is not present or is invalid, the user
is redirected to ACS. After ACS confirms the authentication of the
user, the user is redirected back to the explicit proxy with a token.
The proxy then validates that token and sets the cookie for that
domain for that user.
Prisma Access
applies security enforcement based on the
security policy rules that the administrator has configured.
If the URL is not blocked by security policy rules, Prisma
Access sends the URL request to the internet.
Explicit Proxy identifies users in the traffic
logs dependent on how the users authenticate with the proxy, as
shown in the following table.
Authentication Type
User Identification in Traffic Logs
Users that are logged in using SAML authentication
and decryption
The username.
Users that are logged in from another proxy
that uses X-Authenticated-User (XAU) headers
XAU header information.
Explicit Proxy
only allows traffic from specific IP addresses to use XAU for authentication.
You create an address object and specify
the IP addresses where you allow XAU for authentication; then, add
the address object in the
To
help identify traffic that is coming from authenticated users in
cases where browsers cannot send cookies or perform authentication
redirection, such as CORS requests, Explicit Proxy adds the
swg-authenticated-ip-user
to
the traffic logs.
Undecrypted traffic (if you have allowed
Explicit Proxy to allow undecrypted traffic from IP addresses where
users have previously authenticated)
The
swg-authenticated-ip-user
user.
You
can specify Explicit Proxy to allow undecrypted traffic from IP
addresses where users have authenticated; to do so, specify
Decrypt
traffic that matches existing decryption rules; for undecrypted traffic,
allow traffic only from known IPs registered by authenticated users