Claims propagation: Kirchhoff or maxflow?

In the last week or so Paul Madsen made at least a couple of posts with strong visual components: one that resumed my old 2005 post on a notation for message crypto, the other on Feynman diagrams. Nice! Paul, when I am in that mood I find especially pleasant to thumb through Tufte: I highly recommend it. Like Paul, in a former life I dealt with completely different stuff: I spent few years on computational geometry first, and on scientific visualization later. I am absolutely in love with what I do now (proof?), but I still have some residual forma mentis from those times. There's nothing on TV until Friday (can't wait for the next Battlestar Galactica!), and I am not focused enough to make real work; hence for this post I will indulge my inner geek a bit.

On the topic of notation and diagrams, I often wonder if it would be of value to find an expressive representation of the claim propagation pattern. Would a circuit-like notation work? Or a network flow would work better? The main idea can be simple: all the claims inserted in the circuit must be there for a reason, since at a certain point the policy of an RP requested them; so for every claim produced there must be a piece of biz logic that eventually uses ("consumes") it. Hence IPs are sources and RPs are sinks; an initial coarse simplification may indirectly factor out subjects, by assuming that an RP-IP edge is in the schema if the subject chose to disclose.

Let's take the example of one RP that implements a content portal; let's assume that the RP requires a personal card for signing in, and a managed card from IP1 for making higher value operations such as showing special content (like movie trailers rated only for people beyond a certain age). Our little schema would look like

Whoah, rocket science uh? Not exceptionally useful. The reason is that it is difficult to make an interesting network if you have just sources, sinks and edges: we need nodes, primitives that have both inputs and outputs. What are the nodes of the IdM? Claim transformers, of course! Think of an R-STS, the favorite tool for implementing CTs: it chews the token used for security the RST and spits out a new token with transformed claims. Let's revisit our little sample by adding a meaningful claim transformer:

Our RP accepts claims of type AllowedRating (from [ G | PG | PG-13 | R | NC-17 ]), and we have a claim transformer (CT1) that is able to transform Birthdate claims into AllowedRating claims. So if I'd be the subject the RP would receive a token with 5 instances of AllowedRating which would cover all possible values; if the subject would be Giacomo, my youngest nephew (I have 12 of them :-)), he'd get just G and PG. This is an easy case, we can certainly imagine scenarios with multiple CTs in cascade.

Ahh, now we're onto something. The flow/circuit notation may have suggested that here the property of transport networks are preserved, but we just observed it's not true. Kirchhoff junction law does not work here, because the amount of information exiting one node can be smaller than the one that entered. A birthdate is much more information than a rating: I can always derive a rating from a birthdate, but I cannot guess the age of somebody just by knowing his movie rating privileges. This is bad news for our little notation experiment, but good news for the subject: user consent and minimal disclosure are respected here, the subject gave consent for using his birthdate and the RP is using no more than that. Seems a good result: it matches the intuition, but it's always nice to get more reassurance.

Perhaps representing the CT as a single node is not such a good idea, for waht we said above it is rather an RP-IP "molecule". Let's try that, and let's add a bit more complexity to it:

Everything like before, we just exploded CT1 in RPCT and IPCT. Ah, and we added a little detail, now the claim transformed adds a new claim to the output token, Loyalty. The claim Loyalty is some measure of how often the subject uses the service: the higher it is, the higher the bandwidth that the RP will grant him. As usual, I can hear the objections rising: "But Vittorio, the subject never consented to disclose Loyalty information! This is in violation of the Laws!". Well, well. Let's think about it for a moment. What if the CT is actually a resource managed by the same entity that manages the RP? After all it is very common to have a resource STS that lives in the same domain of the RP: at that point using an R-STS is barely an implementation detail, the RP may obtain the very same information from a profile store. If the info comes from a profile there's not much that the subject can do, the RP can save whatever it pleases it: Amazon remembers the last n books I bought and I can try to exercise my consent until I am blue in the face, but I can't prevent them from using it in the application. The matter is different if the claim transformer is a distinct entity from the RP. The additional claims that may be injected in the process may not be visible to the subject, since the claim set explicitly consented is just the one that starts the chain (IP1 in our case). On the other hand, the fact that CTs are intermediate endpoints rather that the starting point of a chain implies that there is no explicit direct relationship between the subject and the CTs (otherwise the chain would have not progressed beyond the CT searching for a more distant fixed point, IP1 in this case), hence the possibility of the subject to handle information release would be nil anyway. It's like having people about gossiping about you: you can't really avoid it, and it can happen even without the need for you to start a conversation.

