Reject unsolicited authentication requests

For extra mitigation against cross-site request forgery (CSRF), we can configure WebSEAL to reject any unsolicited login requests. This configuration ensures that WebSEAL does not process login requests without first issuing a login form.

The general process for a client to authenticate to WebSEAL and access a protected resource:

  1. The client requests the protected resource.

  2. WebSEAL detects the client is not authenticated so WebSEAL returns a login form to the client.

  3. The client enters login information and submits the form to WebSEAL.

  4. WebSEAL processes the login information as follows:

    1. Authenticates the user.
    2. Creates a session.
    3. Sends a redirect to the requested resource.

  5. The client requests the protected resource.

  6. WebSEAL detects the user is authenticated and returns the resource to the client.

By default, it is possible for a client to skip directly to step 3 and initiate authentication with WebSEAL by sending through an unsolicited login request. However, we can configure WebSEAL to reject these unsolicited requests. We can set allow-unsolicited-logins in the [server] stanza to no to ensure the first two steps are required for a client to gain access to a resource. If we set this option to no, WebSEAL must always issue a login form to unauthenticated clients.

By default, allow-unsolicited-logins is set to yes, which means that WebSEAL does accept unsolicited authentication requests.

Set this entry to no if we are concerned that CSRF might cause a user to inadvertently authenticate with authentication data provided by an attacker.

Parent topic: Prevention of Cross-site Request Forgery (CSRF) attacks