Back in September I wrote an post on Double Authentication in which I noted that I would elaborate on the HTTP Form Authentication method menu option at a later date. This post gives an overview of both its mechanism as well as its use by Cisco ASA security appliances.
One reason why a network administrator might want to implement the HTTP Form authentication method is because it’s a very effective Single Sign-On (SSO) solution, especially in SSL VPN implementations. The schematic below illustrates such a case:
The procedure outlined below is a “condensed version” of what actually happens in HTTP Form Authentication (which is called HTML Forms Authentication by most other vendors).
- The user logs into the clientless SSL VPN server (WebVPN), which in this case is the ASA.
- The ASA authenticates the user to an authentication server using the HTTP POST protocol.
- If approved, a temporary authentication cookie is returned and stored for the authenticating client.
- The tunnel is now up.
- The user can now access other “authentication required” servers without having to re-enter the credentials.
The schematic below illustrates the client-server interactions in more detail. The rectangle on the left-hand side labeled “Client” corresponds to the “WebVPN server” in the diagram above. As this diagram indicates, the POST method does not happen until the ASA has first received the FormsLogon URL and has subsequently requested it.
- HTTP Form Authentication does not mandate encrypted credentials and
- a 120-character limit exists for the password.
The SSPI Package (Security Support Provider Interface) mentioned in the diagram above refers to a Microsoft API offered for developers. Not surprisingly, because of the lack of enforced credentials, Cisco has made the HTTP Form authentication AAA method only available for SSL VPNs.