OK, enough playing around for the evening. I am happy of the Birthdate->AllowedRating information funnel result, but I am still no 100% satisfied with the information injection case: I have the intuition, but I've to work more for a proper formalization.  And the notation? Before throwing it away, I'll give it a try with the next big system I'll design and keep you appraised of the results :)

Blogging software misfired...

...or I clicked "Publish" instead of "Save Draft".

Anyway, the net result is that a post was erroneously published in draft format; since it was during the lunch break, it had the time to propagate and be reaggregated in a number of feeds. Luckily I didn't write anything especially bad, it's just that it was still very coarse, definitely unfinished and I changed my mind another 2 times on the subject before deciding to publish. Hence, FYI: in case you read a post from my feed that seems to finish mid-sentence, know that it is ACTUALLY mid-sentence :-) the complete post is here.

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 "http://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=http://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 :-)

Privacy & Money do not mix very well in Italy

Privacy is in the eye of the beholder. From time to time something happens that gives spectacular confirmation of that simple statement. Consider what happened in Italy just few hours ago.

"L'agenzia delle entrate", the Italian tax agency, published on their website the all tax declarations filed in Italy in 2006 (story in English here). It is my understanding that this is perfectly common practice in various countries, like some Scandinavian nations, but in Italy that gesture simply had no precedents. The same data has always been available in paper format in local offices, which of course made impractical (borderline impossible) consulting it, while on the web it perfectly accessible. Surprise surprise, the site crashed for all the accesses and in few hours the "garante della privacy" (an institutional figure who safeguards the right to privacy in Italy) who formally requested the data to be taken down. Too late, of course: they promptly ended up in the P2P circuits, where they'll probably circulate (no pun intended) for the next decennia. Interestingly enough, the law in some sense backs both the decisions of agenzia delle entrate and il garante. One should "assicurare la fruibilità dell'informazione in modalità digitale utilizzando con le modalità più appropriate le tecnologie dell'informazione e della comunicazione", or "ensure the access to the information  in digital format, taking advantage in the most suitable ways information & communication technologies"; that would seem to back the decision of putting the data online. OTOH "most suitable ways" is sort of ambiguous: the law establishes that the maximum timeframe in which such information should be available is a year, and even if you take down the data within that term there's no guarantee that it won't be replicated in search engine caches, P2P networks and so on.

Of course the media jumped immediately on the story, comparing the declarations of actresses and public figures (including the superblogger Beppe Grillo, who is Genovese like me :)) and in general everything and the opposite of everything happened. Politicians who claims they don't understand what the problem is, others who suggest that the taxpayers should be entitled a refund for the offense suffered, and so on. If you can read Italian, I suggest going through the comments on this article on il Corriere: again, the variety of opinions it presents is noteworthy.

I have 2 takes on this:

1. It is very difficult to adapt a law system to the situations that are possible in our modern world
2. Privacy is in the eye of the beholder. Everybody draws the line in a different place, deciding what is private and what it isn't; and I won't even mention the usual comment "the facebook generation have a different concept of privacy", because here it would be overkill. I think that the law of user control and consent is always a great CRC check; I suggest that we should all work for making its application super easy from the technical standpoint, so that it can be applied consistently whenever necessary

What can I say. E' proprio vero che a questo mondo non si finisce mai di imparare :-D e non commento oltre senno' rivelo troppo ;-)

5 years of blogging

2:35AM. I landed few hours ago in Seattle, back from a successful week in Kuala Lumpur & Singapore, and of course I am totally jetlagged and I can't sleep at all. Hence I'll kill some time writing the customarily post I do every April for this feed's birthday (former installments: 2004, 2005, 2006, 2007).

Five years is quite a long time in the IT timescale. It always amazes me to see the readership stats: given the specificity of the topics I write about, coupled with my regrettable tendency to tangents & severe verbal incontinence, one would never expect a yearly total of views well in the six digits and yet.. thanks everybody for your attention & patience :-)

Here there's a selection of some of the most popular's posts since last April. Considering that in the past year I've also worked on the book and spoke at many events, besides the usual customer engagements, I am surprised I managed to write almost 100 entries.

Some musings

• The Tao of Claims
• The Tao of Authentication series (I, II & III)
• The Authorization Continuum
• Omnidirectional Identities
• On R-STS
• On ProofTokens
• On DisplayTokens
• Cloud Computing & Identity 

Some samples & tutorials

• Sample usage of CardSpace & WF's new Send/Receive WCF activities
• Sample usage of CardSpace & WCF's new REST style services
• Sample usage of CardSpace & Excel
• Sample usage of CardSpace on non-HTTPS websites
• Sample usage of managed cards for accessing a biztalk.net RP
• The Teched EMEA STS demo series (I, II & III)

Some announcements

• Channel9 In Italian (si, sono colpevole. Ho gente da intervistare ma pochissimo tempo per farlo :()
• MySpace, REST & WCF at MIX
• Changi Hospital
• CDiscount

Well, it didn't work: I am still fully awake... apparently I need something stronger, like attacking the 2069 messages that piled up in my inbox while I was OOF. That will do :-)

Cloud Computing and Identity

On a flight between Seattle and Tokyo. I've just put down The Big Switch, and decided it's time to write about cloud computing and how identity management is going to play a key role for the success of the new paradigm. As you go though this post, please remember that (as always) you are reading my personal opinions/views and not a press release from my employer :-)

Cloud Computing: a nanointroduction

The word "Cloud" is well on its way to be one of the most hyped & overloaded term in the recent history of IT: just enter "Cloud Computing" in your search engine of choice and be prepared to navigate a huge result set. A good way of ramping up on the topic would be to read the recent Forrester report "Is Cloud Computing Ready for the Enterprise?"; or, if you are less technical, you can start by reading the aforementioned The Big Switch (as long as you read those cum grano salis, without ever turning off your critical thinking module).

For the purpose of understanding this post, I'll give you here my usual oversimplified stance:

Cloud Computing is mainly a new deployment model.

Let's say you are the solution architect of an enterprise, and you are in the process of setting up a new capability for your company. As usual, the two big alternatives are build the solution yourself, buy it as a service if available or all the intermediate approaches which combine the two. If you decide to build even just a little piece of the solution, you are implicitly stepping up for running it too: making sure your datacenter is up to the task (and beef it up if it's not), installing, updating, handling downtimes and security patches, walking the tightrope between reacting to spikes in workload and keeping costs to a reasonable level, keeping an eye on health indicators, making sure that integration with other solutions runs smoothly... business as usual. There are many cases in which the above is just a symptom of the tight grip you want to keep on your system: the more aspects you want to control the higher the overhead associated to it, and there are often good reasons for having full control. OTOH there are a great many cases in which the above is *really* an artifact of how the IT works today (habitual readers, I II & III: think of the attributes store that appeared necessary in the pre-token era but was just an artifact of using pure credentials and not identities), and you'd gladly forsake control on some details if it would mean easing the administrative burden. If you belong to the second category, cloud computing is for you. Imagine that a vendor comes to you and offers to host components your solution on his datacenter. With "host" I don't mean just giving you a slot in their racks, nor just a virtual directory in their web servers. I mean hosting your tables in their store and performing queries for you, hosting service endpoints with ESB-like capabilities, running workflows & long running processes... all things you'd do on your own application servers on your datacenter, with some important differences:

