I did a session at Tech Ed on CardSpace (formerly known as InfoCard) that illustrated several ways to integrate CardSpace into your applications. For example you can:

1. Use CardSpace to pass claims to a web application using the <object> tag or XHTML (IE 7).
2. Use CardSpace to pass claims to a WCF web service using wsHttpBinding/IssuedToken credentials, or wsFederationHttpBinding and specifying a list of claims.
3. Use CardSpace to pass claims to a WCF security token service (STS or token issuer) that in turn validates those claims and issues a token for the target WCF service. This involves specifying an alternate token issuer, and implies that that token issuer might trust the CardSpace claims to issue a proper SAML token for the target service.

I have samples for all three, and the delay in posting (sorry) is related to writing up instructions to make sure you are successful...while I was out of town last week.

UPDATED: 06/28/06 to add federation sample

InfoCardBrowser.zip (18.27 KB)

InfoCardWSHttpBinding2.zip (1.98 MB)

MediaServicesFederation.zip (2.07 MB)

Oh, I should also mention that I had lots of help from several product team members to get these samples working on the latest build on short notice - both on the WCF and CardSpace teams...these guys really rock! And you might want to head to Martin Gudgin's blog for more Q&A on the STS he let me use for the federation sample!

Let me know if you have any questions after reading the readme files!

In this session at Tech Ed in Boston last week, I discussed how you can apply Enterprise Services (COM+) and MSMQ to build scalable applications pre-WCF. The sample code that I demonstrated is listed below. Don't forget also to look at my Publications page to get more background, specifically the articles I wrote for The Server Side on security and sandboxing which discuss many of the EnterpriseServices features used.

• SimpleComponent.zip (51.19 KB) - Simple example of ServicedComponent
• SimpleQueuedComponent.zip (53.57 KB) - Simple queued component
• ASPNETSandboxing2_updatedfor2.0.zip - Fully features ASP.NET sample with serviced components, using features of COM+ including security, transactions, application configuration.

Enjoy!

Slight delay posting this, had a little trouble with the wireless in my Amsterdam hotel, and have been flying for a day to get back home!

I have resource sites related to the topic of this session, they are listed here in my post from Tech Ed San Deigo.

Thanks so much for the great feedback I received so far on this talk. I will be posting an update to my sample code in a few days, as soon as I get caught up on some seriously pressing deadlines. Right now, the code sample has everything I demonstrated with the exception of the HTTP handler that forces "Save As" download for configured resources such as XML files.

If you have other ideas for modules, handlers and SOAP extensions you are completely welcome to ask me, I may have some code lying around that I haven't cleaned up and posted yet!

Cheers!

Thank you for attending my session last evening. As I mentioned, I gave this talk previously at Tech Ed San Diego, but since then I have actually added some more code samples and discussion points that I unfortunately didn't have time to explore during the session.

My globalization resource page can be found here:
http://www.dotnetdashboard.net/sessions/globalization.aspx

Look for a new sample with a script for versioning and deployment shortly. I'll update this blog entry when it is finally there. Thanks for coming to the session!

Thanks to everyone for getting up so early (two days in a row, some of you!) to attend this session! The resources for this talk are here:

• Globalization Resource Page

The latest code is up there now!

Thanks to everyone for getting up so early to attend this session! Wow, what a turn out! The resources for this talk are here:

• HTTP Handlers Resource Page
• SOAP Extensions Resource Page

The latest code is already uploaded to the site, and more samples are bound to be there soon...

This talk started out with a bang as Don and Doug collected a list of questions from the audience that they planned to answer throughout. The best part about this was that the questions were really great. For example: When should you use .NET Remoting vs. Enterprise Services? What will happen to COM+? When does COM matter? Should we use ASMX?.

After this, they proceeded to go through exactly 3 slides. Cool bullets…

• There is only one program and it is still being written.
• Choice is an illusion.
• Objective interpretation is an oxymoron.

The question is, what do the bullets really mean? Clearly, Don and Doug are great philosophers who enjoy abstracting the meaning of technology, where have we been, where are we going, how do we get there…all that. So, I’ll give you my interpretation (which we know from the bulleted list will not be shared by everyone).

First of all, the meaning of SOA (something the masses struggle with big time) is that we need to design systems (or, services) as well encapsulated, autonomous chunks of functionality that can be consumed by other systems, across departmental, enterprise, and possibly industry boundaries. This is one big program (the matrix anyone?)…metaphorically speaking…although of course not literally. If we design systems with the expectation that we cannot control where and who consumes them, we will fit within the SOA model. Contracts for these services, once published, must remain constant…because we have no idea who is consuming them, nor when.

In a related topic of discussion regarding the definition of service interfaces, we must consider that there can be many interpretations of a service schema. For example, if an industry like ACORD (for insurance) defines what XML looks like for a certificate of insurance, does that mean all systems following that standard will interpret EVERY element of the schema in the same way? Or, might there be different (valid) renditions of this schema? For example, could an xsd:int value be delivered as an xsd:string instead and still be meaningful? Sure it can. Could a subset of the schema be used by the destination endpoint? Absolutely. Thus, by definition we need extensibility and we need to be prepared for variant interpretations. In addition, the object model behind a service will rarely look exactly like xsd-generated classes. Services must be able to interpret XML payloads in their own way, and process them according to the needs of the system. What all of these competing Web service vendor platforms can agree on is the goals of SOA and the protocols (WS*) that are required to interoperate. Proof of this of course is in my recent experience with the Web Services Interoperability Education Day. This is exciting stuff, to see emerging standards work across platforms…we will continue on our quest there.

I enjoyed the philosophy shared during the talk, but must admit that the questions asked at the beginning were so compelling that I was really looking forward to their answer. I almost think they could have done two complete presentations. One for the philosophy, another for the Q&A. So, although there wasn’t a lot of time for answers at the end, here’s a summary of what I captured:

• COM will not disappear, it will be part of hybrid solutions, and transparent to the service interface.
• Remoting is useful for crossing app domains, but not for crossing machine boundaries. Use it for fault tolerance within a process (one app domain goes down, the main process stays alive).
• Crossing machines and processes, DCOM is fastest binary protocol, and can be secured, which means EnterpriseServices (ES). This also facilitates DTC transactions. Oh, and MSMQ is integrated here so you can also guarantee message delivery.
• On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting, short term performance gains using remoting today will not position your applications for future releases (I.e., Indigo). You can expect better performance with ASMX in future as programming models change, and frankly what impacts performance most is usually bad architecture, including hardware choices and physical tier distribution. One thing that will also support performance improvement at a more granular level is also XML parsers…something the team is working on.
• How many WS* protocols do we need? Less. SOAP/XML is a great start. WS-Security is critical for end to end message integrity. We need standard protocols for interoperability, thus we need tools to assist with serialization, such as WSE 2.0.
• WSE 2.0 gives us a chance to work with WS* protocols now, while waiting for Indigo. The important thing is to realize it is taking you in the right direction. It keeps you in the game. These standards move fast, so does the WSE team. Indigo will just swallow it all making it even easier once standards are more stable.
• MTOM is the future of DIME.
• SAML will be supported, because WSE is extensible. Actually, Benjamin Mitchell and I worked on a SAML sample for our interoperability demonstration with Axis/SourceID…so we kinda already have a start on that!
• Your ES investment with COM+, MSMQ will be supported by the world of Indigo. Of course!

Rebecca Dias hung out with keynote Steve Ballmer and announced the release of WSE 2.0, the successor to 1.0 component libraries with support for OASIS WS-Security protocols in addition to several features of WS-Policy (specifically WS-SecurityPolicy) and WS-Trust/WS-SecureConversation. This is truly an attribute to .NET’s extensibility model that the WSE team can build support for emerging standards (as they emerge) through use of HTTP handlers and SOAP extensions. The WSE team has one of the fastest release cycles at Microsoft, and I expect they will continue to plung forward to support more of the WS* standards so that we can have tools at our fingertips to interact with these protocols with a lot less pain (or, WS-Pain as I call it).

NOTE: If you’re at Tech Ed, come see my talk on HTTP handlers, modules and SOAP extensions. DEV410: Inside the ASP.NET Runtime: Intercepting HTTP Requests, Wednesday 8:30am in Room 8.

This release gives developers a simple way to use Web services security protocols that enable:

• Passing security tokens
• Authenticating callers
• Ensuring message integrity
• Ensuring message confidentiality

This tool has the best support out there today for generating WS-Security and WS-Policy XML, and help you see the value of the actual standard.

Becky, can I have a WSE T-shirt now?