Chat now with support
Chat with Support

Single Sign-On for Java 3.3.2 - Administration Guide

About this guide Introducing Single Sign-on for Java Preparing for Single Sign-on for Java Deploying Single Sign-on for Java
Getting started with Single Sign-on for Java Single Sign-on for Java and your web applications Setting up logging Controlling access to resources
Security Issues Maintenance and Troubleshooting Appendix: Configuration Parameters Appendix: Using the JKTools

Why delegate?

When a user requests information in a web page from a browser, more than one application or server may be involved. It may not be possible for the first server receiving the request to provide all details for the page requested. That first server, for example, may have to seek some information from a database on a second server.

Any dependency pattern of this kind then has implications for the process of Kerberos authentication. A Kerberos requirement is that at each stage of the requesting process, the parties involved have to be able to authenticate with each other. In practical terms, without use of a “shortcut” such as delegation, this could be very difficult to achieve.

For example, the original client may have no knowledge at all of any secondary stages in the request process: it just knows that it is supposed to get information from the first server it approaches, and relies on a single request (for example, for a web page).

Theoretically, one approach might be for the client to have to directly and separately authenticate with every information source: but that approach is clearly impractical and may be impossible.

Delegation “trust” in authentication

In order to deal with the problems involved when multiple points of authentication of this kind may be needed, Active Directory allows you to establish a form of trust between clients and services. What this means is that a client may be prepared to permit one or more services to act on its behalf to establish authentication. There are configuration options on each account which handle permissions of this kind, and which can allow for a form of “delegated identity”.

A client can specify that other services can act on its behalf, as its “delegate” in establishing authentication. It may do this in a general sense with a setting saying the client’s identity may be delegated -- that is, generally, other services may “impersonate” it for authentication purposes. This is known as “unconstrained” delegation.

In some circumstances, however, the client can set more refined limits on delegation, and can specify a list of those services that it allows to act on its behalf in the course of authentication processes, thereby establishing that those not specified are not given such permission.

Delegation options

The limits that can be configured for delegation now involve two or three basic configuration options, varying with the domain functional level:

For Windows Server 2003 and higher domain functional levels:

  • Delegation disallowed: A Kerberos service is not to be trusted for delegation at all
  • Delegation allowed for all services: Use the Unconstrained option for Kerberos using a TGT
  • Delegation only allowed for a limited set of services: Delegation to specified services only (the Constrained option), with sub-options for either using Kerberos only, or allowing any authentication protocol (the Protocol transition option).

For the last of these, further configuration permits a selection of Service Principal Names (SPNs) for the services for which delegation is allowed.

Unconstrained delegation

In this form of delegation, known as Unconstrained delegation, a client which has established its identity can transmit that identity to other entities, asking them to act on its behalf in the authentication process.

As far as the Active Directory domain controller is concerned, each server which has received such a delegation from a client is assumed to be the client, because it can present the client’s Ticket Granting Ticket, or TGT. At the authentication level, the server is indistinguishable from the client itself.

Unconstrained delegation of this kind can imply multiple security risks and the possibility of unlimited “spoofing” of the client if a server which acts as a delegate and holds a TGT falls vulnerable to a security attack.

Kerberos Delegation extensions introduced with Windows Server 2003 and higher now make it feasible to avoid these risks, by choosing the appropriate domain functional level and Single Sign-on for Java supports the new “Constrained” form of delegation as an additional option, known as the S4U2Proxy extension.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating