Matias Woloski’s Blog

Don Smith announced today that Service BAT Service Factory is finally a public project. I’ve been part of this project since the beginning of the year and I can tell you that I’m pretty excited about it. Jason Hogg said that this were going to change the way we develop SO applications.

This is a great moment for people writing Service Oriented apps using Microsoft technologies!

First, if you are not aware of patterns & practices latest
activities, let me tell you that they’ve been creating BATs, Baseline
Architecture Toolkits, which are more than App Blocks. They cover the
whole thing! The first one was the SC-BAT (for Smart Client apps using CAB) which was more than successful. So here is the definition:

 What is a BAT? A BAT is a collection of various forms of guidance (written
guidance like patterns, reusable code like application blocks,
executable code like reference implementations, and guidance packages
embedded in Visual Studio) to help .NET developers and architects build
a certain kind of application.

What is the scope of Service BAT Service Factory? In short, from the proxy to the database.

Join this project if you want to

• Write Service Oriented apps using WCF or ASMX
• Leverage the best practices and the experience of a 50 recognized experts in the
  field (the advisor board) and a group of Redmond brainees
• Automate the menial tasks of creating a Service by leveraging the use of GAT
• If you were looking for the Grail on writing backends for Enterprise Applications
• Solve most of the cross-cutting concerns (Exception Shielding, Logging, Versioning, Security, Data Entitlement, and more)
• Align to WCF
• Have great tooling for WCF

See you there!

UPDATE: want to see some early screenshots? look at Edward Bakker post. Christian Weyer also blogged about it.

UPDATE 2: Service BAT was rebranded. Now it’s Web Service Software Factory.

One of the challenges presented when developing Service-Oriented
application is how to setup the authorization for services. That means
"Role salesman is granted to access CreateOrder service"

The ideal would be:

1. to have a pipe & filters pluggable architecture where you
   could add/remove components without affecting the code of the services
   (this is also called cross-cutting concerns)
2. to have a nice GUI to manage Tasks and Roles
3. to have a programmatic API to do the access check in an agnostic
   provider way so if we want to change the Authorization provider in the
   future, make it painless.

Luckily these days of continous innovation we have all of these to support it:

1. WSE 3 and it Policy Assertions
2. AzMan (Authorization Manager)
3. Enterprise Library or RoleProvider of ASP.Net 2

Regards (1) I’ve already written in a previous post about the Policy
Assertions and its purpose. The idea would be to plug a Policy
Assertion that would call AzMan through EntLib or RoleProvider. In this
assertion we take the Action name of WSE using envelope.Context.Addressing.Action.Value and the WindowsPrincipal if we are using KerberosToken in WSE.

In (2) we have this great GUI (Azman.msc) to manage Tasks and Roles.

To install AzMan on Windows XP Professional

Install the Windows Server 2003 Administration Tools Pack, which you
can download from
http://www.microsoft.com/downloads/details.aspx?FamilyID=e487f885-f0c7-436a-a392-25793a25bad7&DisplayLang=en.
This tools pack enables remote server management of Windows Server
2003, but it also includes AzMan.

Note that if you are running Windows XP Service Pack 2 or later, you
must also install Service Pack 1 or later of the Windows Server 2003
Administration Tools Pack.

To install AzMan on Windows 2000

Install the Windows 2000 Authorization Manager Runtime, which you can
download from
http://www.microsoft.com/downloads/details.aspx?FamilyID=7edde11f-bcea-4773-a292-84525f23baf7&DisplayLang=en.
You must be running Windows 2000 Server Service Pack 4 or later. You
must also install MSXML 4.0 or later.

Note that this installs the runtime components only; it does not
install the AzMan administration MMC snap-in. You can still use the MMC
snap-in on a Windows Server 2003 system, or on a Windows XP system that
has the Windows Server 2003 Administration Tools Pack installed, to
remotely administer AzMan on a Windows 2000 Server.

On Windows XP and Windows 2000, you must install the primary interop
assembly for the AzMan COM object into the global assembly cache. This
assembly is already installed in the global assembly cache on Windows
Server 2003 systems.

Finally regards (3) we could use Enterprise Library Security Application Block which implements an AuthorizationProvider based on Azman. I show in this post
how to use it. Using EntLib will abstract us from the store which in
this case is AzMan and this will lead to more flexibility because in
the future we could use another store (SQL Server, ADAM, AD, etc).

