Problems Using Self-Issued CardSpace Cards with .NET Service Bus WSHttp Binding Sample

The .NET Services SDK (March 2009) CTP includes a reasonably complete set of samples for the .NET Service Bus (SB). Installing the CTP adds a Microsoft .NET Services SDK (March 2009 CTP) node to the Programs menu with Access Control, Scenarios, ServiceBus, Setup and Workflow sub folders.

Opening …\Service bus leads to GettingStarted and ExploringFeatures subfolders. The latter contains Bindings, Configuration, Metadata, Queues, RelayAuthentication, and Routers subfolders. Binding has folders for NetEvent, NetOneWay, NetTcp, WebHttp and WSHttp bindings. The WSHttp folder contains five sample solutions. I started with the Simple\CS35 C# sample: WSHttpRelayEchoSample.sln.

The Details of CardSpace Credentials for WSHttp Bindings Simple (WSHttpRelayEchoService)thread of 5/18/2009 in the .NET Services - Technical Discussions forum reports this problem and, as of 5/18/2009 2:30 PM PDT there’s no suggested workaround.

Update 5/19/2009: Problem Solved! (Sort of)

The problem has been resolved as due to a combination of the following:

1. An incorrect scope URI autogenerated when creating an Access Control Service credential for the solution (bug).
2. Incompatibility between the Windows CardSpace “Geneva” and original WindowsCardSpace Control Panel applets (unpublicized).

Details are in my last reply of 5/19/2009 to Li-Lun Luo in the Details of CardSpace Credentials for WSHttp Bindings Simple (WSHttpRelayEchoService)thread of 5/18/2009 in the .NET Services - Technical Discussions forum, which is quoted near the end of this post.

It’s to be noted that Vittorio Bertocci reported the following in his Claims and Cloud: Pardon our Dust post of 4/1/2009 (not an April Fools Day story):

[F]or a variety of reasons, an application that takes advantage of the Geneva Framework will not work “as is” when hosted in Windows Azure, including Microsoft products that were written to use the Geneva Framework. You may have heard that the new full trust settings we announced for Windows Azure at MIX would make the above scenario work, however that’s not the case: there is more than full trust for enabling the complete range of possibilities offered by claims based access.

There is no mention of the problem in the "Geneva" Framework Beta 2 Release Notes.

The problematic incompatibility here has nothing to do with Azure as far as I can determine. It relates to the two local Control Panel Applets and possibly to incompatibility with WCF claims components.

An unresolved question: Why haven’t more .NET developers reported problems when attempting to use of CardSpace credentials with .NET Services SDK samples after installing Geneva Beta 2? Are prospective .NET Services users avoiding CardSpace authentication/authorization?

The incompatibility bug has been reported as “Windows Cardspace "Geneva" (Beta 2) is Incompatible with Windows Cardspace (Default) Control Panel Applet” (453987) to the Microsoft Code Name "Geneva" Claims Based Access Platform Microsoft Connect forum.

The WSHttpRelayEchoSample.sln Sample

WSHttpRelayEchoSample.sln contains a Service and Client projects pair. Both services specify CardSpace as the credentialType in their App.Config files:

<configuration>
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="cardSpaceClientCredentials">
          <transportClientEndpointBehavior credentialType="CardSpace" />
        </behavior>
      </endpointBehaviors>
    </behaviors>

and

    <services>
      <!-- Application Service -->
      <service name="Microsoft.ServiceBus.Samples.EchoService">
        <endpoint name="RelayEndpoint"
                  contract="Microsoft.ServiceBus.Samples.IEchoContract"
                  binding="wsHttpRelayBinding"
                  bindingConfiguration="default" 
                  behaviorConfiguration="cardSpaceClientCredentials"
                  address="" />
      </service>
    </services>

Readme and Release Notes References to CardSpace Cards

The Readme.htm page for the solution states:

This example uses a Windows CardSpace credential that acquires tokens from the Access Control Service based on a card selected from and sent by the CardSpace identity selector; in other words, you will be prompted to pick an information card.

and

To run the sample build the solution in Visual Studio and then run the two resulting executables using an elevated privileges command line. The 'service' should obviously be started first and the 'client' second. For either program you will be prompted once for a Windows CardSpace card. The card you select must have been registered with the Microsoft .NET Services Access Control Service beforehand.

The ReleaseNotes.htm page states:

