Single Sign-On for Java 3.3.2 - Administration Guide

Using the principle of least privilege

The Principle of Least Privilege is a security maxim stating that users should only be given the least amount of privilege required, and no more.

We recommend that you apply this principle when creating authorization policies using Single Sign-on for Java.

Allocate a role to each task and map this to one or more groups managed in Active Directory.

It is useful to use groups which are specific to your application to prevent the risk of a user inadvertently being added to a group so they may access an entirely different application.

Denial of service

Single Sign-on for Java has a number of mechanisms to prevent Denial of Service (DoS) attacks. The most important is that no state information is stored on the server until the client has authenticated.

In addition, Single Sign-on for Java limits the amount of communication that is required with back-end servers, and in most cases authentication and authorization can be performed locally without having to contact Active Directory.

However, there are some issues that need to be considered to increase resistance to DoS attacks. These are discussed below.

Basic fallback

Unlike Windows Integrated Authentication, the basic fallback mechanism requires communication with Active Directory to be performed by the server. Because of this, it can be exploited to mount a DoS attack by saturating the number of outgoing connections. A number of application servers can also be used to “amplify” an attack on Active Directory using this feature.

For this reason, basic fallback should be disabled in situations where there is a high risk of DoS attacks, or other measures should be undertaken (such as using a firewall that drops a large number of connections, or increasing capacity).

Session state

Once authenticated, each Single Sign-on for Java session will store security information associated with the connection, including the user's ticket and delegated credential.

It may be possible for an attacker who obtains a legitimate user's account to saturate the memory of an application server by making a large number of new requests to an application. However, this is a fairly low risk.

Such an event would be indicated by a large number of logins from the same account in the audit logs, and could be effectively stopped by disabling the offending account.