Chained Invocations

Once the intermediate B has obtained the delegation certificate DCab from A, it has the authority to speak for A. To complete the service, B might have to invoke methods on other objects. When B selects C to be the next target, B represents an entity (B for A) and requires access to method invocation. At this point B exercises the type DelegateIdentity and during the process of becoming a DelegateIdentity, the delegation mode is considered to calculate the privileges of the delegate (here, B). In this case of B being a DelegateIdentity, B can authenticate for itself. Also, it provides the delegation certificate DCab to prove that A has indeed delegated the task to B. C authenticates that it is actually B it is talking to, through normal authentication procedures. It verifies the delegation certificate to be signed by A by verifying the digital signature of A that is engraved in the certificate DCab. These provide proof of the fact that ``B speaks for A'', abbreviated as or (B for A)[1]. The delegate's (B's) getPrivileges() method returns the privileges associated with B, which is either only the privileges gained through delegation (A's privileges only), or also includes the privileges of the delegate identity itself (both B's privileges and A's privileges). Thus the set of privileges returned by the delegate reflects the privilege of the identity (B for A) during that context.

Based on access control policies on the target C, the method invocation and any related resource accesses are controlled. These access control policies may be based on only the initiator (A) or might depend on the delegates as well.

If C requires delegation from its requester and B is a delegate for A possessing a delegate certificate DCab, i.e., (B for A) then:

1. B first checks if this delegation is forwardable, i.e., delegatable to further intermediaries.

2. If it is forwardable, B checks whether C is present in an exception list provided with the delegation certificate DCab (i.e, whether A disapproves any further delegation to C).

3. If delegation to C is not prohibited, B generates a delegation certificate DCbc and passes on DCab with it to C. The delegation certificate DCbc may contain: i) A's privileges only, ii) B's privileges only, or iii) a combination of both, depending on the delegation mode specified in the delegate identity B. Once B delegates to C, the delegation chain becomes A-to-B-to-C, i.e., (C for (B for A)).

In contrast, if B is not a delegate for A, that is if B had not specified delegation in its security requirements, then A would not have generated (and passed on) the delegation certificate DCab to B. In this case, when a request is issued to C, it is not possible for B to establish A as the original initiator due to the lack of a delegation certificate. So C must treat it as if the request originated from B and handle it accordingly, without having any idea about the involvement of A in the complete invocation chain. Extending this chain to one more principal, we get A-to-B-to-C-to-D. If B does not require delegation and C does, then when the request reaches D, D will treat the request to have initiated from B and delegated through C.

Thus, at any given time, control is based only on currently available information on the delegation chain and the specified modes and policies. SDM does not support any means of tracing back calls through intermediaries to obtain predecessor delegation certificates.