• all the basic IT chores (patching, air conditioning...) are being taken care of
• workload handling is not an issue: the vendor accommodates many customers, hence it operates a datacenter much bigger than you'd ever dream to have in-house, and its architecture will be necessarily be designed for scale. With some luck, your vendor may even offer dynamic workload (spawning more instances automatically as demand increase)
• costs are likely to be proportional to actual utilization, which finally frees you (somewhat) from the nightmare of capacity planning
• advanced capabilities are inherited "for free" by the sheer fact of being hosted in the vendor's infrastructure. If you want name resolution, advanced messaging capabilities like pub/sub, discoverability and similar, chances are you just need to check an option in the contract as opposed to set up an entire ESB yourself
• ...and many others

This is huge. Think of a startup with a great idea but not the financial prowess to afford its own datacenter, the pay as you use model is ideal; and even for bigger player the advantages are obvious, just imagine how easy it is to set up a test environment and dismantle it after your proof of concept is done.

You'll find no shortage of hype about this, the idea IS exciting and important after all, but I'd urge you to resist the temptation of being carried away and burn all the old toys. Even Mr. "IT doesn't matter" Nicholas Carr envisions a future where traditional and and cloud approaches are used together:

“…larger companies…can be expected to pursue a hybrid approach for many years, supplying some hardware and software requirements themselves and purchasing others over the grid.  One of the key challenges for corporate IT departments, in fact, lies in making the right decisions about what to hold on to and what to let go.” from "The Big Switch", Nicholas Carr.

Let me reiterate my initial point: Cloud Computing is mainly a new deployment model. Another arrow in the quiver of companies and solution architect, that will work well for slaying certain kind of monsters.

What about the relationship between Cloud Computing and S+S & SaaS? The answer depends by which team you play in. If you are an ISV, the Cloud is a great way of hosting & offering your services. It saves you many of the headaches you'd have to deal with yourself, the dynamic workload is great, and so on. I an sure you'll hear a lot about deep implications or architecture & business models.

If you are an enterprise, for you it is probably a bigger shift. You can think of it as enabling an S+S model where you are both the client and the service provider: you reap the benefits of the S+S approach (IT savings etc) and you have control on the services themselves. Control, as we know, cuts both ways: hence you get back some of the responsibilities (especially at the design level) that you deferred to others. If the service being build is your core business, where you bring IP and expertise, it is probably a good thing: if it is a general "utility" service, already covered by a specialized ISV you could use right away, probably not so much.

"But Vittorio, isn't this blog supposed to be about identity?". Right, I forgot: read on :-)

Enterprise Identities and Cloud

Let's say the vendor convinces you to move some of your services "in the cloud"; you pick one of the services with the most erratic CPU utilization pattern and you deploy it in the cloud. Great! In the figure below you can see your new situation, with a "hole" where the service now in the cloud used to be.

The service now in the cloud is part of a LoB application, which features a sophisticated authorization policy. This is one of the many benefits you reap from running a great directory (red pyramid). But hey, wait a second! What happens when one of your employees calls the service in the cloud? The service is no longer under the jurisdiction of your directory, hence the kerberos token that states your employee's affiliation with the Managers group is gibberish: how is the cloud infrastructure supposed to handle authorization the way you originally envisioned?

Now that I think of it, we have issues also in the opposite direction. As part of the LoB application, the service in the cloud will likely invoke other services:

Unfortunately it cannot do so with the blessing of the directory of your company, since it is hosted elsewhere: as a result, its siblings still deployed within your boundaries won't be able to authenticate the call.

