74-43
Cisco ASA 5500 Series Configuration Guide using the CLI
Chapter74 Configuring Clientless SSL VPN
Understanding How KCD Works
application trust boundaries by limiting where application services can act on a user’s behalf. This
flexibility improves application security designs by reducing the chance of compromise by an untrusted
service.
For more information on constrained delegation, see RFC 1510 via the IETF website
(http://www.ietf.org).
Authentication Flow with KCD
Figure 74-8 depicts the packet and process flow a user will experience directly and indirectly when
accessing resources trusted for delegation via the clientless portal. This process assumes that the
following tasks have been completed:
Configured KCD on ASA
Joined the Windows Active Directory and ensured services are trusted for delegation
Delegated ASA as a member of the Windows Active Directory domain
Figure74-8 KCD Process
Note A clientless user session is authenticated by the ASA using the authentication mechanism
configured for the user. (In the case of Smartcard credentials, ASA performs LDAP
authorization with the userPrincipalName from the digital certificate against the Windows
Active Directory).
1. After successful authentication, the user logs in to the ASA clientless portal page. The user accesses
a Web service by entering a URL in the portal page or by clicking on the bookmark. If the Web
service requires authentication, the server challenges ASA for credentials and sends a list of
authentication methods supported by the server.