Authentication styles
Multiple different methods exist for end-users to authenticate with websites. These methods have different appearances and features.
Via the “Authorization:” header in the HTTP/HTTPS protocol
The HTTP/HTTPS protocol itself (RFC 2965; http://tools.ietf.org/html/rfc2965) supports simple authentication via the Authorization: and WWW-Authenticate: fields in HTTP headers.
When a website requires authentication in order to authorize access to a URL, it replies with an HTTP 401 Authorization Required response. This elicits a prompt from the web browser.
An HTTP authentication prompt in the Google Chrome browser
If the user supplies credentials, his or her web browser includes them in a second request for the same page. If the credentials are valid, the web server returns the requested URL; otherwise, it repeats its 401 Authorization Required response.
This type of authorization is handled at the web server layer of the host’s software stack, independently of the static HTML, dynamic pages and runtime interpreters (PHP, ColdFusion, Python, etc.), or database (MySQL, PostgreSQL, etc.) of the web applications it may host, and as a result can span multiple web applications. It also may be offloaded to a FortiWeb. For details, see Offloading HTTP authentication & authorization.
Because the HTTP protocol itself is essentially stateless—no request is required to have knowledge of or be related to any other request—as a practical matter, many browsers cache this data so that users will not have to re-enter the same user name and password over and over again, for every page that they visit on the website. (For this reason, one-time passwords are generally impractical. They effectively contradict the reusability of the cache.) However, in payment for this initial convenience, logouts are basically impossible unless the user clears his or her browser’s cache and/or closes the window (which can also clear the cache).
Accounting, if any, of this type of authentication is handled by the web server (or, if you have offloaded authentication to FortiWeb, it may be accounted for in logs, depending on your configuration of Alert Type).
|
While some supported WWW-Authenticate: methods encrypt passwords, due to a lack of other cryptographic features, if used with HTTP, it is not as secure as HTTPS. For stronger protection, use HTTP-based authentication with HTTPS. |
Via forms embedded in the HTML
Web applications can authenticate users by including <input> tags for each login credential in an <form> buttons, text fields, check boxes, and other inputs on a web application’s login page such as /login.asp.
An authentication form on the Fortinet Technical Support login web page
This method does not rely on the mechanism defined in the HTTP protocol. Instead, when the user submits the form, the web application uses form inputs to construct server-side sessions, client-side session cookies, or parameters in the URL such as JSPSESSIONID in order to create statefulness.
This type of authorization occurs at the web application layer of the server’s software stack. As a result, when visiting different web applications on the same host, users may have to authenticate multiple times, unless the web applications share a single sign-on (SSO) framework.
Authorization for each subsequent requested URL then occurs based upon whether the user is in the logged-in state, or the logged-out state, and possibly other implemented conditions such as user groups and permissions. Dynamic page content may change based upon knowledge of the user’s preferences. In addition to a logout button, this method also often adds session timeouts. However, depending on the implementation, it often may only work properly if the client supports—and accepts—cookies.
Accounting, if any, of this type of authentication is handled by the web application or servlet.
This type of authentication cannot be offloaded to FortiWeb, but can be protected using its features. For example, you can use FortiWeb to enforce complex passwords by applying an input rule. Depending on your operation mode (see Supported features in each operation mode), you might want to see:
- Protecting against cookie poisoning and other cookie-based attacks
- Blocking known attacks & data leaks
- Validating parameters (“input rules”)
- Preventing tampering with hidden inputs
- Preventing brute force logins
- Specifying URLs allowed to initiate sessions
|
|
If used within the content of HTTP, it is not as secure as HTTPS. For stronger protection, use form-based authentication with HTTPS. |
Via a personal certificate
Alternatively or additionally to logging in by providing a password, clients can present an X.509 v3 personal certificate. This can be a good choice for large organizations where:
- entering a password is onerous due to password length/complexity policies or the nature of the device (e.g. small touch screens on iPhone or Android smart phones, or highly secure environments)
- you control the endpoint devices, so it is possible to install personal certificates
If your clients will connect to your websites using HTTPS, you can configure FortiWeb to require clients to present a personal certificate during the handshake in order to confirm their identities. This is sometimes called public key infrastructure (PKI) authentication (RFC 5280).
A personal certificate prompt in Microsoft Internet Explorer
For details, see How to apply PKI client authentication (personal certificates).