Breaking Changes

Access Control Service

The Access Control Service of this release has the following breaking changes:

…

• In the previous CTP, you could associate the same certificate or InfoCard credential with multiple solutions. In this case, one of the InfoCards was used as the default. This CTP only recognizes the default InfoCard. All other associations are removed.

…

Known Issues

Access Control Service

…

Windows CardSpace sometimes fails on Access Control Website.

• In some cases a registry entry is missing which CardSpace requires to function correctly. Check the registry for the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\InformationCard Token Provider folder. If it doesn't exist, create it. Inside folder, check for {Default} key. If it doesn't exist, create it with value: {D978F0CB-DEBA-4388-83BE-D3E106E02A4F}. Modifying the Registry can cause serious harm to your computer. Please proceed with caution.

The registry entry is present and has the required GUID value.

Bruno Terkaly’s Azure – Microsoft .NET Services- Step 01 – The Service Bus – Blog Post about Setup post includes a table of valid CredentialType values. The Description for the CloudSpace value is:

The client credential is a self-issued Windows CardSpace information card that is registered with the .NET Access Control Service. [Emphasis added.]

The table is taken from the CredentialType enum’s documentation.

Steps to Reproduce the Problem

To associate a self-issued CardSpace information card with a Service Bus solution:

1. Go to http://portal.ex.azure.microsoft.com/.

2. Click the Sign In link to open the Getting Started page.

3. Click the .NET Services solution you previously set up, oakleaf-sb for this example, to open the Solution: oakleaf-sb page.

4. Click the Solution Credentials link to open the Credentials Management page, which reports “There are no Information Cards associated with this Solution.”

5. Click the Select a Card button to open the Add a Card page which proposes to add the default card without identifying it. This indicates that you have an existing card that might not be appropriate for associating with the solution.

6. To eliminate the existing associated card(s), open Control Panel’s Windows CardSpace[“Geneva”] applet, select an existing card and click the Delete Card link (for each card), and close the applet. (Deleting a card doesn’t remove it from other solutions.) I created these cards when testing Access Control Services federation:

7. Return to the Credentials Management page. (If you click the Select a Card button, you receive a “No matching cards found” dialog; click cancel.)

8. Open the WSHttpRelayEchoSample.sln solution in VS 2008 and press F5 to build and run the solution and open the Service console with a “Please enter the solution name to use with this sample:” prompt.

9. Type the solution name (oakleaf-sb for this example) and press Enter to open the Windows CardSpace dialog.

10. If cards are present, click the Back Up Cards link and save the cards to a file, then click the Delete All Cards link so you can add a new default card.

11. Click the Add a Card button, then click the Personal Card link.

12. Give the card a name, such as oakleaf_sb for this example (Hyphens aren’t permitted in CardSpace names), and click Send to close the dialog. The solution will throw a timeout exception on the Main() method’s host.Open() instruction.

13. Shut down and restart the instance, repeat step 9 to open the Choose a Card dialog.

14. Select the card you added in steps 10 through 12 and click Send.

15. You receive the following exception at the host.Open() instruction:

Preliminary Analysis

It appears that the applies-to-address claim, which seems to be a custom claim type, is missing from the personal (self-issued) CardSpace file.

The question is “What’s the workaround?”

Here’s the full text of my last entry as of 5/19/2009 11:00 AM PDT to the Details of CardSpace Credentials for WSHttp Bindings Simple (WSHttpRelayEchoService) thread of 5/18/2009 in the .NET Services - Technical Discussions forum, which reported this problem:

Yi-Lun:

I found the problem, which appears to be a bug:

The auto-added scope http://echoservice is invalid.

Changing the scope to the full DNS http://oakleaf-sb.servicebus.windows.net/EchoService/ and selecting the card works as expected for Serivice and Client projects.

Adding the scope also works as expected.

Updating blog accordingly after testing on Vista with Geneva Beta 2 installed.

“applies-to-address" is a rather confusing synonym for scope, is it not.

Update: Removed Geneva Beta 2 from Vista SP1 machine. Had to remove and recreate the association in the Credentials window to get the above fix to work.

Cheers,

--rj

Technorati Tags: .NET Services,.NET Services SDK,Service Bus,ServiceBus,.NET ServiceBus,CardSpace,CardSpace Geneva,WsHttpRelayBinding,Windows Azure