Clemens Vasters, Bldg 42

Announcing the Microsoft Code-Name "BizTalk Services" R12 Release

We’re thrilled to announce that the BizTalk Services “R12” Community Technology Preview (CTP) is now available for general use.

“BizTalk Services” is the code-name for a platform-in-the-cloud offering from Microsoft.  Currently in active development, BizTalk Services provides Messaging, Workflow, and Identity functionality to enable disparate applications to connect quickly and easily.
Combined together in an integrated offering, these capabilities deliver a Service Bus architectural pattern that is immediately usable by applications that need to connect across the Internet. 

Many enterprises employ the ‘Enterprise Service Bus’ pattern to interconnect disparate systems within an organizational domain. Built on Microsoft platform technology, an ESB might include building blocks such as Windows Server, Active Directory, BizTalk Server, as well as the Windows Communication Foundation and Windows Workflow Foundation technologies included in the .NET Framework.  “BizTalk Services” extends the concept of an ESB to truly exploit the Internet, for instance by exposing individual service endpoints in a secure fashion or by selectively federating elements of distinct identity systems to facilitate cross-company collaboration.
 
For ISVs and Solution Providers creating specialized business solutions that enable collaboration and information exchange across increasingly mobile and distributed work-forces, “BizTalk Services” provides the cloud-based platform building blocks to create sophisticated (Internet-) Service Bus solutions with broad reach that could otherwise only be realized by operating dedicated Data Centers of significant complexity – which is often out of reach for both, ISVs and their customers.

Major Changes

With the release of BizTalk Services “R12”, developers must update all clients and SDK installations to the new release. 

New in R12 - Workflow

The most exciting new capability we’ve added in the “R12” CTP is Workflow. These new cloud-based Workflow capabilities enable ‘service orchestration’ from the cloud.  This specialized cloud-based, or hosted, Windows Workflow Foundation runtime can orchestrate services that connect to systems in your enterprise, or to systems running anywhere on the Internet via Web services messages.  This new power and capability will enable an entirely new set of application scenarios, and we’re very excited to see what people will do with it.

In the SDK you will find  samples showing how to create and control Workflow instances hosted on the BizTalk Services cloud, including a sample Workflow implementation that monitors the availability of a website and fires multicast events into the service bus indicating the state.

New in R12 - Identity

For R12, the BizTalk Services Identity Service has been expanded and enhanced to enable more flexibility for scenarios demanded by our customers.  R12 introduces a new approach for creating, viewing, and managing access control rules. This approach relies on a few key principles outlined below:

• Every Identity Service account owns a Security Token Service (STS).
• An STS is composed of one or more scopes.
• A scope contains zero or more access control rules.
• An STS owner can grant another Identity Service account permission to edit the access control rules in a scope

A practical illustration to clarify:. The Messaging Service owns an STS whose root scope is http://connect.biztalk.net/services/. When you create a new account (newaccount) in the Identity Service, the messaging service creates a new scope http://connect.biztalk.net/services/newaccount. The Messaging Service then grants (newaccount) the permission to create access control rules in that scope. Any communication endpoints hosted there can thus be secured by the owner of the scope.  Rules from R11 accounts have been migrated to the “root” scope of the new account.

On the protocols front, we’ve added several new capabilities for ‘REST’ services. We now support integration with Windows Live ID and have added RFC2617 Basic and HTTPS/Client Certificate support for acquiring security tokens using simple HTTP GET requests.

New in R12 - Messaging

Connectivity Modes

The most fundamental new feature area in the Messaging service are the new ‘connectivity mode’ settings on the RelayBinding. Before this release, BizTalk Services clients and listeners always required outbound TCP ports 808 and 818 to be available for connecting to the BizTalk Services cloud for all connection modes except the clients of a listener running with ConnectionMode.RelayedHttp. 

In this release we are introducing three different connectivity modes: Tcp, Http, and AutoDetect. The connectivity mode can be set on a static property of the RelayBinding. The Communication\ExploringFeatures\ConnectionModes\Multicast sample shows how. For clarity: ‘Connection Mode’ defines the type of end-to-end connection that is to be established through the Relay. ‘Connectivity Mode’ defines how a particular endpoint connects up to the Relay.

The ‘Tcp’ connectivity mode is the most efficient one and works as in previous releases. The ‘Http’ mode is new. It creates a volatile FIFO buffer for messages in the BizTalk Services cloud and polls for messages using HTTP ‘parked requests’.  The Http model exhibits delivery latency characteristics similar to Tcp mode, albeit with slightly higher bandwidth consumption on idle connections. The ‘AutoDetect’ mode will check whether TCP connectivity is available and will choose ‘Tcp’ if that’s the case and ‘Http’ otherwise.

The new HTTP-based connectivity option is only effective for the RelayedOneway, RelayedMulticast and RelayedDuplex connection modes. RelayedDuplexSession, HybridDuplexSession, and RelayedHttp (listener only) still require TCP connectivity at this time. 

Transport Credentials and Unauthenticated Access

Also, in the “R12” release, the model for specifying the client credentials for the Relay has now been closely aligned with the standard WCF client credentials model. Instead of picking and instantiating token providers, there is now a TransportClientEndpointBehavior that holds all credential information and credential types. The samples in the Communication\ExploringFeatures\RelayAuthentication of the SDK download clarify the use of this new behavior.

We have added a pair of ‘WebNoAuth’ samples which introduce a new capability that we had a lot of requests for: Unauthenticated client access. When registering a service listener you can now explicitly waive the authentication requirement for clients connecting to your service. This is very useful in Web scenarios where you want to enable any HTTP client to connect to your service and don’t want them to authenticate in any way. For the time being we suggest that you always use this new  unauthenticated access mode for RelayedHttp services until we release the update for the ‘Web’ client authentication capability.

For R12, we have omitted the ‘Web’ (REST) samples for Relay authentication since that area is undergoing some substantial protocol changes.  The update for this will be released soon. In the interim, existing applications that were built on a prior release of the BizTalk Services SDK to use the authentication technique shown in the R11 ‘Web’ sample must be modified to use unauthenticated access as shown in the new ‘WebNoAuth’ sample.  

Give it a try

The new BizTalk Services “R12” CTP is online and available now for your use.  The SDK is available at http://labs.biztalk.net. If you already have an account for BizTalk Services, your accounts and settings have been migrated to the new environment. If you don’t have an account yet, just sign up, download the SDK, and get started creating the new generation of connected applications.  

BizTalk Services R11/R12 upgrade in progress

The BizTalk Services CTP will be switched from the "R11" to the "R12" release starting in about 30 minutes and we expect to have a 2 hour time window (1400h-1600h PT/2300h-0100h UTC) where existing service accounts are being rolled over to the new release. We're expecting to be done with the migration by 1600h. Once the migration is done we'll give you an update on what's new in R12.

BizTalk Services: Update to the services (and SDK) scheduled

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]

TechEd Time! - and what I'm up to these days

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  

What is a Token?

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...

What is a Claim?

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 ...

Federated Identity with BizTalk Services

I highly recommend reading Vittorio's most excellent and illuminating blog entry for how to use the new features we've added to BizTalk Identity Services for allowing you to use 3rd Party Managed Cards.

BizTalk Services "R11" CTP Comes with a Surprise

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]

Good Morning. It's 2008 and I have a new job.

2007 I've posted some 30 entries on my blog. That's what some of the "Whoa, listen to me, I am so awesome!" blogging crowd of today typically does in a day or two. 2008 promises to be so interesting that it would be a shame not to be blogging, and hence I do. There'll be lots of things going on in tech and in the world. 

Over the past year I've been very deeply involved in the still rather stealthy project 'Oslo' about which we'll talk about in MUCH more detail throughout this year than we have at the recent conferences. When you are in a project with tight disclosure constraints there's really nothing of any substance to talk or blog about. Hence I didn't.

However, since Wednesday I have a new job. I'm now getting my hands dirty by writing code for our Internet Service Bus infrastructure that's currently code-named 'BizTalk Services'. Here, the rules of the game are very different. We're actually building most of the stuff out in the open and are inviting people to play with it. That's really more in the spirit of how I've been working with the community in the past and therefore I'm looking forward to the fun that's to be had in this new team.

Beware; since I gather that I've lost about 95% of my readership of my main at http://vasters.com/clemensv blog due to my inactivity I will use the opportunity to adjust the agenda and make it a "everything that I find interesting" place. Expect political opinion. My MSDN blog at http://blogs.msdn.com/clemensv will get mirrored copies of the tech topics as I've done that since I work here at MSFT. If you just care about the tech stuff read the MSDN mirror. 

SOA and Business Process Conference 2007

You are in North America and not in Europe? You want more content than what fits into a track at TechEd?

No problem! Just come to the SOA and Business Process Conference that we're running October 29 - November 2 at the Microsoft Conference Center here in Redmond. There'll be lots of very interesting new stuff from teams across our division here at Microsoft. And our boss speaks, too.

