Identity payloads have a lifecycle. It is generated, consumed, used as a basis for negotiation, and may be further transformed and communicated. Many conversations center around the "front half" of the identity transactions, e.g. logging into a server. But in a distributed systems this identity may be mapped, propagated, and used in a variety of ways. I blogged earlier about the Open Group's Security Design Patterns which are excellent. Keith Brown has an excellent article on S4U which provides constrained delegation services for 2K3. Keith describes some of the problems of delegation:
Delegation is another problem that has plagued developers. Even when a client is able to use Kerberos to authenticate with a service, the client's security context given to the service does not normally contain the client's network credentials. Imagine what could happen without this protection: a service, which may or may not be trusted in its own domain, could use a client's credentials from another domain to access resources it would normally not be able to access on its own. No client would ever want to use such a service, unless that service was highly trusted.
Delegation is also an issue for configuration, administration, and auditing. Mapping must occur so that identities have proper access, but these mappings are at very granular service and protocol level. This granluar control is desirable from a security standpoint, but how well does this scale in a large environments?
Comments