Summary

Goals

Implement the MS-SFU S4U2self protocol

Implement the MS-SFU S4U2proxy protocol

Make sure the implementation is interoperable with current MS and MIT
implementations.

Motivation

In a typical network service, the front-end (say, a web server) often
needs to access the back-end (say, a database server) on behalf of the
client. Kerberos 5 supports delegation but demands all layers using
Kerberos. In some cases, the authentication between the client and the
front-end is not performed in Kerberos (for example, client logs in to a
web server using digest authentication), and there are no Kerberos
credentials to be delegated. Microsoft defines the Service for User
(S4U) extension so that the front-end can still access the back-end on
behalf of the client without the client's credentials.

Also, with the standard Kerberos 5 delegation (which Microsoft calls
open delegation), once you grant a service account an ability to
delegate it can delegate to any service at all. This means that one
needs to be very careful with this privilege. On the other hand, the
MS-SFU delegation (Microsoft calls it constrained delegation) is much
more secure. Here the administrator can precisely control which services
a particular service can delegate to.

Microsoft started using S4U since Windows Server 2003, and the feature
is also supported by MIT Kerberos 5 implementation recently (in krb5-1.8).

Description

S4U includes two extensions to the original Kerberos Protocol defined in
RFC 4120: Service-for-User-to-Self (S4U2self) which allows a front-end
service to obtain a Kerberos service ticket to itself on behalf of a
user, and Service-for-User-to-Proxy (S4U2proxy), which enables it to
obtain a service ticket on behalf of the user to a second, back-end service.

Collectively, these two extensions enable the front-end service to
obtain a Kerberos service ticket on behalf of a user. The resulting
service ticket can be used for:

The requesting service's own information.

Access control local to the service's machine, impersonating the user.

Requests to some other service, impersonating the user.

We'll provide some new public JGSS-API to support this feature. New
config files and/or system properties are also likely to be added.

Alternatives

We can also enhance the native JGSS provider to make use of existing S4U
feature from a native Kerberos implementation.