After the initial shock, we soon realize there's no reason to panic. We know how to handle the situation, this is exactly like talking with a partner: we can set up a federation with the cloud provider. It is a bit unusual, after all it is our own very service code we are dealing with, but it can be done. In fact, this federation has another unusual aspect: while a classic partnership translates and mediates between two organizations, here one of the parties is pretty much an empty shell. The cloud provider has no users, hierarchies & roles of its own, it is simply an environment designed for running other's code. It has a "corporate" identity, sure, but it has no claims of its own that need to be translated into ours (and vice versa). Maybe we can solve the situation with something simpler than a full fledged federation in the classic sense of the word: in fact, I believe that a simple R-STS can save the day. Consider the picture below:

On top the directory pyramid I added an STS, which can give to employees portable identities in form of interoperable tokens. On the cloud side I added an R-STS, which sits on the multitenant application that takes care of authenticating the calls of the companies that subscribed to the cloud hosting offering. The scroll on the top right corner represents the configuration for our enterprise: you may notice that it contains a small copy of our directory STS, it symbolizes the fact that our cloud infrastructure (read: our R-STS) will trust tokens from our directory (read: it will accept those tokens and will issue transformed tokens in return).

How does that help? Simple. It is reasonable to assume that a service hosted in the cloud infrastructure will be configured to accept tokens issued by the cloud R-STS; and with the trust relationship just described, we just ensured that our employees can obtain such a token.

The above covers beautifully the authentication part: we've yet to deal with the authorization, though. If your services are already claim-aware, you are already OK: the R-STS can simply repackage the claims it receives from your directory STS (the approach would not work if you'd need tokens from third parties, since you'd want to verify their signature on the original token, but that's another story). If your service was not claim aware, you can still use the solution above and handle authorization. If the R-STS allows you to execute your own claim mapping rules when transforming tokens coming from your directory STS, the R-STS will basically issue a token which contains your authorization directives: at this point it is enough that the service hosting infrastructure is intelligent enough to enforce such directives. This would be a great point to place a link to my post about attribute vs authorization claims, but unfortunately I didn't finish it yet.

Let me summarize here: the cloud provider can handle authentication of incoming requests to the service it hosts with an R-STS. You can easily manage access control by having that R-STS trust you, and by having a say in the claim transformation rules applied by the R-STS. If you recognized in this what I described in this other post, congratulations: you are on the right track.

I'll leave the mirror case as exercise to the reader, just apply the same logic. If you are in the mood of some out-of-the-box thinking, you may even try to imagine how easy it would be to handle the case of the service hosted in the cloud calling home IF the services still hosted at home would have a network addressable presence in the same cloud... but I told you the solution already ;-)

ISVs, Identities and Cloud

Fine, enterprises can launch their services in orbit and yet make them available to their employees still on the ground. What about ISVs? I guess that some would say they have an even better deal with the cloud when it comes to access control & management.

Before we've seen how the enterprise twisted the behavior of the cloud R-STS for achieving this unusual eigenauthorization, gaining extra advantages (especially if doing so it discovered the power of claims) but substantially being motivated by protecting its investment during the move to a hybrid model. For the ISV, instead, the R-STS is the ultimate decoupler & the perfect trust broker: it can take care of the onboarding, authentication and integration of the ISV customers while standardizing the credentials that the ISV service itself needs to understand.

Let's consider a S+S ISV who offers a CRM solution (how original of me) from its own datacenter. Apart from the usual IT problems we already mentioned for the enterprise, the ISV needs to worry about authenticating "foreign" users. The easier is to integrate the service with customer's IT environments, the lower the entry bar and the higher the probability of doing business: that basically means that the more people you want to onboard, the more swivel chair integration you should expect to do. You have your authentication criteria and application roles (or claims if you're advanced), and you have to map those with whatever your customer has; somebody will have directories and hierarchies that will map well, smaller shops may simply collapse roles in explicit accounts (user A can do X, user B can do Y). Now consider for a moment the picture below: it represents the service we've seen before, this time from the perspective of external consumption.

Also in this case, authenticating somebody is simply a matter of telling the R-STS that it's OK to emit a token for them; and for the mapping and authorization, again we can take advantage of the policy engine of the cloud provider. The ISV does not need to worry about handling credentials anymore; it becomes a matter of administering the authorization rules, which is more a business problem than a technical one (how the ISV explains to a potential customer what is the meaning of the various claims/roles, so that the prospect can take informed decisions about what maps in where? Here we do have a need for claim mapping across orgs). In fact, one could even imagine that if a prospect of the ISV is already registered for other reasons with the cloud provider (for example because it is already customer of another ISV that hosts its services on the same cloud provider), onboarding should be a breeze.

In fact, the picture above suggests an interesting twist: if once a service is hosted in the cloud it is so easy to make it available to others, perhaps in some cases enterprises will end up recovering costs and fighting inefficiencies by acting as ISVs. Think of situations in which you have excess capacity, like if you have a wonderfully automated warehouse that ends up being empty most of the time because you got the sizing wrong. You could "rent" warehouse services (receiving, stocking, retrieving, packaging, shipping) just by taking the services that front the warehouse function already in the cloud and opening them to third parties just by changing some policies. I know I said that already, but it's *huge*.

Open Questions

All figured out, then? Far from it. In fact I realize that, with all it promises of future greatness, the above generates more questions than answers. Ho do you export policies from ACL and directory settings in claim mappings? How to give a clear authorization syntax & semantic to claims? How to have an holistic view on your access control if big parts of your assets live elsewhere? How to enable ISV customers to self provision policies in effective yet secure manner? And many others.

We'll figure those out: the incentive is strong, and the intellectual tools we have are powerful too. You can probably tell by the tone of the post, I am really excited about this! This is a powerful trend, and as I said  I am sure identity will play a pivotal role in it... I hope the industry will get it right from the start, now that we have the 7 laws we don't have excuses anymore :-)

Evangelizing the Identity Metasystem in culture-conscious fashion

Before presenting in a country I never visited I always try to read about the local culture and understand the basic do's and don'ts. Besides being IMHO a basic form of respect for your hosts, this helps you avoiding VERY embarrassing situations that you'd never ever figure out on your own. If you ever followed one of my presentations, you know that my "Identity Metasystem in a nutshell" pitch is a slide describing the msdn faceless guy having his age checked in order to get some wine.

This example served me well in many events, across many countries: US, Italy, Spain, Japan, Iceland, Germany, Netherlands are the places I can conjure up but I'm sure there's more.
A couple of days ago I was reading about one of the countries I am going to present in next week, and realized that a substantial percentage of the population profess a religion that may not find an example about alcohol consumption appropriate. I struggled a bit to find an example that would express the concept with the same directness, and picked the brain of few colleagues in the process (thanks Su!). The alternatives were good (movie rating system, voting) but I was not satisfied, I wanted something "disposable". Finally I got the right suggestion (thanks Aaron!): cigarettes.

Perfect! It is a disposable good, hence bought in a very agile way, yet it requires age verification; and, as far as I know, it should not entail cultural problems. it may not be super popular in the US, but there I will stick with wine :-). Thanks to the "change picture" function of powerpoint 2007, I modified the slide without even have to rework the animation.

Et voila', we made a step toward better understanding. I know I'll probably make another million mistakes for cultural differences reasons, but at least this one should be solved now :-)

RSA Wrapup

Well, I really really enjoyed going to RSA. As I foresaw, more than the event itself I really appreciated the chance of meeting with very smart people: the Concordia and the OSIS events were truly exceptional in this sense. Axel captured some of that spirit here. Just to mention a few notable encounters:

• I spent some quality time with Pat Patterson, mainly discussing the book. I really really appreciated his honesty and his feedback, he truly read the book with attention and his remarks were always on point: we'll make sure to incorporate them in the next revision of the book, and in fact some of the points he rose are so important that I may blog about them for clarifying. I just loved the chance of seeing things through his eyes, discussing mainly with colleagues carries the risk of falling in groupthink and I feel this was very beneficial for me. Unfortunately we didn't have more occasions of sharing our views, but I hope there will be other chances soon. Thanks Pat!
• I finally met the famous Pamela Dingle :-) Pam is great, her passion on those matters unparalleled. She gave a great presentation on the IdM, despite it was in the earliest slot the day after the Ping party (great party BTW, thanks Andre'). We had various discussions during the RSA week. For what I can tell she has a clear predisposition to the interface & interactive aspect, while I concentrate more on the protocol angle: that makes us very good conversation buddies ;)
• Vijay from FuGen showed me a great Concordia demo... in Italian! That surely caught me off balance :)
• At the identity gang dinner I was sitting with Ben Laurie, Dale Olds, Bob Blakely, Pam, Caleb and Nigel. We didn't discuss identity at all, but it was great nonetheless. Talking with smart people is a pleasure; it was quite some time I didn't have such a broad scope conversation. Two days later Dale gave a presentation about his experience with Bandit and OSIS which I really enjoyed.
• I spent some time discussing R-STSes and PPID generation strategies with a very nice guy from Oracle: I think he was Ramana, but I don't remember for sure. I'll check it, apologies!
• I had the chance of shaking hands with Paul Trevithick, Drummond Reed and Ashish Jain. I also had a very pleasant exchange with a guy from CA, but I can't remember his name :( shame on me
• Through the week I spent some time with Christian Paquin. He really does not match with the stereotype of the cryptographer, he's a very open & pleasant guy. In fact, he was very patient and after some brainstorming with Mike he took the time to walk me through the details (though not the GORY details) of U-Prove. And you know what, that's revolutionary: it's really going to rock the boat.
• I've seen a very good presentation from a Sun architect, Yvonne Wilson, and we had a brief chat. I hope there will be more occasions to exchange ideas, I truly admired her no-nonsense and lucid approach to architecture.
• And of course I really enjoyed the chance to hang out with my buddies Caleb, Nigel, Mike, Donovan, Sam, Jan, Chuck... the funniest episode happened with Caleb and Nigel. We went to a restaurant which required 30 mins for seating us: I voted for leaving, they voted for waiting. I waited, yes, but for the subsequent 30 mins I went in 'English strike": that is to say, I spoke to them exclusively in Italian even if they don't understand a word of it :-) it was hilarious, until we discovered that the waitress spoke Italian too...

and I'm failing to mention quite a lot of people, both because I am horrible with names and because in some case I had very little chance to talk.

I would not be honest if I would not mention two things that really made me super happy: the many praises for the book and for the Channel9 video on WS-Trust. It's true that I am very recognizable (hey, that's got to be the euphemism of the quarter), but I really really didn't expect people to stop me at sessions or in the aisles to tell me nice things... the biggest satisfaction came when a number of identirati told Caleb and me that they are glad we wrote the book, and that very often they answer to identity questions by referencing parts of the text. Needless to say, those identirati work on non-Microsoft platforms... this is fantastic validation that we obtained one of the goals we had in mind for the book.

I can only hope that Catalyst will be in the same style!

The PDF of Chapter 2 is on MSDN

The Cardspace landing page on MSDN has now a reference (link at the very top) to a PDF copy of the chapter 2 of "Understanding Windows CardSpace", which features the series layout for side comments & perspective boxes (mentioned here). Thanks to everybody who helped making this happen. Enjoy! :-)

April the 23rd: session & chalktalk at the Singapore's Regional Architects Forum

