I spend quite a bit of time thinking about authorization-especially as it pertains to highly distributed computing environments. Authorization gets tricky fast in this environment. Federated scenarios are an excellent case in point. For example, Mary is a doctor in one hospital and she needs to access patient records in another hospital. Not only will she have to be authenticated, Mary will have to be authorized for those specific medical records. Services in the cloud (SaaS) will almost always require the service host to extend this type of limited trust to its bona fide service consumers. Consensus is forming about how to do this. Both authentication and authorization in highly distributed scenarios can be implemented using claims-based assertions in the form of tokens. Token standards (and services) are emerging and converging. Both SAML and WS-Authorization standards are now in the hands of OASIS and will probably be merged.
These token specifications are quite rich and absolutely necessary for building secure interoperable services, but they may not be sufficient. To see why, you have to understand the need for stable data. Keep in mind that at some level claims are themselves just data. Pat Helland has given a lot of thought to what happens when persistent data becomes a message and vice versa in the midst of SOA. Check out Data on the Outside vs. Data on the Inside if you haven't already.
Helland defines stable data as data that is unambiguous throughout space and time. You stabilize data by defining when and where it is valid. As it turn out, this concept is very important for authorization claims. Once you commit to sending messages and receiving messages that contain authorizing claims, you had better commit to defining and assessing when and where these claims are valid as well. Without such definition, authorization claims will infer far greater extension in space and or time than may have been originally intended. Let's suppose that Mary's medical credentials were revoked a moment after she sent her request messages to view various patient records at other hospitals? Those messages might be invalid by the time that they arrive-might they not? You might answer this question by saying that the request is valid as long as it was valid at the time it was initiated; but denying the problem won't may it go away. The problem with services (especially in the cloud) is that response latency (time) is generally undefined and frequently indefinable.
As I said earlier, faced with meeting business and regulatory policy demands in this environment can be tricky. Even if you knew when and where each of Mary's requests were sent, revoking them after the fact is still nearly impossible once the proverbial train has left the station. For example, there is no practical way to ensure that the revocation message can or will be processed before Mary's request; just as there is no practical way to know how long it will take to process a given request. This is why it's better to stabilize claims before they go out the door and check them as soon as they arrive.
Don't be misled into thinking that it's only the request that must be stabilized. Each claim (and perhaps each claim set) may have a different extent in space and time. In fact, that may be required in order to implement certain access control policies for individuals who have multiple roles. To use some spatial examples, Mary's medical credentials have been revoked in one state but they are still valid in another. My driver's license may still be valid even though the registration on my car has expired. When claims are constructed in one domain, it's often almost impossible to anticipate how they will be evaluated in another. In fact, making assumptions about implementation beyond what is expressed in the service contract violates the idea of loose coupling inherent in the SOA model. This is where it's going to get tricky.
If you look at the SAML specification for a moment, you will see that it makes provision for defining extent in time (as well as other conditions). As part of a claim, you can supply values for NotBefore and NotOnOrAfter . These attributes of the Conditions element are optional, of course, as they should be to provide the flexibility to handle simple cases simply and more complex cases at all. But the formal specification isn't normative; it can only take you so far. Beyond that, the burden is on us to devise policies that comply with business, industry and regulatory requirements and then implement services and consumers with access controls that effectively support those policies. WS-Policy can help us express and advertise these in the services we build, but it won't drive agreement about the substance and specific constraints of access control policies. I'm suggesting that, while bounding access control conditions in space and time are optional in the specifications, they will often be mandatory for authorization claims when sensitive information is being exchanged. We will need to stabilize claims just as we need to stabilize other forms of data in highly distributed scenarios.
Stabilizing claims can help to solve the problem of revocation. By freshness-dating claims before they go out the door-as long as we also then evaluate the boundaries of these claims when we authorize a service request. Freshness dating milk only helps if you actually check the label before you drink it. Admittedly, doing this will complicate our claims-based authorization mechanisms, but as Einstein pointed out, we should keep things as simple as possible, but not simpler. Things could get further complicated for services that are subject to strict regulatory compliance or that deal with highly sensitive information. In these cases, we will need to forge agreement between service-providers and service-consumers regarding what constitutes adequate and reasonable tolerances for claims conditions-especially with respect to time. Token specifications appear to be rich enough to support such policy agreement, but they will be no help for defining the terms.