Multiple different methods exist for end-users to authenticate with websites. These methods have different appearances and features.
The HTTP/HTTPS protocol itself (RFC 2965) supports simple authentication via the
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.
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 (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
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
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:
|If used within the content of HTTP, it is not as secure as HTTPS. For stronger protection, use form-based authentication with HTTPS.|
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:
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).
For details, see How to apply PKI client authentication (personal certificates).
Open topic with navigation