Claim types: a coarse taxonomy

In short. I make some considerations about what kind of info ends up in a claim, and the things we expect will happen when those info are processed. I then describe what I call infrastructure claims, for the lack of a better term, and their role in authorization; and I introduce the R-STS arcology pattern, which still needs refinement but looks very promising. This is a brain dump, so it may not be as straightforward and refined as you'd like; as usual, don't forget the disclaimer :-)

Different views of the world

The user centered identity people are an interesting crowd. Somebody comes from the world of classic federation, enterprises, directories and the like; some other comes from the world of websites and interaction in general. A funny thing I observed is that often the very same element gets interpreted in very different ways, and the interpretation given is so natural and implicit to each camp that it is difficult to understand from where the confusion comes from (or even to realize that there is confusion to begin with). If you are one of the AI winter survivors, that would be Minsky's frames. One of such things happen to be the concept of claim.

Yes, we all know that a claim is a declaration about a subject made by an entity; but what is the first example that comes to your mind? Let me play psychic: if you thought "group" or "role" you are a FED (federation, enterprise, directory) kind of guy; if you thought "birthdate", "name", "nationality" you are likely coming from the web/interactive angle (I'll call you WI). If you thought "PPID" you are probably sick, you go around with long curly hair and you have a severe case of underbite.

So if you are talking to a FED and a WI and you say the sentence "The RP will process the claim" without any further specification, the former may hear "The RP will process the subject's group" while the latter may hear "The RP will process the name of the subject". The actions expected from the RP may be pretty different in the two cases, hence this simple difference in interpretation can affect the understanding of everything you'll say after that.

There's more: the expectations are often also about what will happen when you use claims for sending a certain info. When you send a membership info, it is reasonable to expect it to be processed for authorization purposes: isn't it what happen when you access a share on your local network? In my world, the NTToken content is matched with the ACLs on the resource and from the combination arises the authorization action. Well, this may not be the case when I convey the same information in term of claims: I have no knowledge of the infrastructure used by the RP to shroud its resources, hence I cannot assume anything about the usage that the RP will do of the claims I send. For the claim sender a group membership may be something used in authorization, but the RP may use it in ways I don't expect (since what is a group for my directory software may be a simple string matched with another hardcoded string for the RP). Unless, of course, we agree on a specific semantic & we agree on what to expect. If this reminds you of how to event types conundrum in a service oriented architecture, you're right on the money.

Bottom line. We all have expectations about claims, and perhaps those expectations seems so obvious to us that we don't event think somebody may have a different take. Needless to say, any misunderstanding may lead to issues that would certainly be preferable to avoid. I really don't have a solution in my pockets, but I think it is worth to verbalize the expectations we have about claim processing so that we can discover what is reasonably shared by others and what is not. Note, some of this was already in the Tao of Claims but while there I tried to capture some intuitive ideas here I'll assume you are already familiar with this stuff.

Claims & 'Infrastructure' Claims

You know, I wrote a long piece (surprised?) in which I tried to explain the difference between attribute claims and authorization claims, and advocate this duopole as the most practical way of classifying claims; but the more I tried to explain it, the more it seemed wrong (or at lease suboptimal). So I cleaned it all and re-started from scratch.

Forget for a moment about the format of a claim when using a specific token type, and consider the claim as abstract entity: as shown in the Authorization Continuum, everything can be an authorization claim. Hell, for Oscar Wild even the first name can be an authorization claim! And what's more attribute-sque than a first name (Italian readers, no jokes ;-))? And of course the point is all about the perspective: the subject looks at the set of claims he's about to send and sees an identity; the RP sees answers to its questions, or data from which it can derive such answers (see the Tao of authentication part I). If those answers result in an authorization decision, you may say that the claims whose value led to the decisions were authorization claims; but if the RP does not disclose its authorization process, and it usually have no reason to do so (unless it's an ISV selling you a service, more on this on a later post), you have no way of knowing a priori if a claim will be used for authorization or not (or used at all). Even if it is a group membership, classic 'obvious' case. Conclusion: deciding the functional nature of a claim is extremely tricky, because it is more about that the RP will do with it rather than something intrinsic to the claim itself. Very counterintuitive, I am still trying to wrap my head about it.

There is a notable exception to the above, which IMHO is VERY useful to call out. There is a class of claims that refers directly to the resource endpoint itself, rather than just describing the subject. Consider the post I've made about using a managed card with biztalk.net services: we had a R-STS that had a claim transformation rule whose output was a claim of type  "Resource#Operation" and value "https://connect.biztalk.net/services/<username>/*#Send" .

I don't think there's any doubt here: from the syntax of the claim I can already tell that this represents a privilege, and I even understand what privilege it describes (being able to send messages to any service published by <username> via biztalk.net). In fact, I understand it so well that I can enforce the authorization decision it entails without even understanding what the actual service does, hence even before I reach the service itself.

NOW we are getting somewhere. In my first version of the post, I wanted to call this class of claims Authorization Claims. They have this very special property of being enforceable by the infrastructure while they are still traveling toward their destination, hence IMHO they deserve a name; and they definitely are about authorization. But for what we've seen above there many other claims that can be meaningfully called authorization ones, hence it would be very confusing. So I would opt for something like "Infrastructure Claims" . I really don't like the name, but you get the concept: we just need a sexier moniker, but this is the idea.

OK, as usual I can hear the classic questioning voice: "But Vittorio, those are by no means the only claims I can enforce before hitting the service itself! What about RBAC? What about spending limit?". Well, the ones I described seems the only claims that are obviously enforceable without knowing anything about the resource. If normal claims are language, those are metalanguage. Anyway, let's explore the issue. First of all, "infrastructure" is ill-defined. If for you anything that is not in the service code is infrastructure, a legitimate view, then you may be right. But you see, while you may be able to enforce "spending limit=$100" without touching the service code you cannot do it without understanding the message format and semantic of that specific service call. You need to recognize that the method you are invoking will result in some sort of spending, and you need to be able to parse the message for gathering all the values that look like spending, sum them and verify if they'll pass the $100 threshold. Doable? Sure! In fact, this is incredibly attractive for a lot of people and a very useful feature: there are many products supporting it, and if anything I expect this approach to grow. But in this case it is more the infrastructure that provides the intelligence for processing the claim in this specific way, there is a dependency on the specific payload with which the claim is traveling with, etc etc... hence I don't see this as an inherent property of the claim. Almost the same goes with RBAC, though I'll explain better what I mean in a later post.

So, in the end I came out with almost the coarsest taxonomy possible: there are Infrastructure claims, and there are all the others. I fully expect more fine grained taxonomies to emerge (the attributes alone can be subdivided further) and they will be useful for their own purposes, however my super rough subdivision here is enough for deriving some guidelines about further aspects like authorization decisions points & authorization enforcement points.

Enforcing authorization: R-STS Arcologies and buses

Another difference between "SpendingLimit=$100" and "Resource#Operation= https://connect.biztalk.net/services/\<username>/*#Send"

lies in the fact that while the former provides information useful to reach an authorization decision, the latter is the authorization decision itself!

Whoever processes an infrastructure claim of the form above does not have much room for interpretation: it's just a matter of enforcing the decision that was made by the entity that issued the claim in the first place. This has two splendid consequences.

Bus and/or resource hosting environment: good places for authorization enforcement 

Authorization decisions in infrastructure claims can be enforced at any point between the issuance of the carrying token and the resource invocation. The only things you need to understand for enforcing authorization decisions carried by infrastructure claims are 1) the claims syntax and 2) the resource addressing scheme. Wether you use endpoints or a bus (ESP or ISB), your hosting infrastructure needs to understand the resource address for dispatching the call: hence it is the ideal place for adding a module that takes care of enforcing those authorization decisions before the message hits its destination (for the bus there is the detail of the encryption for the ultimate receiver and intermediary visibility, but nevermind for now). The important takeaway you need to get as a resource developer is that for what concerns infrastructure claims you don't have to worry about handling authorization. Like, at all. This is even better than not worrying about the format in which you get claims, the main result of moving to tokens & claim based models (and you still need to do it for normal claims modulo products like the ones mentioned above which may take authZ decisions & enforcements at the cost of adding more intelligence to the process): this is about not writing anything at all. As a service developer I should not have the burden to write any code that retrieves the infrastructure claim value and make decisions; if the syntax is clear, the system (whatever it is) should act upon the authorization right carried by the claim and grant/deny access to the resource accordingly. Think of a powerpoint file in a shared folder: when somebody tries to access the file it is not the powerpoint.exe code that decides if he can open the presentation or not, but the network infrastructure itself. With infrastructure claims, you gain back this capability. Neat!

R-STS & arcologies: the ideal place to make authorization decisions

Our good friend R-STS, always busy transforming claims. What if we get the authorization decision logic that pertains to a set of resources, and we wrap it in an R-STS? We'd obtain a magic box that swallows (generic) claims and spits authorization decisions, ready to be enforced by the infrastructure itself. Trivial? But this is HUGE! Think of how many problems you can handle with minimum waste and maximum joy. Do you have a set of resources that use custom roles you don't want to surface in the global schema? Set an R-STS with the rules for transforming global schema, generic claims into the authorization decisions that your custom logic requires; then get all those resources to trust your R-STS. You just got an R-STS Arcology, which nicely hides the details of the custom authorization logic of all those resources from the global schema. Do you have a set of resources that use a custom attribute store? Again, wrap the profile retrieval & authZ decisions in an R-STS, then get all the resources to trust your R-STS, and you got another arcology that consumes "global" claims and manages custom authorization logic while keeping it isolated from the rest.

The value of R-STS arcologies is high per se, but the introduction of infrastructure claims makes it even more palatable as pattern. More on this in the future.

OK, I have to admit there's a catch. I hope I made the case for infrastructure claims being the easiest way of expressing authorization decisions, and that works really well with R-STSes. BUT. As I said, there is a lot of value in having a piece of software that blocks a call that would result in a $150 purchase because it can process the message payoff and the "SpendingLimit=$100" claim. It simply happens to be much more complex (hence brittle) than the simple infrastructure claim approach. Ehr, hmm, it also happens to be intractable with the R-STS trick. The reason is simple: when a subject invokes the R-STS, he sends a RST message. The RST contains info about the subject, such as a token obtained from a IP, but it does not contain any indication about the content of the messages that the subject will send to the RP together with the token it will obtain from the R-STS. That means that the R-STS cannot codify any authorization decisions, the best it can do is declaring "SpendingLimit=$100" and hope that the RP (or a product in front of it) will be smart enough to take the constraint in proper consideration.

The value of the infrastructure claim approach + R-STS stands: it's just not the solution to every authorization problem, which of course was never the intention.

All right, this came out longer than expected; and given the obscurity of the topic (plus the absence of drawings) I don't expect a lot of you will read it all. But if you do, and if you have questions, you know where to knock :-)