If distributed systems and composite applications are your thing, you should be here for that conference. No debating, sign up and come!

Live again at TechEd Barcelona: The Steve & Clemens Show

Even though the TechEd Europe Developer Website doesn't yet clearly say so, Steve Swartz and myself will "of course!" be back with a new set of Steve & Clemens talks in Barcelona for TechEd Europe Developer (November 5-9). And for the first time we'll stay for another week and also give a talk at TechEd Europe ITForum (November 12-16) this year.

What will we talk about?

Last year we've started with a history lesson, did a broad and mostly technology agnostic overview of distributed systems architecture across 4 talks and closed with a talk that speculated about the future.

This year at the TechEd Developer show, we'll be significantly more concrete and zoom in on the technologies that make up the Microsoft SOA and Business Process platform and show how things are meant to fit together. We'll talk about the rise of declarative programming and composition and how that manifests in the .NET Framework and elsewhere. And as messaging dudes we'll also talk about messaging again. At TechEd ITForum we'll talk about the end-to-end lifecycle of composite applications and how to manage it effectively.

And of course there'll be "futures". Much less handwavy futures than last year, actually.

So .... We'll be in Barcelona for TechEd. You too?

LiveID + CardSpace

Check this out.

Sin, Sin, Sin: How to do Simple, Webby, and Completely Insecure ASP.NET Membership Authentication and Role Authorization with WCF

We're all sinners. Lots of the authentication mechanisms on the Web are not even "best effort", but rather just cleartext transmissions of usernames and passwords that are easily intercepted and not secure at all. We're security sinners by using them and even more so by allowing this. However, the reality is that there's very likely more authentication on the Web done in an insecure fashion and in cleartext than using any other mechanism. So if you are building WCF apps and you decide "that's good enough" what to do?

WCF is - rightfully - taking a pretty hard stance on these matters. If you try to use any of the more advanced in-message authN and authZ mechnanisms such as the integration with the ASP.NET membership/role provider models, you'll find yourself in security territory and our security designers took very good care that you are not creating a config that results in the cleartext transmission of credentials. And for that you'll need certificates and you'll also find that it requires full trust (even in 3.5) to use that level of robust on-wire security.

dasBlog has (we're sinners, too) a stance on authentication that's about as lax as everyone else's stance in blog-land. There are not many MetaWeblog API endpoints running over https (as they rather should) that I've seen. 

So what I need for a bare minimum dasBlog install where the user isn't willing to get an https certificate for their site is a very simple, consciously insecure, bare-bones authentication and authorization mechanism for WCF services that uses the ASP.NET membership/role model (dasBlog will use that model as we switch to the .NET Framework 3.5 later this year). The It also needs to get completely out of the way when the service is configured with any real AuthN/AuthZ mechanism.

So here's a behavior (some C# 3.0 syntax, but easy to fix) that you can add to channel factories (client) and service endpoints (server) that will do just that. If you care about confidentiality of credentials on the wire don't use it. For this to work, you need to put the behavior on both ends. The behavior will do nothing (as intended) when the binding isn't the BasicHttpBinding with BasicHttpSecurityMode.None). The header will not show up in WSDL.

On the client, you simply add the behavior and otherwise set the credentials as you would usually do for UserName authentication. This makes sure that the client code stays compatible when you upgrade the wire protocol to a more secure (yet still username-based) binding via config.

MyClient remoteService = new MyClient();
remoteService.ChannelFactory.Endpoint.Behaviors.Add(new SimpleAuthenticationBehavior());
remoteService.ClientCredentials.UserName.UserName = "admin";
remoteService.ClientCredentials.UserName.Password = "!adminadmin";

On the server, you just configure your ASP.NET membership and role database. With that in place, you can even use role-based security attributes or any other authorization mechnanism you are accustomed to in ASP.NET. Just as on the client, the behavior goes out of the way and gives way for the "real thing" once you turn on security.

using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.ServiceModel.Security;
using System.Threading;
using System.Web.Security;
using System.Xml.Serialization;

namespace dasBlog.Storage
{
    [DataContract(Namespace = Names.DataContractNamespace)]
    class SimpleAuthenticationHeader
    {
        [DataMember]
        public string UserName;
        [DataMember]
        public string Password;
    }

    public class SimpleAuthenticationBehavior : IEndpointBehavior
    {
        #region IEndpointBehavior Members

        public void AddBindingParameters(ServiceEndpoint endpoint, 
                                         BindingParameterCollection bindingParameters)
        {
           
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, 
                                        ClientRuntime clientRuntime)
        {
            if (endpoint.Binding is BasicHttpBinding &&
                ((BasicHttpBinding)endpoint.Binding).Security.Mode == BasicHttpSecurityMode.None )
            {
                var credentials = endpoint.Behaviors.Find<ClientCredentials>();
                if (credentials != null && credentials.UserName != null && credentials.UserName.UserName != null)
                {
                    clientRuntime.MessageInspectors.Add(new ClientMessageInspector(credentials.UserName));                   
                }
            }
        }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            if (endpoint.Binding is BasicHttpBinding &&
                ((BasicHttpBinding)endpoint.Binding).Security.Mode == BasicHttpSecurityMode.None)
            {
                endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new DispatchMessageInspector());
            }
        }

        public void Validate(ServiceEndpoint endpoint)
        {
           
        }

        #endregion

        class DispatchMessageInspector : IDispatchMessageInspector
        {
            #region IDispatchMessageInspector Members

            public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
            {
                int headerIndex = request.Headers.FindHeader("simpleAuthenticationHeader", "http://dasblog.info/2007/08/security");
                if (headerIndex >= 0)
                {
                    var header = request.Headers.GetHeader<SimpleAuthenticationHeader>(headerIndex);
                    request.Headers.RemoveAt(headerIndex);
                    if ( Membership.ValidateUser(header.UserName, header.Password) )
                    {
                        var identity = new FormsIdentity(new FormsAuthenticationTicket(header.UserName, false, 15));
                        Thread.CurrentPrincipal = new RolePrincipal(identity);
                    }
                }
                return null;
            }

            public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
            {
               
            }

            #endregion
        }

        class ClientMessageInspector : IClientMessageInspector
        {
            #region IClientMessageInspector Members

            UserNamePasswordClientCredential creds;

            public ClientMessageInspector(UserNamePasswordClientCredential creds)
            {
                this.creds = creds;
            }

            public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
            {
               
            }

            public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel)
            {
                request.Headers.Add(MessageHeader.CreateHeader("simpleAuthenticationHeader", http://dasblog.info/2007/08/security,
                                    new SimpleAuthenticationHeader{ UserName = creds.UserName, Password = creds.Password }));
                return null;
            }

            #endregion
        }
    }
}

