Pablo M. Cibraro (aka Cibrax)

Configuring both products to work together can be a nightmare.
I've spent almost three days trying to configure Azman and ADAM membership providers in a normal ASP.NET application, but I couldn't.
I wanted to use ADAM as user/group repository and Azman as authorization repository (to have fine grained access control and manage roles).
This article from MSDN has helped me a lot to configure both products, but it's a little tricky. It shows how to use ADAM as a repository for the Azman schema, but not as authentication server. Instead it uses a windows user to get the azman roles.

WSE 2.0 and 3.0, both provide AES128 + RSA 1.5 as default algorithms for symmetric encryption and key-wrap.
However, AES256 + RSA-OAEP are always recommended for these purposes, and Indigo will ship with that combination as default.

The "WS-I Basic Security Profile Sample Application" preview for WSE 3.0 is out, you can get it in the GDN workspace.
This sample illustrates how to build secure and interoperable web services based in the specification WS-I Basic Profile 1.1.
When we started to develop this application, we faced some challenges, all of them related to the new policy framework shipped in WSE 3.0.
Some parts of the policies used by the previous version of this application weren't easy to migrate, so we had to develop some custom assertions.
In this post, I will give a brief description about the new WSE "Policy framework", and the custom assertion shipped in this preview. (CustomX509Assertion)

This script is helpful when you have different versions of the .NET framework running in your computer and you need to setup a virtual directory in IIS targeting one of them.
If you have the versions 1.1 and 2.0, when you create a virtual directory in IIS, it takes a version by default, usually 1.1.

SQL Server 2005 ( Codenamed "Yukon" )  provides a new interesting feature to execute stores procedures or Transact-SQL statements through web services published in the server, without need to use IIS.
This new feature exposes Http endpoints using the Http Api provided in Windows XP SP2 and Windows 2003.
These endpoints are published in a specific URI, and they listen for incoming soap requests, so they facilitate interoperability because any application, which talks soap, can communicate with SQL server without requiring additional sql libraries or MDAC.

In my last post, I talked about hosting the CRL within a native custom action.
This week I found an easier way to execute a managed custom action, it is based on a hack and not extra C++ code is required.
Actually, you can't write a C# custom action because the compiler doesn't allow you to create a __stdcall function to be 
called from the outside.
Well, take a look to this article, it shows how to overcome that problem.

Today, in order to develop a custom action for a Window Installer setup, you can choose between two options: