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!

Categories: Talks | SOABP

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?

Categories: Architecture | Talks | TechEd Europe

August 28, 2007
@ 12:58 AM
Categories: Technology | CardSpace

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

Categories: Indigo | WCF

August 21, 2007
@ 07:46 AM

UPDATE: The code has been updated. Ignore this post and go here.

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.

Categories: MSDN | Indigo | WCF | Weblogs

I wanted to get the blog going again with something more substantial than this (I've got several demos in the pipeline, including an XmlRpcHttpBinding for WCF), but given the circumstances, I'll start with this here.

My wife, the baby and I went to Seafair on Saturday to see the boat races and the air show. It was a beautiful day and we had a lot of fun with friends. On the shuttle bus back to the Eastgate P&R little Eva suddenly (and quite loudly) started demanding food, so we hastily dug up all the necessary stuff from the stroller and that required taking the camera bag off the stroller. So I put the camera bag on the seat right next to me - and that's where I left it. Pretty stupid. So if someone found it and finds this post through a search  ... clemensv@microsoft.com

Sigh!

Categories: