A while back I posted about the algorithm used for creating a test ID within VSTS Test Lists. I also made mention that I was writing a utility that allowed for basic test list management and unfortunately more time has passed between that post and me actually putting something out there for the community. In all honesty, this tool is very basic and I haven't had much time to work on it, but I hope it is feature complete enough to at least be usable by people wanting to create test lists for their build process.

When using this tool, the vsmdi file created must be at the solution root for the project (which is where VSTS puts it when they create it - this tool won't default to that location, but that is where it needs to be put). To create a test file, go to File->New and create the test list file (name it with a .vsmdi extension). When the file gets created, there are three nodes in the tree view (Lists of Tests, Tests Not in a List, All Loaded Tests). To add test lists to the file, right click on the Lists of Tests node and select "New Test List...". Within the new window, type the name of the test list and click OK. Test lists can be nested and you can create as many test lists as you like, but they must only be created under the "Lists of Tests" node. To load up tests, select File->Open and select .dll for the file filter. Navigate down to the location of your test assembly (test assemblies must be somewhere within the same directory tree as the vsmdi file) and load the dll into the application. Select the All Loaded Tests node to view all the tests within the test assembly. Expand the Lists of Tests node and drag tests from the grid to the correct test list (the Test List field in the grid will get populated with the fully qualified location of the test). Select File->Save to save off the vsmdi file and now this file should be usable by Team Build for your unit test execution during a build.

Here is the source for the management tool, hope you find it useful. If there are missing references, the location for the 2 files is C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies and you will need Microsoft.VisualStudio.QualityTools.Common.dll and Microsoft.VisualStudio.QualityTools.Tips.UnitTest.ObjectModel.dll.

Please let me know your experience with this utility (good, bad, or otherwise).

A major problem facing people today is that their identity/information is not secure when dealing with the web. It is not that measures haven't been taken to protect the data as it is transferred from my web browser to the destination web server, in fact there are many encryption methods out there to make sure the data is safe as it goes across the wire, but the main problem seems to be between my brain and my keyboard. My data is safe as it is sent, but am I sending my data to the correct site? I know the data is secure since I see "https" in my address bar and the web page is "locked" but all that tells me is the site I am sending information to has a valid SSL certificate. I am still never blatantly told what site my data is going to (sure it is in the URL, but how many times have we seen valid URLs that are very cryptic). In fact, the people employing "phishing" tactics rely on me not knowing this piece of information. If I knew I wasn't actually sending my username and password to my actual bank site, I would never try to perform a log on.

How do we get around this problem you ask. Well that is where Kim Cameron's work comes in to play with the Laws of Identity. These are "laws" that were collaborately created which discuss what would generically be needed to ensure identity security.

1. User Control and Consent - Technical identity systems must only reveal information identifying a user with the user's consent.
2. Minimal Disclosure for a Constrained Use - The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
3. Justifiable Parties - Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
4. Directed Identity - A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
5. Pluralism of Operators and Technologies - A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
6. Human Integration - The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offing protection against identity attacks.
7. Consistent Experience Across Contexts - The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

So, how are these laws applied to the three major actors Relying Party, Identity Provider, and Identity Selector? Well, they always say a picture is worth a thousand words, so for brevity sake, here is a picture showing the communication flow between all 3 parties.

Step 1 shows the client wanting to access a secure part on a website, requiring some sort of authentication. In the second step, the relying party (called a relying party since it relies on some information from the client) sends back to the client the information it is requesting (Law 2). The relying party must be a signed site (Law 4) in order for this transaction to take place, so with the identity requirements, the site also sends back information about itself, notifying the user who is actually requesting this information (Law 3). Step 3 presents the user with identities that satisfy the requirements of the Relying Party and then in Step 4 the user actually selects an identity they would like to try and send (Law 1). Steps 5 and 6 create the security token to be presented to the Relying Party and then in Step 7 the user actually approves the final token created can be sent (Law 1 again). After being accepted by the user, in step 8 the token is finally sent to the Relying Party to finish off the security transaction. Law 6 is shown in both steps 4 and 7 where the user has control both before the identity token is created and then once again after it is created and before it is sent to the Relying Party. Laws 5 and 7 were never explicitly dealt with in this diagram, but Law 5 can kind of be shown if you take into consideration the fact that not every Relying Party, or Identity Provider, would want to use the exact same type of encryption and transport type.

This is the first post of a series of posts in which I will be exploring the workings of CardSpace. When I use the term CardSpace here, I am meaning more than just the CardSpace client which ships with .NET 3.0, I am actually referring to the complete 3 party system (the Relying Party, the Identity Provider, and the Identity Selector - more on these three parts later). I had the privilege to speak on this topic at our local user group and instead of just posting my notes up to the site there (which would make it available only to members), I have decided to create some rolling blog articles instead.

This is going to be a work in progress and a learning process for me at the same time, so if you read any sections along the way and have input or corrections, please feel free to leave comments and I will update the text (as well as leave the comment in place). My goal for this series is to not only create a decent place to look when trying to get up and running with CardSpace, but also a resource to look at when trying to dive deeper into each individual aspect as well.

After playing with Visual Studio Team System for a while, the biggest draw back I have seen so far in the Developer SKU is that I can't get my unit tests to run with a build. A team build requires a test list and the only way to create a test list is through Test Manager and that is only available in the Tester SKU. Fortunately, I have Team Suite so I was able to create a test list, but the downside is that where I work, I am one of the only people with Team Suite, so every time a developer creates a new unit test, I am the lucky one who gets to add it to the list. After doing this a couple of times, I found it got old very fast, so I started to look at the vsmdi file that contains the test information and found it was a pretty simple xml file. The simplicity ended very quickly, though, when I found the Guid created for each test in the list is not just generated with Guid.NewGuid(). I did some hunting on the web to figure out how this Guid is created, but came up empty, so I decided it was time to bring out my old friend ILDasm and see what happens under the covers. For anyone interested (and I can't guarantee it will stay like this since the code was not in a publicly exposed API), the below method will generate the correct Guid for a test (where FullName is the fully qualified name of the method <Namespace>.<Class>.<Method> - since test methods never take parameters, method overloading is not an issue).

private

Guid GuidFromString()
{
   SHA1CryptoServiceProvider provider = new SHA1CryptoServiceProvider ();
   byte [] buffer1 = provider.ComputeHash( Encoding .Unicode.GetBytes(FullName));
   byte [] buffer2 = new byte [0x10];
   Array .Copy(buffer1, buffer2, 0x10);

   return new Guid (buffer2);
}

I am still in the process of creating an application that will create test lists like what is created with the Tester SKU, but I wanted to post this in case other people are struggling to find the same algorithm for their needs.