The thing I didn’t like about AzMan was that it is bounded to Windows
Tokens. But after some research I found the Custom SID story.

These series of posts talk about how to implement it.

Read this article for an indepth on this post: Combine the Powers of AzMan and WSE 3.0 to Protect Your Web Services from the November 2005 of MSDN Magazine

Setup secure conversation using WSE 3 was very simple. You just need to
add two attributes to the secure policy assertion
(usernameOverCertificate, mutual, etc).

establishSecurityContext="true" renewExpiredSecurityContext="true"

The
problem was when I wanted to establish the secure conversation, get the
token and use it in further requests. Secure conversation means just
this:

1. Send a first request with a UsernameToken (username/password), BinarySecurityToken (certificate).
2. The service will reply with two messages: the response of the
   original request and a RequestSecurityTokenResponse which will have the
   SecurityContextToken issued
3. Grab the SecurityContextToken
4. Send a second request with a SecurityContextToken (now there is
   no need to send UsernameToken or whatever which means more performance
   and security)

How this four steps are translated into code?

1 and 2.

WseProxy proxy = new WseProxy();proxy.SetClientCredential(new UsernameToken(txtUser.Text, txtPass.Text, PasswordOption.SendPlainText));proxy.SetPolicy(“ClientPolicy”);SomeResponse respone = proxy.DoRequest();

3.

SecureConversationCorrelationState correlationState = proxy.ResponseSoapContext.SessionState.Get();if (correlationState != null){     // Get the SCT for the current conversation
     sct = correlationState.Token as SecurityContextToken;}

4.

WseProxy proxy = new WseProxy();proxy.SetClientCredential(sct);proxy.SetPolicy(“ClientPolicy”);SomeResponse respone = proxy.DoRequest();

The trick is in the step 3 where we are getting the
SecurityContextToken from the session state under the response soap
context. We could store this sct in the ASP.Net Session, or in a static
variable for Winforms and use it for further requests.

I’ve been playing with WSE 3 because I wanted to fully understand how Policy Assertions, SoapFilters and the Pipeline work. My tools were: Reflector and a test harness example consisting of a custom Policy Assertion that creates a SoapFilter that logs to an xml file. Note: I’ve used WSE 3.0.5152 which is the June CTP because I was using VS 2005 Beta 2.

I recommend you reading this post from Mike Taulty so we are all on the same page.

My tests:

1. The normal execution flow
2. What happens when an Exception is being thrown from the webservice?
3. What happens when an Exception is being thrown from a SoapFilter?
4. Short-circuitingon client-output, client-input, service-input and service-output

I’ve created some nice drawings to illustrates what is happening in each case. So here we go…

Here  I decided to go with reflector because the short-circuiting
was not behaving as I expected, so I found the ProcessInputMessage and
ProcessOutputMessage from the Pipeline class.

ProcessOutputMessage

 using (IEnumerator enumerator1 = ((IEnumerator) this.outputFilters.GetEnumerator()))            {                  while (enumerator1.MoveNext())                  {                        SoapFilter filter1 = enumerator1.get_Current();                        SoapFilterResult result1 = filter1.ProcessMessage(envelope);                        if (result1 == null)                        {                              throw new InvalidOperationException(string.Format("SoapFilter of type ‘{0}’ did not return a valid result from ProcessMessage", filter1.GetType().ToString()));                        }                        if (result1.Stop)                        {                              flag1 = false;                              goto Label_014A;                        }                  }            }

ProcessInputMessage

using (IEnumerator enumerator1 = ((IEnumerator) this.inputFilters.GetEnumerator()))            {                  while (enumerator1.MoveNext())                  {                        SoapFilter filter1 = enumerator1.get_Current();                        SoapFilterResult result1 = filter1.ProcessMessage(envelope);                        if (result1 == null)                        {                              throw new InvalidOperationException(string.Format("SoapFilter of type ‘{0}’ did not return a valid result from ProcessMessage", filter1.GetType().ToString()));                        }                        if (result1.TargetMethod != null)                        {                              method1 = result1.TargetMethod;                              goto Label_012A;                        }                  }            }

Note that both methods are using either on the client-side and the service-side. What attracted my attention was that ProcessInputMessage doesn’t analyze the result whether is Continue or Stop.

So I would not be able to do any short circuiting when messages get

into the service or the client. A very common use of this is doing

idempotent where I check the message id and reply with a already

processed message stored in a cache.

Am I missing something here?

Anyway, I will try again when WSE gets out on November.