Revocation

Sometimes users and services need to revoke privilege assignments. Users change their minds; people leave groups, services change functionality, and so on. Even though it adds complexity, any practical delegation protocol must support revocation.

In SDM, revocability is an optional attribute of delegation. If performance is an issue, or revocation is somehow known to never ne necessary, the delegation can be made non-revocable. This facility to explicitly enable or disable revocation is again carried out using the AccessController object. The changed revocation status remains valid, until it gets changed again. The AccessController method setRevocableDelegation(true) enables delegation to be revocable until it is set otherwise.

If delegation is revocable, then the end-point (but not necessarily any of the intermediate delegates) of a chain must be able to find out. In SDM, the DelegationID and delegation server (URL) associated with certificates define the uniqueness of a delegation certificate. If the endpoint has not seen the delegation certificate earlier, it must contact the DelegationServer of the initiator and verify its validity. And if it is not a one-shot delegation (a delegation that is valid for one access request only), the end point registers itself as a DelegationRevocationListener with the initiator.

When an end-point receives a service request from a principal, its AccessController checks if the service has been delegated through the invoking principal, and if so whether the delegation is revocable. If the delegation is not revocable, it goes ahead to provide/deny access according to the delegates privileges.

But if the delegation is revocable:

• The AccessController first checks if the delegation certificate is in a local <delegationCertificate, status> table.

• If the certificate is not present in the table, then this must be the first time this delegation certificate has been obtained. It contacts the DelegationServer of the initiator querying the status of the delegation.

• If the delegation is not one-shot, the user setting is analyzed to see if the change-of-status notification is periodic or aperiodic.

• In the default aperiodic case, the end-point registers itself as a DelegationStatusListener with the delegation server for future updates only upon status changes.

• In the periodic case, the end-point registers itself as a DelegationStatusListener with the delegation server for future periodic updates at a given update interval.

• If the delegation is revoked (i.e., the delegation is no longer valid), the access is denied. Otherwise, the AccessController then provides or denies access according to resulting status and deletage privileges.

• Revocation Notifications