XML-RPC with WCF

I'm writing lots of code lately. I've rejoined the dasBlog community and I'm busy writing a prototype for the .NET Framework 3.5 version of dasBlog (we just released the 2.0 version, see http://www.dasblog.info/).

One of the goals of the prototype, which we'll eventually merge into the main codebase once the .NET Framework 3.5 is available at hosting sites is to standardize on WCF for all non-HTML endpoints. Since lots of the relevant inter-blog and blogging tool APIs are still based on XML-RPC, that called for an implementation of XML-RPC on WCF. I've just isolated that code and put it up on wcf.netfx3.com.

My XML-RPC implementation is a binding with a special encoder and a set of behaviors. The Service Model programming experience is completely "normal" with no special extension attributes. That means you can also expose the XML-RPC contracts as SOAP endpoints with all the advanced WCF bindings and features if you like.

The binding supports client and service side and is completely config enabled. Here's a snippet from the MetaWeblog contract:

[ServiceContract(Namespace = http://www.xmlrpc.com/metaWeblogApi)]
public interface IMetaWeblog : Microsoft.ServiceModel.Samples.XmlRpc.Contracts.Blogger.IBlogger
{
   [OperationContract(Action="metaWeblog.editPost")]
   bool metaweblog_editPost(string postid,
                             string username,
                             string password,
                             Post post,
                             bool publish);

   [OperationContract(Action="metaWeblog.getCategories")]
   CategoryInfo[] metaweblog_getCategories( string blogid,
                                            string username,
                                            string password);
    ...
}

For your convenience I've included complete Blogger, MetaWeblog, and MovableType API contracts along with the respective data types in the test application. The test app is a small in-memory blog that you can use with the blogging function of Word 2007 as a client or some other blogging client for testing.

Of the other interesting XML-RPC APIs, the Pingback API has the following contract:

    [ServiceContract(Namespace="http://www.hixie.ch/specs/pingback/pingback")]
    public interface IPingback
    {
        [OperationContract(Action="pingback.ping")]
        string ping(string sourceUri, string targetUri);
    }

and the WeblogUpdates API looks like this:

    [DataContract]
    public struct WeblogUpdatesReply
    {
        [DataMember]
        public bool flerror;
        [DataMember]
        public string message;
    }

    [ServiceContract]
    public interface IWeblogUpdates
    {
        [OperationContract(Action = "weblogUpdates.extendedPing")]
        WeblogUpdatesReply ExtendedPing(string weblogName, string weblogUrl, string checkUrl, string rssUrl);
        [OperationContract(Action="weblogUpdates.ping")]
        WeblogUpdatesReply Ping(string weblogName, string weblogUrl);
    }

I'm expecting some interop bugs since I've done a clean implementation from the specs, so if you find any please let me know.

The code is subject to the Microsoft samples license, which means that you can put it into your (blogging) apps. Enjoy.

Posted by clemensv | 4 Comments

Filed under: WCF, MSDN

TweetieBot - A BizTalk Services Experiment

Having an Internet Service Bus up in the cloud is not very entertaining unless there are services in the bus. Therefore, I built one (and already showed some of the code basics) that’s hopefully fun to play with and will soon share the first version with you after some scrubbing and pending a few updates to the ISB that will optimize the authentication process. It’s a 0.1 version and an experiment. The code download should be ready in the next two weeks, including those adjustments. But you can actually play with parts of it today without compiling or installing anything. The info is at the bottom of this post.

To make matters really interesting, this sample not only shows how to plug a service into the cloud and call it from some Console app, but is a combo of two rather unusual hosts for WCF services: A Windows Live Messenger Add-In that acts as the server, and a Windows Vista Sidebar gadget that acts as the client.

Since the Silicon Valley scene is currently all over Twitter and clones of Twitter are apparently popping up somewhere every day, I thought I could easily provide fodder to the proponents of the alleged Microsoft tradition of purely relying on copying other’s ideas and clone them as well ;-)  Well, no, maybe not. This is a bit different.

TweetieBot is an example of a simple personal service. If you choose to host it, you own it, you run it, you control it. The data is held nowhere but on your personal machine and it’s using the BizTalk Services ISB to stick its head up into the cloud and at a stable endpoint so that its easily reachable for a circle of friends, bridging the common obstacles of dynamic IPs, firewalls and NAT. No need to use UPnP or open up ports on your router. If you choose to do so, you can encrypt traffic so that there’s no chance that anyone looking at our ISB nor anyone else can see the what’s actually going across the wire.

Right now, lots of the Web 2.0 world lives on the assumption that everything needs to live at central places and that community forms around ad-driven hubs. The mainframe folks had a similar stance in the 70s and 80s and then Personal Computers came along. The pendulum is always swinging and I have little doubt that it will swing back to “personal” once more and that the federation of personal services will seriously challenge the hub model once more.

So what does the sample do? As indicated, TweetieBot is a bot that plugs into a Windows Live Messenger using a simple Add-In. Bart De Smet has a brilliant summary for how to build such Add-Ins. When the Add-In is active and someone chats the bot, it answers politely and remembers the chat line, time and sender. The bird has a leaky long term memory, though. It forgets everything past the last 40 lines.

Where it gets interesting is that the Add-In can stick three endpoints into the BizTalk Services ISB:

• A Request/Response Web Service that allows retrieving the list of the last 40 (or less) “tweets” and also allows client to submit tweets programmatically.
• An RSS service that allows (right now) anyone to peek in to the chat log of the last 40 tweets.
• An Event service that allows subscribers to get real-time notifications whenever a new tweet is recorded.

The accompanying Sidebar Gadget, which is implemented using WPF, is a client for two of these services.

 When you drop the Gadget on the Sidebar, it will prompt for the IM address of the TweetieBot service you’d like to subscribe to. Once you’ve authenticated at the relay using your registered Information Card, the gadget will pull and show the current list of Tweets and subscribe to the Events service for real-time updates. And whenever someone chats the bot, the Sidebar gadget will immediately show the new entry. So even though the Gadget lives on some client machine that’s hidden between several layers of firewalls and behind NAT, it can actually get push-style event notifications through the cloud!

“How do I send events to clients?” must be one of the most frequent questions that I’ve been asked about Web Services in the past several years. Well, this is your answer right here.

While I’m still toying around with the code and the guys on the 1st floor in my building are doing some tweaks on the ISB infrastructure to make multi-endpoint authentication simpler, you can already play with the bot and help me a bit:

Using Windows Live Messenger you can chat (click here) tweetiebot@hotmail.com now. Drop a few lines. If the bot is online (which means that I’m not tinkering with it) it will reply. Then look at this RSS feed [1] and you can see what you and everyone else have been telling the bot recently. Enjoy.

[1] http://connect.biztalk.net/services/tweetiebot/tweetiebot%40hotmail.com/rss