Good Claims, Bad Claims 1: an Example

Ahh, claims. Aren’t they a thing of beauty? When you first discover them, you’d be tempted to use them for everything up to and including brewing coffee.

Now that we finally have powerful tools at our disposal for actually developing claims-based systems, as opposed of just talking about it, it is time to go past the trivial examples and make some more realistic considerations. Oversimplification is useful for breaking the ice, but we don’t want to fall victim of the hype and do silly things do we? Just remember that there was a time in which there was the belief that before writing any web service (including the one doing a + b) you should have provided the corresponding XSD… yeah, fits beautifully with the vision but not especially agile in practice 🙂

We kind of started this process in the “what goes into claims” post, which BTW is being reworked for appearing in the claims guide, however here I’d like to go a step further and reason about what makes a claim a good or a bad choice for a given scenario. I’ll start by discussing one of the most classic example of claims in the authorization space, the Action claim, and use it as an example of kind of the things you want to consider in practice when evaluating which claims are right for your scenario.

The Action claim: really???

Let’s say you have a LoB application featuring various web services, all facade-ing business entities. Most of those services offer CRUD operations for some business entity, but there are others exposing operations whose semantic is less clear. How are you going to authorize access to those services?

One recurrent solution in literature is requiring the caller to present a token containing one or more Action claims. If the value of one of the Action claims corresponds to the action URI of the method being invoked, we’ll authorize the call; otherwise we’ll block it. Clear as spring water, right? An elegant catch-all solution to services authorization. Unfortunately, not always “simple” corresponds to true, effective or realistic. Back in ancient Greece Aristotle believed that stones fell to the ground and smoke rose up because they were trying to reconnect to their elements (Earth and Air) in their natural places. That’s a good model while your technology level  sticks to crab pots and horse-powered carriages, but if you don’t move your understanding past it forget about PET scans and buckyballs.

Did I go off a tangent again? Let’s get back to business. Who are we expecting to issue the token containing the Action claim? A good candidate would appear to be the federation provider in the same organization as the app we are securing: after all they are in the same org and they know about each other, right? It’s not like we are asking the IP in another organization to pollute its schema with info about the app.

Ehrr, when you try to put the above in practice you discover that it’s not as simple as it would have seemed at first. The administrator of your local FP (think of it as the local ADFSv2 instance) will want to know about your app, since it is a relying party that should be recorded & recognized if we want to issue claims for it. At a certain point of the app development cycle the administrator will be notified of the URL of the app (better if done via metadata docs). But think about how much more you’d have to ask to the administrator if you’d want the FP to issue Action claims for you. He’d have to know about ALL the web services your application have, ALL endpoints, and ALL the methods you want to secure; and he’d have to write claim issuance rules accordingly. If you think that an administrator will gladly submit to that, you never worked with a DB admin (which is the best approximation I can find for a FP admin). I worked with customers who always added extra columns to their DBs before going to the DB admins, so that they had something to sacrifice in the bargain bagarre that inevitably ensued.

Let’s admit that for some reason the admin agrees to handle for you al those rules. What happens when next week you need to make adjustments to your app, like adding or deleting a web service? Are you going to bug the man again? Now, multiply this for all the LoB apps in your company’s portfolio. Even if they guy has the attitude of a martyr, he would simply be unable to comply with the extra work.

Note, here I didn’t even touch on non-admin issues of sticking with Action, such as action strings collision (it may happen that CRUD ops are represented by the same action URI, and they are simply applied to different services) and claims overcrowding vs token issuance overhead (do you overstuff a token with all possible actions for that user, or do you keep querying the FP every time you call a different method?).

So much for improvement. Note that here the fault is not in claims, of course; it’s in the choice of claims for the scenario. If you’d ask the FP to issue a role claim, and at the resource map that role to the actual permissions at the method level, the autonomy of everybody in the chain would be respected and you would not have to duplicate within the FP what you already know locally. Of course this is not a foolproof rule in itself, since uncontrolled app-specific role proliferation is precisely one of the main causes of AD overspill, but you get my point. 

OTOH it is not my intention to demonize the Action claim: there are situations in which it may make sense, it’s all about understanding the scenario rather that blindly following catch-all rules. If instead of dealing with an entire portfolio of LoB apps for an enterprise you are simply exposing one SaaS app, the number of possible Actions will likely be manageable and their semantic more uniform (especially if you believe in the resource model). In that case using Action may prove to be handy; that would also hold in cases in which between the FP and the app itself there are intermediate levels, such as a departmental R-STS or in any case an issuer for which the knowledge of resource-level info would not be a burden but a natural part of its operations.

Good Claims, Bad Claims

Your application has questions about its users, and the answers to those questions are what decides if one call succeeds or fails. Claims are a great way of getting the answers to those questions right when you need them, from the most authoritative source: why storing the roles for your users when you can simply require that info to be there, fresh & authoritative, in form of claims in a token right at the moment of the call?

If you ask the right question to the right authority, things flow literally by themselves and everything works out beautifully: all you need is already in place, claims based identity simply helps you to unlock it and make it available where and when it’s needed. You just need to think a bit to figure out to whom you have to ask what.

When you don’t control the scenario end to end, you are kind of forced to respect everybody’s autonomy: the real danger is when you do control the scenario end to end, because you may dig yourself in a deep hole if you are not careful. If you run a successful pilot using the Action claim & the FP for authorizing access to one 10-webservices, 3 –actions-each LoB app, you may think you’ve found your claims-based Graal. However, if later it turns out that you have almost a hundred of LoB apps (with tens of services each, with tens of methods each) and the only STS you can rely on is the main FP, you may find yourself in a tough spot to extend the same strategy company-wide if that would require handling rules in the tens of thousands involving fairly volatile resources.

In the last several months my typical posts where of the type “announcing sample X” or similar: now that a very successful PDC and WIF launch is behind us, I finally have some time to get back to some good ol’ architecture. In the next few posts I’ll try to reason about claims effectiveness. As I mentioned, there are no hard & fast rules here: my hope for this and the next posts is to make exactly that point, and inspire you to think about your systems and the best way of taking full advantage of the claims-based identity approach. Don’t get caught in information cascades and never suspend your judgment, including (especially) about what you read here! 😉