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

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.

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.

Winer writes:

The problem is that they're not bloggers, they're reporters and they work for a company that's not a blog, it's a publication. Publishing stuff on the web with blogging software says nothing about the people and what they write.  

A blogger is person who has an idea, expertise or opinion who wants to convey that to other people. The unedited voice of a person. What makes a blogger interesting is that they do something other than writing a blog. If all you do is write a blog, and if you want or need to make money from your blogging, it's really hard to distinguish what you're doing from what professionals who don't use the web (are there any left?) do. 

Amen. With what's currently considered a "tech blogger" I really, really don't want to be in that crowd. When I look at TechMeme, the scene seems to be increasingly degenerating into a bunch of self-congratulating, "Boy, am I important", corrupt attention whores seekers who are pimping themselves out to PR bribes and advertising traffic without having much of an original idea themselves.    

Turns out that I much prefer TechMeme's sister site WeSmirch these days. The drama is the same, but the people being talked about are either in entertainment and make a mess out of themselves for a living or are wrecks much beyond what a geek would ever become. That's more fun to watch. A pissing match between TechCrunch and Blognation or whether some stupid idiot from Gizmodo gets thrown out of CES is so very interesting that I rather keep track of what Britney is up to.

It is ridiculous how many people spell ridiculous 'rediculous' these days. I must be reading the ridiculous spelling 'rediculous' dozens of times a day. English is my second language and I'm far away from claiming that I know it all, but if thousands of people keep making the same mistake on a regular basis it just makes my eyes bleed and my brain's spell-checker revolt. Same goes for 'definately' (wow, I really need to clean out the spam on that old page) and the horrific 'there' instead of 'their'.

Luckily, I just found that I'm not alone:

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. 

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!

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?

Check this out.

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