Cisco Cisco Web Security Appliance S170 사용자 가이드
366
I R O N P O R T A S Y N C O S 6 . 3 F O R W E B U S E R G U I D E
A L L O W I N G U S E R S T O R E - A U T H E N T I C A T E
AsyncOS for Web can block users from accessing different categories of websites depending
on who is trying to access a website. In these cases, users successfully authenticate, but they
are not authorized to access certain websites due to configured URL filtering in the applicable
Access Policy. You can allow these authenticated users another opportunity to access the web
if they fail authorization.
on who is trying to access a website. In these cases, users successfully authenticate, but they
are not authorized to access certain websites due to configured URL filtering in the applicable
Access Policy. You can allow these authenticated users another opportunity to access the web
if they fail authorization.
Note — Only authenticated users are allowed to re-authenticate, not unauthenticated users.
You might want to do this for shared workstations that have multiple users, but the default
account has limited access. If the default account on the workstation is blocked from a
website due to restrictive URL filtering, the user can enter different authentication credentials
that allow broader, more privileged access.
account has limited access. If the default account on the workstation is blocked from a
website due to restrictive URL filtering, the user can enter different authentication credentials
that allow broader, more privileged access.
To do this, enable the “Enable Re-Authentication Prompt If End User Blocked by URL
Category” global authentication setting. The user sees a block page that includes a link that
allows them to enter new authentication credentials. The Web Proxy evaluates those
credentials against the authentication realms defined in the applicable Identity group, and if
the new credentials allow greater access, the requested page appears in the browser. For more
information, see “Configuring Global Authentication Settings” on page 353.
Category” global authentication setting. The user sees a block page that includes a link that
allows them to enter new authentication credentials. The Web Proxy evaluates those
credentials against the authentication realms defined in the applicable Identity group, and if
the new credentials allow greater access, the requested page appears in the browser. For more
information, see “Configuring Global Authentication Settings” on page 353.
Note — The Web Proxy evaluates the new credentials against the authentication realms
defined in the applicable Identity group only. It does not compare them against all other
Identity groups.
defined in the applicable Identity group only. It does not compare them against all other
Identity groups.
When a more privileged user authenticates and gets access, the Web Proxy caches the
privileged user identity for different amounts of time depending on the authentication
surrogates configured:
privileged user identity for different amounts of time depending on the authentication
surrogates configured:
• Session cookie. The privileged user identity is used until the browser is closed or the
session times out.
• Persistent cookie. The privileged user identity is used until the surrogate times out.
• IP address. The privileged user identity is used until the surrogate times out.
• No surrogate. The Web Proxy requests authentication for every new connection, but most
browsers will cache the privileged user credentials and authenticate without prompting
the user until the browser is closed. However, because the Web Proxy requests
authentication for every new connection, there is an increased impact on the
authentication server when using NTLMSSP.
the user until the browser is closed. However, because the Web Proxy requests
authentication for every new connection, there is an increased impact on the
authentication server when using NTLMSSP.
Note — To use the re-authentication feature with user defined end-user notification pages,
the CGI script that parses the redirect URL must parse and use the Reauth_URL parameter. For
more information, see “Working with User Defined End-User Notification Pages” on
page 249.
the CGI script that parses the redirect URL must parse and use the Reauth_URL parameter. For
more information, see “Working with User Defined End-User Notification Pages” on
page 249.