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.

Recently I switched roles where I work and we have started to use BizTalk quite extensively for our current project. We have also made the move to Team Foundation Server and VSTS and I got the great responsibility of getting our build system up and running. Now out of the box, Team Foundation Server has a great build story, but we had the requirement of being able to deploy our BizTalk application to a remote server and start the application as well. BTSTask.exe took care of 80% of that functionality by being able to add and remove an application and the resources for the application, as well as import bindings that exist within an XML file, but one thing I couldn't seem to find was how to start and stop a BizTalk application from the command line. Luckily BTSTask itself was a .NET application and since I am not afraid of ILDASM, I decided to take a look and see how BTSTask worked under the covers. One thing to warn you about is that all the documentation for the classes that are used within BTSTask (and also in the source code below) have the claim at the top stating the classes should not be used externally and are purely for internal BizTalk use. Overall, the program was pretty simple. I know there is not really any error handling or anything like that and the command line parsing probably isn't the most robust, but the command line syntax is very similar to what already exists for BTSTask and since the code is pasted below, you are more than welcome to modify it any way you would like.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.BizTalk.ExplorerOM;

namespace BizTalkApplicationManagement
{
   class Program
   {
      private static string DatabaseName = "BizTalkMgmtDb";
      private static string DatabaseServer = ".";
      private static string ApplicationName;
      private static bool Start = false;

      static void Main(string[] args)
      {
         ParseCommandLine(args);

         if (ApplicationName == null)
         {
            throw new ApplicationException("ApplicationName must be passed in");
         }

         Microsoft.BizTalk.ApplicationDeployment.Group myGroup = new Microsoft.BizTalk.ApplicationDeployment.Group();
         Application application;

         myGroup.DBName = DatabaseName;
         myGroup.DBServer = DatabaseServer;
         BtsCatalogExplorer explorer = (BtsCatalogExplorer)myGroup.CreateInstance(typeof(BtsCatalogExplorer));
         ApplicationCollection applications = explorer.Applications;
         application = applications[ApplicationName];
         if (application != null)
         {
            if (Start)
            {
               application.Start(ApplicationStartOption.StartAll);
            }
            else
            {
               application.Stop(Microsoft.BizTalk.ExplorerOM.ApplicationStopOption.StopAll);
            }
            explorer.SaveChanges();
            explorer.Refresh();
         }
         else
         {
            Console.WriteLine("{0} does not exist in database [{1}] on server [{2}]", ApplicationName, DatabaseName, DatabaseServer);
         }
      }

      static void ParseCommandLine(string[] args)
      {
         foreach (string currentParam in args)
         {
            if (currentParam.ToLower() == "start")
            {
               Start = true;
            }
            else if (currentParam.ToLower() == "stop")
            {
               Start = false;
            }
            else if (currentParam.ToLower().Contains("applicationname"))
            {
               ApplicationName = currentParam.Split(':')[1];
            }
            else if (currentParam.ToLower().Contains("server"))
            {
               DatabaseServer = currentParam.Split(':')[1];
            }
            else if (currentParam.ToLower().Contains("database"))
            {
               DatabaseName = currentParam.Split(':')[1];
            }
         }
      }
   }
}

You will need to add references to Microsoft.BizTalk.Admin.dll, Microsoft.BizTalk.ApplicationDeployment.Engine.dll, Microsoft.BizTalk.ExplorerOM.dll, and Microsoft.EnterpriseServices.dll.

From the command line, you would then start an application like so:
BizTalkApplicationManagement Start -ApplicationName:<NameOfBizTalkApplication> -Server:<Server> -Database:<BizTalkMgmtDb>

Ok, I always seem to love to change my mind on things which I think is a big reason I never really get anything done. At first I was going to install a pre-packaged blog setup on my server, then I was going to write my own (which is what the past couple of weeks has been running), and then I decided that rolling my own was a bigger undertaking than I currently have time for, so I decided to go back to a pre-packaged deal. I am finally setting on dasblog as my engine. I am hoping over time to tweak it to be an actual .NET 2.0 project, but the good news is that as I change the UI, the underlying post server will still be the same, so my links and rss feeds should stay the same.