On the 23rd I'll be in Singapore, practically my third home, and will present at the Singapore's Regional Architect Forum (the famous RAF). There is something in that country that charmed me already during my first visit in '89, and every time I have half a chance I try to go visit. Meeting my good pal Linda is certainly one of the things I like of going to Singapore: you would no believe the staggering amount of great work she gets done, all without ever losing her smile :-) A close second would be the levels of the customers & the industry in general there. Singapore's IT is often ahead of the curve, which makes it a perfect audience for very new ideas and approaches. That's why I am looking forward to present on S+S, cloud services and how the new paradigms are already affecting the way in which we deal with identity management. I will also give a chalktalk about the internet service bus, I hope to elicit some deep discussion and explore with Singapore's architects the implications of architecting solutions with tools like the ISB (without ever forgetting the identity aspect, of course).

Also in this case Gianpaolo will present on S+S. I am sure he will provide a lot of food for thought, I can't think of anybody more qualified for explaining the topic. besides, his sessions are always fun :-) see you there!

April the 22nd: session at the IASA IT Architect Regional Conference in Kuala Lumpur

In a couple of weeks I'll be in Kuala Lumpur, at the IASA's IT Architect Regional Forum Conference; I will present on identity in the context of S+S and cloud services, which happens to be the topic that intrigues me the most nowadays. I am really excited for the session, but even more so for the chance of meeting fellow architects and discuss how these new ideas apply to their scenarios. Also: I never went to Kuala Lumpur, and I am very very curious about everything.

I'll be there with my good friend Gianpaolo, who will present (surprise surprise) on S+S. I had an exclusive preview of his session, and it's *great*. Don't miss it.
Looking forward to be there and spend some time with him and Aaron!

Podcast on "Understanding Windows CardSpace" at SearchWinDevelopment.com

Few weeks ago Caleb and I had a nice phone interview with Jack Vaughan, during which we gave a short intro to CardSpace and mentioned the book; the result is a 6 mins podcast (available here).

Thanks Jack & SearchWinDevelopment!

Passwords on PostIt... on the floor of the RSA expo :-)

Well, well, well. I was strolling trough the vendor booths at the RSA exposition (which, by the way, is really very interesting) when my eyes were caught by a peculiar scene:

[snip]

Yes, it is what it seems: a username & password pair on a PostIT!

To be honest, after talking with the booth owners given the technology demonstrated by that booth the user/password credentials were not really the point. Nonetheless, before knowing it I found just surreal to see the quintessential example of password mishandling right in the heart of RSA itself :-)

Note: I do have a picture of it and I was going to embed it in this post, but I don't think it would be nice of me to publish it to a wide audience hence I won't. Anyway I am sure you saw that scene a number of times already ;-)

Book Signing at RSA

After a remarkably quiet flight I landed in S.Francisco: the city of the Golden Gate, the Italian consulate and the theater of this year's RSA conference.

I just unloaded on the bed all the swag from the conference bag (very original BTW, love the Turing theme), and I was going through my agenda so far: believe it or not, Caleb and I actually have a book signing session (for the listeners tuning in just now, this is the book). I already felt it a bit surreal, but when I saw our names adjacent to Malcom Gladwell... well, I am smiling like an idiot since then. I know I know, there's more or less the same merit as being adjacent in the phonebook... but I'll smile nonetheless! ;-)

Note: if you want to meet you'll also find us at the OSIS Interop demonstrations and at the Concordia events

(Re)Focusing

I am delighted to announce a slight change in my role: from now on I'll focus on identity architecture, especially in the context of S+S and cloud services. YEEEEEES!!!

If you are a regular reader of this blog you may have gotten the impression it was already the case. Actually, for the last three years I worked with enterprise early adopters and connected systems (WCF, WF, CardSpace). If you ever read a case study on those, chances are I may have worked on the project in some form: I had the chance of working with the best and see a wiiide range of scenarios, I loved it (most recent example here). It's simply that when it came to blogging I just loved to dig deep in identity topics, then the articles and the book, the sessions, so... I now have the chance of staying on the topic full time. Fantastic :-)

P.S.: recently Mike challenged me to surprise everybody and make a post of just three lines (I think he was poking fun at me for the the unmanageable length of this, this and this). I thought I could do it with this post, but it turns out I am actually unable to... scary :-)