Heads up: If things go as planned, the BizTalk Services cloud will be unavailable for a few hours during the day on Tuesday 7/15 (U.S. Pacific Time) since we're doing an update to the services and to the SDK. I will post an update with the exact time window some time on Monday. Once we're back up and have verified that everything is working as intended we'll let you know about it and tell you what's new.
Applications built on the R11 release (the release currently running in the data center) will have to be recompiled (and in some instances slightly changed) against the new R12 release's assemblies to run with R12. We've done some protocol adjustments in R12 that make this necessary - mind that we're still in "experimentation-only preview" mode here. Theory suggests that some compiled R11 applications will work against the R12 cloud, but it's not a combination we're explicitly testing as of yet. We obviously have that sort of backwards compatibility on the radar (it's SOA, should be easy, right?) but it'll likely take us a couple more revisions before we're happy enough with the baseline protocols.
[Update: The switch to R12 will happen between 1400-1600 PT/2300-0100 UTC. More later]
Just found this piece about why users should be scared of Apple's push-channel to the iPhone. Quote:
Why not find out which apps are getting the most use and offering the developers special licensing deals? Better yet, why not sell that information to third parties like advertisers to help them work with highly used apps to sell ad units or sponsorships while getting an additional cut? This new tunnel for data is a veritable gold mine that's not just metrics--it's attached to user IDs and billing information too.
That's somewhat interesting, but doesn't scare me. What scares me is that Apple has a backchannel AND the device has GPS built in. I'm keenly aware that the mobile phone carriers can triangulate my whereabouts with some precision, but that's the carrier. Here we're talking about a third party that happens to make the hardware and with whom I have no contractual relationship whatsoever. I'd own the device, my contract would be with AT&T.
There's significant uproar whenever any app is trying to phone home for privacy reasons. If that is worrying you even for tiny little moment, you should be worried about what Apple is doing there.
Didn't I write that I wanted to blog more this year? It's June, you see what came out of that.
First things, first; I'm flying to Orlando tomorrow for TechEd. Looking back at what my conference schedule looked like up until 2 years ago, it's hard to believe that this is my first (!) scheduled conference talk this year. I actually do miss the life on the road a little bit. The compensation for it is that I get to see my family every day (my daughter Eva's first birthday is coming up on June 25th) and that I'm getting to work on and define the stuff that I 'just' used to be talking about. This really is the first time that I do a talk about a Microsoft technology that I own; so that's a bit of a thing:
SOA 403 Building Federated Solutions on the Internet Service Bus
Thursday, June 5, 2008 10:15AM-11:30AM
Room: S220 C (DEV)
'Own' means here that I'm the responsible Program Manager for the entire 'Messaging' feature area of BizTalk Services in what we call the '.NET Online Services' team around here. The PM title isn't entirely accurate, because I'm also writing pretty substantial amounts of product code these days. The ability to write and contribute code into the product was the primary reason why I switched jobs and joined the team I'm now in, but it turned out that the PM role was the overall better fit for me. So I'm 60% PM and 40% Dev. Or something like that.
Back to TechEd. There are two talk about what we're building. The first one is 'today' (I'm still on Pacific Time so I realize that may be a bit late); Justin Smith will provide a broad overview on the services we're building:
SOA206 Messaging, Identity, and Workflow in the Cloud
Tuesday, June 3 10:30 AM - 11:45 AM
Room: S220 C
The second talk is mine (above) and as you might be able to tell by the '400' classification I've got the clear intent not to spend too much time in Powerpoint. I am going to show four common architectural issues and ways to deal with them using the cloud platform. And I'm going to show you the code for it. I also plan (we'll see how that part goes with the on-site network) to host an app for 'crowd participation' so that I'm explicitly not going to ask you to turn your laptops off. Since the BizTalk Services SDK hasn't spread very broadly, yet, I'll base the majority of the demos on the SDK samples so that you can easily repro the stuff that I show you.
Now ... you say ... "BizTalk Services? I don't have anything to do with BizTalk! Do you want to sell me BizTalk Server?"
Well, it's always nice if customers decide to pick up some BizTalk Server licenses, but: No, I don't. Our stuff does actually compose with BizTalk Server 2006 R2 through the WCF Adapter, but the way to think about this code-name is that 'BizTalk' just happens to be the brand that our division has been using for Messaging. There was the BizTalk Framework, BizTalk Server and now we've got BizTalk Services. It's a brand. And we're actually finding that that name isn't really a perfect fit for what we're doing; customers suggest the same. So there'll be a different name. I'm guessing we're going to talk about that new name and some other cards we hold in our hands at or around PDC.
The stuff that I own in the 'Cloud' Messaging area are Naming, Service Registry, Connectivity/NAT Traversal, Relay, Eventing, a bunch of internal, servide-side infrastructure supporting those feature areas and some feature areas that we'll talk about more at PDC. So the fun part of TechEd for me (and you) is that the 'feedback opportunity' is pretty immediate. We're updating the services (just about) every quarter and I'll probably check in my last set of stuff for the current release cycle from Orlando or the night I get back here. From there I'm switching into planning mode for the next release (aligned with PDC) and if you bring good ideas that we can fit into the next cycle, I'm very inclined to take them. Not that we'd have any shortage of feature ideas, mind you. More is better.
If you are in Orlando .. I'll have booth duty at the WCF booth in the Exhibition Hall (or whatever they call it this year) both Wednesday and Thursday from 2:30PM to closing so come see me there or come to see my talk or just grab me at the Attendee Party if you can recognize me. 
I wonder whether whoever is in charge of architecture at Twitter has already figured out that they aren't running a website but an Internet-scale, one-way, pub/sub messaging relay.
Earlier today I hopefully gave a somewhat reasonable, simple answer to the question "What is a Claim?" Let's try the same with "Token":
In the WS-* security world, "Token" is really just a another name the security geniuses decided to use for "Handy package for all sorts of security stuff". The most popular type of token is the SAML (just say "samel") token. If the ladies and gentlemen designing and writing security platform infrastructure and frameworks are doing a good job you might want to know about the existence of such a thing, but otherwise be blissfully ignorant of all the gory details.
Tokens are meant to be a thing that you need to know about in much the same way you need to know about ... ummm... rebate coupons you can cut out of your local newspaper or all those funny books that you get in the mail. I have really no idea how the accounting works behind the scenes between the manufacturers and the stores, but it really doesn't interest me much, either. What matters to me is that we get $4 off that jumbo pack of diapers and we go through a lot of those these days with a 9 month old baby here at home. We cut out the coupon, present it at the store, four bucks saved. Works for me.
A token is the same kind of deal. You go to some (security) service, get a token, and present that token to some other service. The other service takes a good look at the token and figures whether it 'trusts' the token issuer and might then do some further inspection; if all is well you get four bucks off. Or you get to do the thing you want to do at the service. The latter is more likely, but I liked the idea for a moment.
Remember when I mentioned the surprising fact that people lie from time to time when I wrote about claims? Well, that's where tokens come in. The security stuff in a token is there to keep people honest and to make 'assertions' about claims. The security dudes and dudettes will say "Err, that's not the whole story", but for me it's good enough. It's actually pretty common (that'll be their objection) that there are tokens that don't carry any claims and where the security service effectively says "whoever brings this token is a fine person; they are ok to get in". It's like having a really close buddy relationship with the boss of the nightclub when you are having troubles with the monsters guarding the door. I'm getting a bit ahead of myself here, though.
In the post about claims I claimed that "I am authorized to approve corporate acquisitions with a transaction volume of up to $5Bln". That's a pretty obvious lie. If there was such a thing as a one-click shopping button for companies on some Microsoft Intranet site (there isn't, don't get any ideas) and I were to push it, I surely should not be authorized to execute the transaction. The imaginary "just one click and you own Xigg" button would surely have some sort of authorization mechanism on it.
I don't know what Xigg is assumed to be worth these days, but there is actually be a second authorization gate to check. I might indeed be authorized to do one-click shopping for corporate acquisitions, but even with my made-up $5Bln limit claim, Xigg may just be worth more that I'm claiming I'm authorized to approve. I digress.
How would the one-click-merger-approval service be secured? It would expect some sort of token that absolutely, positively asserts that my claim "I am authorized to approve corporate acquisitions with a transaction volume of up to $5Bln" is truthful and the one-click-merger-approval service would have to absolutely trust the security service that is making that assertion. The resulting token that I'm getting from the security service would contain the claim as an attribute of the assertion and that assertion would be signed and encrypted in mysterious (for me) yet very secure and interoperable ways, so that I can't tamper with it as much as I look at the token while having it in hands.
The service receiving the token is the only one able to crack the token (I'll get to that point in a later post) and look at its internals and the asserted attributes. So what if I were indeed authorized to spend a bit of Microsoft's reserves and I were trying to acquire Xigg at the touch of a button and, for some reason I wouldn't understand, the valuation were outside my acquisition limit? That's the service's job. It'd look at my claim, understand that I can't spend more than $5Bln and say "nope!" - and it would likely send email to SteveB under the covers. Trouble.
Bottom line: For a client application, a token is a collection of opaque (and mysterious) security stuff. The token may contain an assertion (saying "yep, that's actually true") about a claim or a set of claims that I am making. I shouldn't have to care about the further details unless I'm writing a service and I'm interested in some deeper inspection of the claims that have been asserted. I will get to that.
Before that, I notice that I talked quite a bit about some sort of "security service" here. Next post...
If you ask any search engine "What is a Claim?" and you mean the sort of claim used in the WS-* security space, you'll likely find an answer somewhere, but that answer is just as likely buried in a sea of complex terminology that is only really comprehensible if you have already wrapped your head around the details of the WS-* security model. I would have thought that by now there would be a simple and not too technical explanation of the concept that's easy to find on the Web, but I haven't really had success finding one.
So "What is a Claim?" It's really simple.
A claim is just a simple statement like "I am Clemens Vasters", or "I am over 21 years of age", or "I am a Microsoft employee", or "I work in the Connected Systems Division", or "I am authorized to approve corporate acquisitions with a transaction volume of up to $5Bln". A claim set is just a bundle of such claims.
When I walk up to a service with some client program and want to do something on the service that requires authorization, the client program sends a claim set along with the request. For the client to know what claims to send along, the service lets it know about its requirements in its policy.
When a request comes in, this imaginary (U.S.) service looks at the request knowing "I'm a service for an online game promoting alcoholic beverages!". It then it looks at the claim set, finds the "I am over 21 years of age" claim and thinks "Alright, I think we got that covered".
The service didn't really care who was trying to get at the service. And it shouldn't. To cover the liquor company's legal behind, they only need to know that you are over 21. They don't really need to know (and you probably don't want them to know) who is talking to them. From the client's perspective that's a good thing, because the client is now in a position to refuse giving out (m)any clues about the user's identity and only provide the exact data needed to pass the authorization gate. Mind that the claim isn't the date of birth for that exact reason. The claim just says "over 21".
Providing control over what claims are being sent to a service (I'm lumping websites, SOAP, and REST services all in the same bucket here) is one of the key reasons why Windows CardSpace exists, by the way. The service asks for a set of claims, you get to see what is being asked for, and it's ultimately your personal, interactive decision to provide or refuse to provide that information.
The only problem with relying on simple statements (claims) of that sort is that people lie. When you go to the Jack Daniel's website, you are asked to enter your date of birth before you can proceed. In reality, it's any date you like and an 10-year old kid is easily smart enough to figure that out.
All that complex security stuff is mostly there to keep people honest. Next time ...
A flock of pigs has been doing aerobatics high up over Microsoft Campus in Redmond in the past three weeks. Neither City of Redmond nor Microsoft spokespeople returned calls requesting comments in time for this article. An Microsoft worker who requested anonymity and has seen the pigs flying overhead commented that "they are as good as the Blue Angels at Seafair, just funnier" and "they seem to circle over building 42 a lot, but I wouldn't know why".
In related news ...
We wrapped up the BizTalk Services "R11" CTP this last Thursday and put the latest SDK release up on http://labs.biztalk.net/. As you may or may not know, "BizTalk Services" is the codename for Microsoft's cloud-based Identity and Connectivity services - with a significant set of further services in the pipeline. The R11 release is a major milestone for the data center side of BizTalk Services, but we've also added several new client-facing features, especially on the Identity services. You can now authenticate using a certificate in addition to username and CardSpace authentication, we have enabled support for 3rd party managed CardSpace cards, and there is extended support for claims based authorization.
Now the surprising bit:
Only about an hour before we locked down the SDK on Thursday, we checked a sample into the samples tree that has a rather unusual set of prerequisites for something coming out of Microsoft:
Runtime: Java EE 5 on Sun Glassfish v2 + Sun WSIT/Metro (JAX-WS extensions), Tool: Netbeans 6.0 IDE.
The sample shows how to use the BizTalk Services Identity Security Token Service (STS) to secure the communication between a Java client and a Java service providing federated authentication and claims-based authorization.
The sample, which you can find in ./Samples/OtherPlatforms/StandaloneAccessControl/JavaEE5 once you installed the SDK, is a pure Java sample not requiring any of our bits on either the service or client side. The interaction with our services is purely happening on the wire.
If you are a "Javahead", it might seem odd that we're shipping this sample inside a Windows-only MSI installer and I will agree that that's odd. It's simply a function of timing and the point in time when we knew that we could get it done (some more on that below). For the next BizTalk Services SDK release I expect there to be an additional .jar file for the Java samples.
It's important to note that this isn't just a thing we did as a one-time thing and because we could. We have done a significant amount of work on the backend protocol implementations to start opening up a very broad set of scenarios on the BizTalk Services Connectivity services for platforms other than .NET. We already have a set of additional Java EE samples lined up for when we enable that functionality on the backend. However, since getting security and identity working is a prerequisite for making all other services work, that's where we started. There'll be more and there'll be more platform and language choice than Java down the road.
Just to be perfectly clear: Around here we strongly believe that .NET and the Windows Communication Foundation in particular is the most advanced platform to build services, irrespective of whether they are of the WS-* or REST variety. If you care about my personal opinion, I'll say that several months of research into the capabilities of other platforms has only reaffirmed that belief for me and I don't even need to put a Microsoft hat on to say that.
But we recognize and respect that there are a great variety of individual reasons why people might not be using .NET and WCF. The obvious one is "platform". If you run on Linux or Unix and/or if your deployment target is a Java Application Server, then your platform is very likely not .NET. It's something else. If that's your world, we still think that our services are something that's useful for your applications and we want to show you why. And it is absolutely not enough for us to say "here is the wire protocol documentation; go party!". Only Code is Truth.
I'm also writing "Only Code is Truth" also because we've found - perhaps not too surprisingly - that there is a significant difference between reading and implementing the WS-* specs and having things actually work. And here I get to the point where a round of public "Thank You" is due:
The Metro team over at Sun Microsystems has made a very significant contribution to making this all work. Before we started making changes to accommodate Java, there would have been very little hope for anyone to get this seemingly simple scenario to work. We had to make quite a few changes even though our service did follow the specs.
While we were adjusting our backend STS accordingly, the Sun Metro team worked on a set of issues that we identified on their end (with fantastic turnaround times) and worked those into their public nightly builds. The Sun team also 'promoted' a nightly build of Metro 1.2 to a semi-permanent download location (the first 1.2 build that got that treatment), because it is the build tested to successfully interop with our SDK release, even though that build is known to have some regressions for some of their other test scenarios. As they work towards wrapping up their 1.2 release and fix those other bugs, we’ll continue to test and talk to help that the interop scenarios keep working.
As a result of this collaboration, Metro 1.2 is going to be a better and more interoperable release for the Sun's customers and the greater Java community and BizTalk Services as well as our future identity products will be better and more interoperable, too. Win-Win. Thank you, Sun.
As a goodie, I put some code into the Java sample that might be useful even if you don't even care about our services. Since configuring the Java certificate stores for standalone applications can be really painful, I added some simple code that's using a week-old feature of the latest Metro 1.2 bits that allows configuring the Truststores/Keystores dynamically and pull the stores from the client's .jar at runtime. The code also has an authorization utility class that shows how to get and evaluate claims on the service side by pulling the SAML token out of the context and pulling the correct attributes from the token.
Have fun.
[By the way, this is not an April Fool's joke, in case you were wondering]
Reading Techmeme I'm seeing that Yahoo! went the way of laying off in the order of a thousand heads by salary ranges rather than experience level.
Look, Seattle's reuptation for weather may be well deserved, but - on the upside - we actually have weather. You know - rain, snow, wind, freezing - all that stuff that reminds you that you are alive - PLUS 5 months of glorious spring/summer weather where it never gets too hot and never too cold. And we've got the water and the mountains. It's gorgeous here.
Oh, and, we're really not that evil here. I'm having great fun working here all day. My boss looks or acts nowhere near like Darth Vader (he's actually a former Silicon Valley dude who's still adjusting to the climate). I'm learning from people smarter than me every day. I even get to write code on platforms and runtime I've never thought I'd ever touch; and I'm not talking about VB6 or Fortran.
So if you are up for a challenge and want to extend the reach of the .NET Framework into the "cloud" like we're doing here at http://labs.biztalk.net (bigger, bigger stuff ahead), I'll stick my head out - you can write me email at clemensv@microsoft.com with your resume and I will connect you to the right folks.
And for the long-time readers of my blog: You can write me too. If you want to make an big impact in the industry, now's the time. Oh, and, FWIW, you'll likely get to work with me, but you should rather look forward to work with the gusy I work with.
|