xmldap

Snowboarding at Baldface 2008

2008-02-15T22:47:00.001-08:00

Meet Dottie

2008-01-16T13:30:00.000-08:00

Dorothy Mae Murphy Mortimore was born on Jan 14th at 6:06. At 9 lb. 1 oz. and 21", she gave us a little fright, when she refused to be pushed out. After a grueling 24 hours of labor, Dottie joined us via c-section. Mom and baby are happy and healthy.

Check out pictures and news at http://babymortimore.com

Baby Pictures

2007-09-29T18:43:00.000-07:00

Mara and I had a 3D ultrasound for our 5th Anniversary. The technology is pretty insane.

Click here for the full slide show!

Identity Deployment of the Year

2007-09-25T09:58:00.001-07:00

Rearden Commerce just won the Liberty Alliance's Identity Deployment of the Year!

I just accepted the award at Digital Identity World 2007, and will be speaking there on a panel at 11:30.

Speaking of panels, Rearden has been invited to speak at a couple panels on online platforms recently (office 2.0 and webguild). Joining the likes of Google, Yahoo, Salesforce, and WebEx, I sat on 2 panels and debated the composition of these emerging development environments. You can check out the webguild video here.

If you're interested in online platforms, than come help us build ours!

$5000.00 cash

2007-03-05T09:33:00.000-08:00

The startup I work at, Rearden Commerce, is in the midst of a major growth spurt. We've recently become the technology platform for American Express Business Travel, and were selected as one of Business 2.0's Next Net 25.

With that in mind, we're hiring like crazy. I'm looking for Product Managers to work on our Developer Network, our Administrative Consoles, and our Platform Services. We also need top engineering and engineer management talent.

So drop me a line and come join Rearden Commerce...or send us your friends. To help sweeten the deal, we're currently paying a $5000.00 referral bonus to anyone that refers Engineering Directors & Managers, Sr Engineers, Product Managers, or a Director of Merchant Network (BizDev). All other positions pay $1000.00 cash.

Send me those resumes!

Snowboarding at Baldface

2007-03-05T09:27:00.000-08:00

Finally have the video from our annual trip to Baldface Lodge online:

http://xmldap.org/BaldFace.mov ~99MB

http://xmldap.org/BaldFace-medium.mov ~37MB

http://xmldap.org/BaldFace-small.mov ~13MB

We're already signed up for next year - drop me a line if you're interested!

Need a new Identity?

2007-02-09T16:33:00.000-08:00

My wife Mara would be happy to help you out. She just started a new letterpress and design business called Dutch Door Press.

If you need business cards, invites, cards, stationary or anything you can think of, they can help design and print it.

Check them out on the web: http://www.dutchdoorpress.com

xmldap as a plugin to perpetual motion

2006-12-17T20:30:00.000-08:00

Kevin Miller's new Firefox plugin wraps the native Windows CardSpace identity selector, and in the process provides a great card parsing implementation. Since Kevin was kind enough to implement a plugin framework, I figured I'd take advantage and added plugin support to the xmldap selector.

If you pick up the latest version of the plugin (requires Java 1.5 on your system) you will now find a new Identity Selector option in your preferences. If you have both Kevin and my extension installed, and you're on Windows, you can now flip back and forth between the CardSpace selector, and the xmldap selector at will.

The great news is that people implementing selectors will no longer need to worry about augmenting the browser. Now hopefully we can all quickly agree on a preferences structure to allow any implementation to easily add itself to the list.

If you're interested in writing you're own plugin, it's pretty simple...here's the basics of an XPCOM component that implements the plugin interface:

http://openinfocard.googlecode.com/svn/trunk/firefox/components/Identityselector.js

have fun!

Another Firefox Cardspace Extension

2006-12-12T15:02:00.000-08:00

Check out this cool extension for Firefox by Kevin Miller

http://www.perpetual-motion.com/

It basically wraps the native CardSpace implementation on Windows so you can use it from Firefox. Very robust looking parsing card detection, and the ability to implement an XPCOM interface to plugin other selectors:

IIdentitySelector..GetBrowserToken(issuer , recipientURL, requiredClaims ,data.optionalClaims , tokenType, privacyPolicy, privacyPolicyVersion , serverCert );

The selector implementation can be determined by the user's preferences, so it should be very simple to adapt the xmldap selector or other cross platform implementations to this model and let user's choose their selector.

Nice work Kevin!

Combining CardSpace and OpenID

2006-12-06T23:00:00.000-08:00

At IIW I demo'd a little proof-of-concept showing the ability to login to a CardSpace relying-party, using an OpenID based identity. For those who didn't get a chance to see it, I provided a little screen cast here:

How-To Decrypt a CardSpace backup file

2006-12-06T20:36:00.000-08:00

Having posted a utility that decrypts CardSpace backup files, I thought I'd take a moment to explain how it works. The backup file format is rather obscure, so hopefully this should help serve as a guide to people looking to import and export cards with non-Windows selectors.

The first thing to do is take a look at the CardSpace backup file format (edited for brevity):

<?xml version="1.0" encoding="utf-8"?>
<EncryptedStore xmlns="http://schemas.xmlsoap.org/ws/2005/05/identity">
<StoreSalt>3BprRlJ6LpWvvLvuGS6hXQ==</StoreSalt>
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#">
<CipherData>
<CipherValue>...Base64 Encoded Ciphertext...</CipherValue>
</CipherData>
</EncryptedData>
</EncryptedStore>

Here we have the file format. There are really just two things we care about...the Salt, and the CipherValue. The first thing to do is extract these 2 values.

At this point, it's probably good to get an overview of what you'll be doing. The ciphertext is actually a 16 byte Initialization Vector, 32 bytes of signature data for validating integrity, and then a CardSpace RoamingStore xml document encrypted using a PBE. Specifically, it's a PKCS5v1 derived key and AES with CBC.

As you get started, one thing to be aware of is the byte order mark. Regardless of what it claims, this xml in this file is actually encoded using UTF-16LE. So...it's prefixed with 3 bytes of data. Here's what you should expect for the byte order mark:

byte[] bom = {(byte)0xEF, (byte)0xBB, (byte)0xBF};

You'll also want to know about a couple pieces of static entropy used in the algorithm:

byte[] encKeyEntropy = { (byte)0xd9, (byte)0x59, (byte)0x7b, (byte)0x26, (byte)0x1e, (byte)0xd8, (byte)0xb3, (byte)0x44, (byte)0x93, (byte)0x23, (byte)0xb3, (byte)0x96, (byte)0x85, (byte)0xde, (byte)0x95, (byte)0xfc };

byte[] integrityKeyEntropy = {(byte)0xc4, (byte)0x01, (byte)0x7b, (byte)0xf1, (byte)0x6b, (byte)0xad, (byte)0x2f, (byte)0x42, (byte)0xaf, (byte)0xf4, (byte)0x97, (byte)0x7d, (byte)0x4, (byte)0x68, (byte)0x3, (byte)0xdb};

So - back to business. Once you've extracted the salt and the ciphertext, you can begin to decrypt the backup file. Here are the steps you'll want to take:

Remove the Byte Order Mark, and parse the XML file, extracting the Salt, and the CipherText
Base64 decode the salt, and set it aside
Base64 decode the ciphertext
Copy the first 16 bytes of the ciphertext, and set it aside as your IV
Copy the next 32 bytes of the ciphertext, and set it aside as your integrity check
Concatenate the remaining bytes together with the IV. ( IV + remaining bytes ) Set this aside as your data
Derive your keys using PKCS5v1. Take the bytes of the user's password used to encrypt the data, and concatenate it with the salt bytes. Take a SHA256 hash of those bytes, and then SHA256 hash the output another 999 times.
Generate the encryption key by concatenating the static encryption entropy together with the derived key. Generate a SHA256 byte hash of these bytes, and that is your encryption key
Generate the integrity key by concatenating the static entrgrity entropy together with the derived key. Generate a SHA256 byte hash of these bytes, and that is your integrity key
Decrypt the data using AES/CBC/OAEP with the encryption key you generated
Remove the byte order mark, and you have the decrypted RoamingStore.

So - that's the basics of decryption. If you'd like to encrypt a store, you simply perform that process in reverse.

Next, you'll want to validate the integrity of the data. Here's how:

Concatenate the IV, the integrity check data ( bytes 12-48 that you set aside earlier), and the last block of data (the last 16 bytes)
Sha 256 hash this, and you have the computed integrity check. Compare your computed value to the integrity check...if they match byte for byte, you're in luck.

That's it. Be wary of character encoding, but if you follow these steps, you should be able to encrypt/decrypt backup files

CardSpace Backup viewer

2006-11-24T15:33:00.000-08:00

Ever wonder what's inside a CardSpace backup file? Now that the xmldap.org codebase can decrypt the backup files, I thought I'd add a quick tool that allows you to peek inside. Here's a little web app which will decrypt your backup file and return the xml inside:

http://xmldap.org/sts/decrypt

And here's a screencast of how it works:

Minor Bug Fixes

2006-11-21T09:55:00.000-08:00

I updated the Firefox Selector to fix a few minor bugs introduced in the Managed Cards support update.

Thanks to Axel and to Antoine Galland from Gemalto for trying it out and reporting the bugs.

http://xmldap.org

Managed Card Support for Firefox

2006-11-19T23:44:00.000-08:00

One more important update for the Firefox selector - With this new release, I've added a simple proof-of-concept around Managed Cards.

The Firefox selector now supports importing managed cards, and retrieving tokens from an STS. It only has support for Username/Password authentication over the simple TransportBinding (this means transport security rather than message level security) Also, I've only tested against the xmldap.org STS...it may work against other implementations, but I haven't yet focused on interop.

That being said, this now demonstrates a complete end-to-end exchange without any Microsoft components. An opensource STS issuing a token to an opensource Relying Party, via an opensource selector...all on a Mac.

Here's a screencast of how it works:

As always, the selector and source are available at http://xmldap.org

Firefox Plugin Updated

2006-11-18T20:42:00.000-08:00

Thanks to the hard work of Axel Nennker and his friends, I've posted an update to the Firefox Selector. The selector now has these great features:

1) Support for Firefox 2.0 - the plugin should now work on 1.5+ and 2.0

2) Internationalization Support - Axel added i18n, and has localized to:

English
German
French
Norwegian
Swedish
Turkish
Czech
Arabic
and Chinese

3) There's also initial support for Logotype certificates, so that a website's icon embedded in a certificate can be displayed to the user as part of the verification process

You can download the latest plugin at http://xmldap.org/

Thanks Axel!

STS is finally working

2006-11-06T01:31:00.000-08:00

I finally checked in a working copy of the xmldap Security Token Service. It's a simple STS, which only supports the Transport Binding of CardSpace, but it's enough to see managed cards in action.

If you'd like to try it out, go to https://xmldap.org/relyingparty/ There you'll find a link to where you can create managed cards. You'll then be able to install them into CardSpace and use them to login to the Relying Party. Below is a screencast which demos the basic steps you should follow:

Here's a screencast demoing what you should see.

As always, it's open source. The code is pretty messy at the moment, but if you're curious you can take a look at http://xmldap.org. Special thanks to the other contributors, and the folks at Arcot who figured out one of the missing pieces.

back online

2006-09-19T13:08:00.000-07:00

Thanks to Ian, Ebe, and a new router, xmldap.org is back online.

Kim - you owe us $65.00 :-)

identityblog effect

2006-09-19T11:42:00.000-07:00

Looks like Kim's two new posts have melted my server. He's the slashdot of the Identity world.

Sorry - the crack sys-admin team has been deployed. Hopefully we're back up soon!

The Missing Infocard Schema

2006-09-17T16:20:00.000-07:00

The Infocard Schema has been notoriously missing since Microsoft published RC1.

Here's the schema for the http://schemas.xmlsoap.org/ws/2005/05/identity namespace

Playing with Managed Cards

2006-09-17T16:10:00.000-07:00

I've just checked in code that can create Managed Cards that import into CardSpace RC1.

To allow people to play around, I've also added a quick little web app, which creates cards for you. You can try this out at:

https://xmldap.org/sts/cardmanager

Here's a screencast of what you can expect.

If you'd like to try it out, you can either download the source from http://xmldap.org

Relying Party updated to support RC1

2006-09-17T12:03:00.000-07:00

I finally got around to updating the Relying Party to support Cardspace RC1.

Enjoy: https://xmldap.org/relyingparty

Instructions for the CardSpace FirefFox Extention

2006-09-16T23:17:00.000-07:00

It sounds like Craig Burton has been having trouble with the demo Cardspace Selector I put together for Firefox. I'm not sure what trouble he's been having, but I thought I'd toss up some quick instructions, and a screen cast.

Step 1) Make sure you're on Firefox 1.5 or greater.

Step 2) Make sure you've got J2SE 1.4x installed on your machine. The xmldap selector doesn't use any .net or Microsoft code...its a cross platform implementation written from scratch in Java. You can hit http://java.sun.com if you need to download a JDK

Step 3) Go to http://xmldap.org and download the Firefox extension. You may need to allow the popup blocker to trust my site. Restart firefox.

Step 4) Go to a Cardspace enabled site like xmldap, identityblog, or ping

Step 5) Click to login, create a card, and submit.

Note that you'll still get a warning saying: "Additional plugins are required to display all the media on this page" Ignore it...I haven't figured out how to make it go away yet. Please email me or comment if you know!

Here's a screencast demoing what you should see.

Craig and others - email me at cmort at xmldap.org if you have questions or issues!

Identity Selector for Safari

2006-09-12T17:32:00.000-07:00

My good friend Ian Brown has taken the xmldap.org code and created an Identity Selector for Safari. It even integrates with the Apple Address Book for self-asserted cards. If you've got a Mac, check it out...if not, he's got a screen-cast.

Nice work Ian!

6 screws and a plate!

2006-08-27T15:11:00.000-07:00

6 screws and a plate!
Originally uploaded by Phil Hunt.

Phil Hunt from Oracle(OctetString), ~~Ian Brown of SOA (BlueTitan)~~ Phillip Kamps (yet another ex-sxipster), myself, and Phil's wife Wendy rode thigh deep powder at Whistler this year.

In a mad dash to the bottom to meet up with Mara, this happened to Wendy's knee.

She literally just laughed it off.

Update - My memory is off - it was Phillip instead of Ian. As Ian comments we was out with his own knee injury...which was my fault. Sorry Ian.

Catalyst 2006

2006-08-27T15:04:00.000-07:00

mortimore, huang, shewchuk

xmldap.org back online

2006-08-26T15:43:00.000-07:00

Thanks to my friends at SOA Software, xmldap.org is back online.

There are a few new things as well:

The homepage has a new look, as well as a bunch of handy links: http://xmldap.org
The Relying Party has been updated to work with the latest CardSpace release.
The FireFox Identity Selector has been updated to get it working with the latest versions of Kim's blog and Ashish/Ping's demo site.
The selector also has a number of updates from Axel Nennker to support images for cards, and required fields in cards. Thanks Axel!
Axel also just came through with support for optionalClaims. Thanks again!

Burnin' Down the House

2006-06-15T14:31:00.000-07:00

"Chuck...this is Mark...apparently the house is on fire"

Everyone is ok, and the damage is minimal.

Slide show here

Identity Vocabulary Comparison

2006-06-15T12:22:00.000-07:00

Here's a nice new overview of schemas across various identity systems by Johannes

Get it here

Discuss it here

Microsoft Labs STS

2006-06-07T10:24:00.000-07:00

This was briefly available a few weeks ago...looks like it's live again:

http://sts.labs.live.com/

Haven't tried it yet myself, but it looks interesting.

Even better than the dolphins

2006-05-11T21:05:00.000-07:00

This article about dolphins referring to each other by name has been making the rounds in the identity world.

The monkeys are still more human.

I completely agree...

2006-05-11T20:08:00.000-07:00

...with Johannes' latest post.

It's too bad rdf is so difficult for people to work with (or even grok)...the simple injection of a predicate into the name/value pair and you'd retain the ability to serialize complex object graphs.

Firefox Identity Selector

2006-05-01T00:32:00.000-07:00

I've just posted a prototype identity selector for firefox, which allows you to login to infocard enabled sites, without infocard, or even windows.

You can download it here: http://xmldap.org/xmldap.xpi

In order to get started, download and install the extension, and then browse over to one of the public relying parties. It also requires that you have a JVM installed, which you can pick up from java.com if need be.

Please note that this is of alpha quality. It only supports Self Asserted tokens, and many other desireable features have not been implemented. However, it should provide the based for some interesting discussions at IIW this week.

Enjoy, and please send feedback.

[Update: There seems to be a small bug with selecting cards. If you click on a card to select it, and its values do not fill in on the right side of the screen, then click it again until they do. If you attempt to submit with blank values it won't work]

[Update: Also - keep in mind that I haven't figured out how to make the Firefox warning that a plugin to handle the infocard object isn't installed. Simply ignore this, and please send me a note if you know how to make this go away]

Mara's on Flickr

2006-04-19T20:51:00.000-07:00

Check out our pics from NYC

Or subscribe to her ATOM feed

Interesting code block...

2006-04-19T20:38:00.000-07:00

Here's an interesting block of code for displaying Certificates I found while poking around Firefox this evening...


mapIssuerOrganization: function(name) {
    
    if (!name) return null;

    if (name == "RSA Data Security, Inc.") 
                        return "Verisign, Inc.";

    // No mapping required
    return name;
}

Another Java RP

2006-04-10T17:47:00.000-07:00

This time from Ashish at Ping:
https://infocard.pingidentity.com/infocard-sp/

Nice Work!

Finally...a Windows VM for the Mac

2006-04-09T18:27:00.000-07:00

I've got to say, Parallel's workstation rocks. I'ts jsut like VMWare except it runs on OSX. Despite the occasional kernel panic (it's still in beta), I can now play with InfoCard without leaving my Mac. XP is super fast, and my friends at Sun will be glad to know that Solaris x86 is supported.

Here's some screen shots of InfoCard running in a VM (click for bigger shots):

Here, I'm prompting for an InfoCard

InfoCard displays some information about my RP, and asks if I want to send a card.

Since this is my first time using InfoCard, it asks if I'd like to create a card, or perhaps import some existing cards.

Here, I'm creating a new self-asserted card.

InfoCard confirms that I want to send my new card.

And I'm logged into my RP.

How to consume tokens from Infocard

2006-03-31T11:05:00.000-08:00

So - if you’ve been wondering how my RP works...here’s an overview. I’m not going to cover declaring Policy or anything, as Mike Jones’ paper seems to have covered it in pretty good detail. I’m assuming here you can get InfoCard to invoke and POST a token.

To get started, you need to get your hands on the XML Token. This should be pretty simple, as your web framework will generally hand back parameters already URL decoded.

Once you’ve got the token, you’ll need to decrypt the token. The token is transmitted as encrypted XML, and will look something like this:


<enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
                   Type="http://www.w3.org/2001/04/xmlenc#Element">
    <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
    <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
        <enc:EncryptedKey>
            <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
                <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            </enc:EncryptionMethod>
            <dsig:KeyInfo>
                <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                    <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">zHXxYr8jTDe/UhznC81ixsQXSpI=</wsse:KeyIdentifier>
                </wsse:SecurityTokenReference>
            </dsig:KeyInfo>
            <enc:CipherData>
                <enc:CipherValue>hgBNzEXXnoLNu6DPhXJanirEPOK/ey53RKISJrwvRhQazPBgqcnZPaxNVqZf6TOR1VbryCU6fbGw
        jIuuXzTb5Z+0PsRPM4N8CLSBxYxN1BFCNnhW67qJ4zrw72OTIkkTLWvPDpJpAak6X6RGFteaf3zD
        uVYU4Ta0sDmMD6lxgjs=</enc:CipherValue>
            </enc:CipherData>
        </enc:EncryptedKey>
    </dsig:KeyInfo>
    <enc:CipherData>
        <enc:CipherValue>qCiqGzgr9JKl8hQXKBkZ7d+CIDmppKGTQgTYCjgT1/jR/0A4uj7gxLtERM09OACzC3oXGHn7o/9qk8J2seWp2gZdQSWcnEavbgGOYDARGi7Vu5jsBrav5m1d4HrpKD2H1uCgB8xNR6eHKoPrsCGN9x9chWph244dD3HlXMXj90OSFSt+/y1oy6DWQV8EC94C4mbUH9udNc2cp90n2MCdHIF+jmjGrDQHVL4AHIYEFbH8b5rIHrW/oFlztcVhon1vOTQ4u3AO6jPINvcZK92greuWMdoyc2Lhx2/G4xNjhRpGdyfFOSHStOCv1xA0mZSvnn9bTMT3khMjPKL5KWdwTduKghMJsoZLFC6M2b2HHM9KdihvF2qPMXMsk8ZOf4dmL76bTzOsfC0yTtasY6L4lLnq9jdOE9NVnxk3KiUtE3ckrwdsKTTP/7VqrXcfdL0NAT04KF30D3Gb3sjm5kebO28fFjC61bMGOd+9KiQUxZ3WO/Tsjiw2FauPJ2lELLQGiUzsvxQ168KBvqvvyBNrDdEYg/XEGnnqBvslV5zGYceV5ptPP8oNJe0ehuzjuN4EPe2RNuOsdXT3I9xp8vetEIFZ0oUw8Vvvocl7AbY8EwHGaHEN37PAzwISLjmm3PZxj5KqLWCo29nvcWWYT7zg154TrgjuU8SeKA3JtYif0Mjoh/OdBuKRjlcAX+a3NYeqBbag80pau7Yd+c6Vm3oQvqJEiA6ofay3kZL1xyhYFKo9CUxd5TfVUFFqSNCx6uUr6bVyYsU4C2TxpF5bl3mVCFqNtlG9QI1nr89zQgSfvbiTE31snHq++RU7xY2yZp8wiTOS4T560oqFKWf5PR9QjjSZh68tKzIM7aZeI3pV3v2wDVoIjkY8SL408xBfIeAW8K5Ea9/b2l7FSnMJ8Hr85EsfREV++odQWYN2iFlFUvMqPYGmCNVoV1/IE19oVdm1ekJK/JQbd3D4VLyiXezCL4a1a5wpOXlznpuYBDVo3IeQI38pl2NYSBWLqYxbDCmriEceKFSDKOr+ByRQgcOmtvE95EW3j1xudIHrzeOorY1RSGuQtXDaey7Ic5cQS3IpjAHM8cPjDMP/T3fXaoY887oruSD6xQtAcvHN21D+nI4V/d7Ze+JRBsuGIcEmkvmF0sdeVQt9GADEbTo4btnrls8JaSfnTePIXZ1V164oUzr+wRU66zV7AL0uk/2poZPps2DtGV+S/u7Mm8bZihs7I4WqqWu5b7wFQ2TKReFD92XJu8gmxVdoQIivFKGNrBPt9Q20FAEnW97LbKhotL/Sy0tD8cVvgmEyK2CYsrqLYAtOv647hA3tcGYKWLoZ6Vmxdd/BVl7UxNiTfnImX/83MVuV0SetKnRRnROnJoGDHFGXWnPKIU9WHezA89xKvwTen9dg1g2YgsM7H6K46yQzREx0evvt0Ax2j6tmRulGuhvckGTl0szZVBK0DSK+fHgJqf4jaN/RooFG4IkdKhaxHuILlA7137JahdhoWPlv2amaCKB8S+FyFPX/C59zXY/fQZw+3g5joMdbWt/M6NL1zgJlPzrEqUTo/t94m1j8qllh0k2TuPtdtLdkJQHxYg/e0NZgLgH/czbUPdG3dR+dAqxFaCcyfcy040vLCqGw9cpcz5iyGGh953ALFoCRGDRQuaghb1zO3eqI/ZxC0C9hv6M/nOF7pyH4mqUl3B+ctvk0yxQwhcoAS5CXi3C0LmryhMQevYfyVbJMMOHlxBmaYq1JAPwUTcEGGCQhfgo6uVgpoe2KAgGhV43GCRxk2tjuXFsYR1byy08bCFfTqXIYCLKRFvoElbbk6toubndS9XuiH8C3fVX21A0Ck6zZF9GoZzYkczuLYQZF+3FZw41KOV7/S7ASVIgAVQPeR5aLggJ2eeFdTFNYAJhZUq6exWfns3o7S2UAgF7qNGj/TIJGLZmZVElsAqWLpQGZskoeFCceNibEeWp+4YqIkz8r3MGedWYfuOfSHF8W/LoYR6Pgwh9Bt1Acx1LG2aALtmh/LgzjCGatxy3QwOXj0k+ghzFiQOzXJuLOYyKXVWnMI9kxJGZA5dLASD4np6/Yy4LMFZdJ6Q7o/5E68Bv6VXLMfhsdIXJwxVvHNgomIez/nwNc52edUkPT8AP2mRpmE9pDNOw4o/KZAhwn4e4lEfkIhZmN/Xn+SBRCEId3CrJM749WJpvd30T9Is5PcCZ3yQ+QIPBmizaOSIfkT2XshTZ99FNxzQlx7mdz6wv8bGIO+Ox9rcvP4zbN+6QWta9lvRdtW+0mA6ms8M19vCecc4EmlxLO/hhYj5gGZYGCswVgHmKQabzOeOzXbn1xF+kOm4j1bWz1/yBwvduCK2Qtv8RYYBKfhKcx7zR9fiRkzAeqqOrEQ/AxXM0cXVmTWb01TKs+vrPkEKzT+DulwAO9RVNFs+7sOAzVC50YCCuPjMLu2D52NCw4IMAed5eSmT5wZ74XHAg+Lzbz6WspTfeabDthchP99IeRHgb1ybyCxUXfeBMocG6HAEhCgDg/oGGe/99aLvE7jGbgbZrbdALJOd32/oGWtMeecft5lomAI/vGjAcrcOpIgUKKE+ANFShGTsk3LJ5qw/juL44a5kOf1rZUMZHiAUKQzW6iOsYDRiYnYzC1HAtpHjGO++i90FYsHLyoxrq4aRNdgptIoa92D+5qPQLVCSPAX4/lEkQ6YECt9jmDhFWPGfp7Hql959h35vZCHEwvZi6i8ATQIgiVaXX9TNdZNUaFQaDy6g+6Hqxb9qsTDQfJ9JkeEkPrgxjFMlIC4iAkBQHajBtPVq51V4r6klbqnKNdTshJnVwwQ688bGg+ccIojmKQmyNlV2Ws/3VGyVfQd7JAQv0qcThGltEig0RVwPYeS+PMxuCup2A1hws+qEGdUUSkvF/xs48+SW91xjoqxEDDEyVobx/Zrnnn53PDM6TGDqMgMyZ5WYVW3jvzqY6watMdTwHXUHzS9OvjxxN3qdQfdp7EDF6hkCitWyG8NWsDR6Aam/V2dxa3E8JjjSc1Ja4PUB7g8jiHonzyVvEvKQ5NZ325L4pPBcEUdbtpyfVsb5AsofEkvibc3AwRyBxxtdunhnNB04CZAFQlcYJygAdaZ7hafuqaey+vRFJl3DRNDX71mzsPyexBzxug0uBeX4HlmpQqi6HSemRLeLAx/7DBJ1EFbAqu0zv2uas8rknok19xU0+wHOeHcWGNUPfjJfCc1RdkJ425JT+1VVXgpThJk5l0OjK737ZEw0/ITUMUv0KbhwJX1cGLacCfEWPIDeubDzkHpNpYqzBj1WPV1Nc2YjX7jFvhoomYeE/ihJA08JsXIAXlX/GkDRJL164x1DMy8pUtzzrDPhIUlT/8XJCRSUa2lQ4lms4WrMxh3aFKHBTLQS6RAK2QlBYdWMSCNz3oytVqLxqf/KkGrhjqJajylYxFS3ktia3j0k5PpH+gpNEuiQL3F2zSfT9vn8nOLQDhfyF7kVuW1AN/paxknCYL7TCJuqK9DNAQyW7hQ7Ij/3NRvIZ+ztFYWj2wziGqjvNXzRhUNi/z+qAeBPNpwzGTRYQoGSoucjorpiEDj2nrKAnxIwwC+i4CWr1A1fLY6e2obpxN5J7D7lcSuXvvF/GqEXEkqZJc8V5zj9ct3ISqG/hEJ9kdnAjeqFkK35/ZlKlfVFbcomBYFWucUC8DPA6a54RIOJK37GNLNahhRh8tgKU2KSknUpejqdF9Jlz5K4ndUrPTqmRzv8ROiMU6WNKtUsEFGOMtdQpb1t13iX/gadVdBbmr4opaIpPhEctuaPx6S0a+e7jJarvQRl6DhTysjnlw56sK3QImHGuJ2726Lh8+6UymbtdizBIJ8fsj5EI5a0FpaBHe1EmJ05p3SmVnW8Gieccevbg4Tp9LRLQEobBT+AzlLbEuIBWxj8tVKegbXlt1ndefuxbzfmgwE3vno0A31tbKEagO/j6zzcSLmdHjG/Csti6QHM8BIX/Bld/W4m9rk0FBvyoiM91pxZSoU0LngVJC+EIKL/OcMzehyEwdbR6f6E8LjDQBBmdFC9VLcpr2ao0YeMGPRdD0ldPAj1IU+l0d473qc6f1ZzQ0lw7JHkwOoHebqQQgZtg+gyy1ejKRIVi55wfshHssKBujAvdV3MM9yKgbXXunO0gSEX/clk74lx3qQR9WNOsbX5B2Ex0UmEXRFTFl5n86annC9QRWtj/IpTNjbktXzxrxAbg0ePp3i59z994+hjp0Oq83rAnT06R1GYI3I9G+KYjtDz0cPZ4c0P8gsETxmW4AjSsGbxGGwxSXoUsut86ENWtpsCIYwsc/BX3UNe4/PjLuzC9InJb93e8C8fB/rdiUpBOco9U0e1AS1fAMBhwhJOOnMZlTZa0R1mJyCarWtvLcMTrO9uWXS/s9NvdGLHRgrW1yMyNmXLEZsDoejl0IsiOx2lzwoyNd+m5G0LOGdHa9uFvlPwYnZ579h3fvWSR5yyV9YZwBD8Zvk3kGPcJd8ybz3Dw21lpHXEsWEReS3kkq+doQE60sv4gXhLGFHZAOClbFKNLcXuW1UX2QE+sjPjn3NsucEE4FQDsMBEQbdZnlFR6rsKAM+ePGJlBn7I9DDMZQpOIZhVkXF6y2q1n9qGvN/HTb3xplWjR/RXFKKqiaShktHdBnPIOmJnXRIvE8EJpq0tMd088QHmbGENDyq0HDgv1nmKfQq+xoyuEOy88gayUdxo8cvoJ6gcrSYLZVr0x3njwSZVgRrmhWsmV29uyEbOYIrIs8o0QlHWZ8m7jO04zbPY34q4otbNq+Qq3jrYwPc/+Opx940ehRKz/+/AePjjSMmbokHDV+hv40HWn4ACWluF8AzQF81H1HNKgIbuK6HZq8j0TEHbBwWDByPuMf6GkwV9gBKuuiNHy9VQiTssuz4dx6Qs0eqEDTJ0bsd30Z+jk9DtxC6f19YJhEv9Ait/SahUt0vjS+8lxuIWUWnz4fy7NTqRWhukVwe97rrZxyosZSsQjPkzSFOA9FAhOaSFVsP+dZeJv4tqmsWMtZ4mmtSQaz62VFGd6NuSwtk2giaZIzW+EcK6qRYjFOiGmZtZpTClqp3h4VpioTGZxLu8vEx91vE0Ew1H8W9YhNW2bEFajK1Vhimx6HkFn8Yy/WpFh28S4peDWIu25DiotDhSJE0iiqz228nk4xHK4kmzWqwVsrhoIo1m+SjNajFfdMVXWZHD3emsS2ZEGa96c/BuxyreGryvQhqz9TQG2Tqw/XXrK+jSYHe734jQ4jTAAfhu0MxBFeiHJJo5robDePuKid/Vh1hvb0uVKKmdc7wNqGXHjP3qM/uyrJJ4tJSBknd0YKc0kTTxeDmJY1pj8yX2gk5SuqhhEBssaJp2bS9lYucYiVM4IrZ4+osVdF/iIxt/5sIQPmPmiaKlkV5Guq7hjOldchCNsanpP2MluTuoptmjXgwfR3lsDokcrva9mKvaaIzofziGFffsYLlBv9t0YS5ZUtW064aa4Z9qGLTXEzmZjvwEU51sSLc371m2U6LLxoT1vSJPtV0idtzR6Q9ezzHeSuaRctGbbVOUyCfd1CL60PlNmTlrUSTavfldGxuGdT/7+WkozgfI+AUih9G1uA1999dGWOy/LBg+Znvb53O5sgrENYiV5OIfVGG7k008I34mkIv6NixpOz8/qixcvFYfl18LvAQSEYFuNaKZfp3WvrJRpxPIZiYx0240G/EjdfKmZLrrPF/zijyW1IjQhwo+xg3n/0BL5MbCFoXztncWX8tVfOW/HEH+m3oAj3eCz83K00vDNqGpGlfxF4f3KGYR7oGglhcMAAnYd0xhggXlMBpDVDv5pLHZCx+CWfNmX7ZCBsVeDmTZgUmq76L5cn4yrhFjm4PypSsO4H1n/lgymZhx1ydb4ZD2tYOzoxEYyJfkEP4h07fJBLi/hp98PCL7Da4mIq81u+7y4jNs3WHO//nmbEBg3LisgmZHrBVI0OUphmNpM+eU5FM1F8eo3za5I3fymPPjOymrsO7fEvdhSLqBbwTqzNAhzw8/vx4I7e9rG7emnvU/3cQAcKd3J5RCChjf0ofWgzmU5bGKYyNHU1IZvhC+Z2kk7TINQyYas3E9uYrZjGS9pF8ppkdc8UdLJaapnPN1h7+DybO2QYQ2hTzU88+sUASUtv/LWFFq0isKjfqDW9XYj4FaIDuGZ6A1Fswy6QYHaeaRi8GCdtT4C8LyCmVkadWNlbcloZPosI8q/qTG9NigEA1p7j7ahAzeZhBUPuCX7vhvFoGg6Ie9wE754X57BvYKqcFbO2WPoDfEir0ibQpS+2uAu7tXdiWEqTId8Fv7JnSs9thx+M1ZYJHe1n1xDdX2FngsWTd2CLvYvHZGl52fmjl/UP7P0dIABY6enZKZ/XTNwKEGc98fijrvMW9CaH6D1N5vCPddD/VBlImkiCaiD7jGNyAtj5xwgGj0OnBHf2mhxHpq650L5qb5NkojFB9Bb07c2UkUxIATy0dZkxtZyK5uIB6IIs1b1bHiaKJHwp4qTw7k3xxXuhSUPdRSncSL19XVUNwnWhQtS4r+jvoM2gsglXDB8yjhXWwc6JvLTp0VKq4XsAM6BV4DodPC4N/GgGYghhxy6uO7ViRU+R0z/H4o/VMifUvOs4anMY1SSe</enc:CipherValue>
    </enc:CipherData>
</enc:EncryptedData>

Basically what you have here is an ephemeral symmetric encryption key, which has itself been encrypted with the Public Key of the SSL Cert for the website InfoCard is interacting with. As you can see from the metadata provided in the KeyInfo fragment, the key is encrypted using RSA with OAEP encoding and SHA1, using the certificate identified in the SecurityTokenReference with the provided fingerprint (the fingerprint is a SHA1 hash of the cert bytes)

Your first job is to decrypt that encryption key. Step one - remove the Base64 encoding. Step 2 - you need to write a function which takes the private key for the cert referenced by the fingerprint, along with the data as input, and decrypts in this manner RSA-OAEP

Once you’ve successfully decrypted the key ( it should be 256 bits), you can use it to decrypt the token. As you can see in the XML, you need to use AES with a ChainedBlockCipher. Decrypt the token (Don’t forget to strip the initialization vectors...thanks Gary ), and you should see something similar to the following:


<saml:Assertion MajorVersion="1" MinorVersion="1"
                AssertionID="uuid:d2de97e7-96ac-4bb3-a373-4fc11c914519"
                Issuer="http://schemas.microsoft.com/ws/2005/05/identity/issuer/self"
                IssueInstant="2006-03-29T20:52:45.312Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
    <saml:Conditions NotBefore="2006-03-29T20:52:45.312Z" NotOnOrAfter="2006-03-29T21:52:45.312Z" />
    <saml:AttributeStatement>
        <saml:Subject>
            <saml:SubjectConfirmation>
                <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
                <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
                        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
                            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                        </e:EncryptionMethod>
                        <KeyInfo>
                            <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                                <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">BCDy8bwQIxTqcoTObIhcvR2KOLw=</o:KeyIdentifier>
                            </o:SecurityTokenReference>
                        </KeyInfo>
                        <e:CipherData>
                            <e:CipherValue>XjkCVuQZ19sYbSnEeKYQ7wD/+bKvGL6kkS2yuVjQX4y3N7U86zRJ66njNPdFNdh8k/x+5CNF1rpjq/Be75a1skO9ePjLgik/UA1DlDo9jaFoYvRlEj0BN/TPJaMZ24kcmcG+QeU89rdg0S4+bqxytHyh14m6IaIaX4aj88RRVq4=</e:CipherValue>
                        </e:CipherData>
                    </e:EncryptedKey>
                </KeyInfo>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Attribute AttributeName="GivenName" AttributeNamespace="http://schemas.microsoft.com/ws/2005/05/identity/claims">
            <saml:AttributeValue>Mister</saml:AttributeValue>
        </saml:Attribute>
        <saml:Attribute AttributeName="Surname" AttributeNamespace="http://schemas.microsoft.com/ws/2005/05/identity/claims">
            <saml:AttributeValue>Milo</saml:AttributeValue>
        </saml:Attribute>
        <saml:Attribute AttributeName="EmailAddress" AttributeNamespace="http://schemas.microsoft.com/ws/2005/05/identity/claims">
            <saml:AttributeValue>milo@xmldap.org</saml:AttributeValue>
        </saml:Attribute>
    </saml:AttributeStatement>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <Reference URI="#uuid:d2de97e7-96ac-4bb3-a373-4fc11c914519">
                <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                <DigestValue>leav91ZV/KJpwumP/j+4XtlEvJg=</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>gEVmREMwNiE67hMdOf7uuC4jnhG4f9y3WYL2pL6d9F3Nblf3qddMe6K+d/b6ucePKS3Q9XXBmBu2tWtmZlwTzldVjx8IYZb5u5jcQByAp2GrTJb/XxHA/3BkE073zdFRlmHje467kVd4Mcg6X2qNsV1N+euZqCUfmrXyf3cs5n4u6A9A1CTuQhCOGhE7jjDUGPmyChJa2YfHqpiVPEXgqN+RYOTLUFbA2kKj1Jyi8+FJD7vHP/5/kblge82waNFOOaA6d7lXDhr4lBDDhr5vKoNWy91bDMStn+nKN7Nzj7zPjxjynp7CisSewyWxAjcD9XDl/I9Va2UVDmPr4JC4bw==</SignatureValue>
        <KeyInfo>
            <KeyValue>
                <RSAKeyValue>
                    <Modulus>rCOb7lDap18tsTurz6j/fSYnO+ck5or10hn9tZhCDwXfJip2lqjIFcj3fYv1cyP96dl4++x8QGXSB5WAu3NNtjZkVxTDO4sOk+IpkLOlE5vM6ClMSV46tx9fo6tbQ9EhJTy7vXAbCH6hQnowxdmUEVKJudCtlMeHSotix98T5zJXYMjeLvmDPmSK8pG/t+kBmRjsgSZGqjD4VFlnDBpYOZ4R+nH2ESudyvZUwAkgPAEtGuBcc+nXVUEbs+O1xOkzcTRCm9FCoww1oNSi2maRGontD14Cbyy3DuNRxqPSxEc8rN7KBoq5w2y+Q5YTVYBB+qn2rXbO0aQlYHXIZOATpw==</Modulus>
                    <Exponent>AQAB</Exponent>
                </RSAKeyValue>
            </KeyValue>
        </KeyInfo>
     </Signature>
 </saml:Assertion>

The next step would be to quickly check the validity period on this Assertion to make sure it’s still fresh. You might also want to check the AssertionID against a table of previously seen assertions to prevent replay...depends on your level of paranoia.

On to signature validation...you should follow the steps outlined in XML-DSIG, but to paraphrase, check the digest of the canonicalized assetion against the digest in the SignedInfo block, and then valhttp://www.blogger.com/img/gl.link.gifidate the signature of the canonicalized SignedInfo using a PublicKey constructed from the provided KeyInfo.

Now, what’s bugging me is the use for the Symmetric Proof key provided in the Subject of the Assertion. Super Pat and I discussed this for awhile, and since it’s not used immediately in this protocol exchange, our best guess is that it’s used in subsequent interactions with the service, although I must admit the InfoCard docs are a little fuzzy on this subject. If anyone can fill me in, I’d appreciate it!

Finally, if your signature validation worked, extract the claims, enforce any policy you’d like, create a session, set a cookie, etc...

good luck!

Make your own security tokens without InfoCard

2006-03-30T23:03:00.000-08:00

Once you can consume security tokens from InfoCards, it's not too difficult to make them. Since most people don't have the time to try out InfoCard for real, I thought I'd add a quick utility to make your own tokens, and submit them to my RP. This should allow you to at least learn about the format and protocol for using InfoCard over the web.

Try the updated Java RP

Simple Java Based Relying Party

2006-03-29T18:15:00.000-08:00

I've just turned on an InfoCard Relying Party, implemented from the ground up in Java. If you've got InfoCard up and running, please login and send me a comment.

Java Based RP

I'll follow up soon with details, as well as an overview of how it works.

[Update: I've had some complaints that this isn't working with the latest and greatest IE ( due to an issue with IE according to Kim ) I suggest build 7.0.5296.0 for now. ]

I for one...

2005-11-21T22:39:00.000-08:00

I saw a commercial for robots tonight. Allow me to paraphrase:

I'm a neat freak...I'm obsesive compulsive...The Roomba is more intelligent than some people I know....It is a full featured robot...I know it's about to do a great service for me...the rumba finds more dirt than is humanly possible...I love robots...I don't know why I didn't buy one sooner.

I Love Robots!!!

Welcome!

Six Sigma

2005-11-21T22:35:00.000-08:00

My new Salomon shipped with the following "quality control" device.

Anyone?

Identity Claims Transformation in Action!

2005-11-07T17:34:00.000-08:00

Speaking of transforming claims, my good friend Pat is off in Tokyo at the moment speaking at Java ONE. As it turns out they've got a nice little posting of his bio for the converence:

アイデンティティ管理テクノロジーはこのセッションに注目しよう！（Pat Patterson氏）

Pat Patterson氏は、1997年にロンドンにあるソフトウェア開発会社のTrustbase社に入社。その後2000年にSunがTrustbase 社を買収し、以来Sunのアイデンティティ・管理製品グループのテクニカルアーキテクトを勤めています。フェデレーションとアイデンティティベースの Webサービス技術を中心に活動を行っています。JavaOne Tokyoでは２つのテクニカル・セッションのスピーカを担当。その内容について伺いました。

Obviously some fairly interesting claims about Pat's reputation/credentials, but unfortunately, not in one of my required formats. Fortunately BabelFish's STS allows for some simple claim transformation:

You will observe identity management technology to this session! (Pat Patterson)

Pat Patterson joins the Trustbase corporation of the software development company which London is in 1997. After that Sun purchases the Trustbase corporation in 2000, serves the technical architect of the identity management product group ever since Sun. Focusing on the federation and identity based Web service technology activity is done. With JavaOne Tokyo you take charge of the speaker of two technical sessions. You asked concerning the contents.

Awesome. Looks like the metasystem is going to need to stick to statically typed claims, with well defined transforms, for awhile yet...

Reply to Craig Burton

2005-11-07T14:57:00.000-08:00

Craig Burton recently replied to my comments on his I Cry Post. While I generally agree with his sentiment on the metasystem, I have to take issue with the oversimplification of Infocard, Microsoft's implementation.

Craig states:

WS-* is not the encapsulating protocol. WS-Trust is the encapsulating protocol.

WS-Trust is actually just the encapsulating protocol for claims transformation. Microsoft's paper on the Identity Metasystem defines encapsulating protocol as the following:

"The encapsulating protocol provides a technology-neutral way to exchange claims and requirements between subjects, identity providers, and relying parties."

While WS-Trust may provide for claims transformation, it certainly does not provide provide the complete working pieces of an Identity Metasystem. In order to build a metasystem, you need a number of other critical pieces. In this case Microsoft is requiring:

WS-SecurityPolicy and WS-MetadataExchange for declaration and negotiation of claims requirements
WS-Security/dsg/encrypt and for message integrity, confedntiality, and claims presentation
WS-SecureConversation for channel security and trust associations
WS-Addressing for action, address, and message correlation
SOAP for transport abstraction
...and some other tiny required specs...

Although not all of these are required components of an abstract metasystem, they all seem to be requirements of the Microsoft implementation, and that seems to run contrary to his call for an "architecture that is independent of mandated adoption" You gotta buy in.

Craig goes on to say:

What does WS-Trust do? It converts a token (in any format) into another token (in any format). You input an existing token, a request for a new token, and get back the new token. In otherwords, it is a token exchanger – between constituent systems.

Properly characterized, I'd say WS-Trust simply allows you to request this action to be performed. It's a simple request/response protocol, where the magic of any to any token transform is left out of band. At that point we're left up to systems that implement an Security Token Service (STS). I can name 1 commercial STS implementation (IBM's FIM), the Indigo Beta from Microsoft would allow you to build one fairly easily, and prototype code from sourceid. (Anyone know any others?) Unfortunately, given the above protocol requirements, there is some serious impedance in place of ubiquitous adoption.

Compounding the protocol requirements, in order for an STS to convert a token in any format, to any format, some sort of semantic equivalence between the two would need to be defined and implemented...something which is generally non-trivial, and sometimes not possible. Additionally, without a single canonical token format, and lacking a registrar of token formats and transforms, we're also left with a pretty serious scale issue. How does one know what the possible transforms are, and who can fulfill them? How do you incent the Supplying and Relying parties to negotiate (and by this I really mean implement) to a common set of claim formats?

Realistically, I think we'll probably end up in an environment where we negotiate to a limited set of common claims formats for the common stuff, and allow transport of a variety of vertically focused claims. Bridging between the participating parties is critical, but I'm not convinced that its the transform that's the killer app.

What I do think Craig really hits on here is that it's mandatory that a multitude of claims formats be supportable; a successful metasystem will neither be able to predict, nor prescribe the token/claim/assertion/attribute/etc formats which will flow across it. The transform is really just a facilitator, often necessary, but perhaps not a required one. I think Microsoft really nailed the decision to leave the token format out of band for the metasystem. This is critical to ubiquity, and I'm singing along with Craig on this. I am skeptical that they've got the right design center for adoption in the encapsulation protocol, when looked at in terms of it's complexity.

This does bring up a few outstanding questions I've got about Infocard:

What is the metadata format for "cards"? A combination of a WS-Addressing Endpoint Reference and Ws-SecPol? Something else?
How is it advertised and acquired? - Discovery seems totally opaque in the information I've seen so far. Kim Cameron alluded to the ability to advertise that one provides a card on a website at IIW this year, but what are the details?
At IIW, Microsoft mentioned that in order to promote usability aspects of the system, they'd be binding a human readable explanation of the machine readable claim. What is that format, and how is this not a new mandatory claim format for us to adopt?

Anyone out there have the answers?

Big Iron

2005-10-27T14:28:00.000-07:00

Went down to Atlanta earlier this week for a Sxip install...ended up getting awfully nostalgic for Sun when I saw this sucker:

That's a $5 million dollar Sun StorEdge L8500. Basically, it's a giant array of backup disks serviced entirely by robots, complete with a built in fire suppression system.

In 4 years at Sun, I never actually saw one in the wild.

Identity Insurance

2005-10-04T21:46:00.000-07:00

Interesting development...AllState is providing Identity recovery insurance:

http://www.allstate.com/landingpages/home/idtheft.aspx

"With Allstate's identity restoration coverage, you have a dedicated team to handle the complicated, time-consuming and tedious work needed to help restore your good name and your credit rating. They will make the phone calls, handle the paperwork and deal with the credit bureaus. Some services focus solely on credit card theft or offer limited expense coverage, but Allstate goes further to help protect your good name — and your time."

Sxip's at Web2.0 this week trying to kill this market off before it starts.

Interesting post at sforce

2005-07-25T19:54:00.000-07:00

Benji at SalesForce.com had an interesting post today on the sforce blog. Here's the juicy part:

How do the clients, which all use web services to authenticate (using login and password today calling our login call), know where to get the SAML token from, in a standard way? There is no standard way to do this today, and even standards like WS-Trust don't seem to solve this problem. For example, you build a client using our web services apis. You deploy to all our customers. Customer A has one SAML provider. Customer B has another SAML provider. How does your code know where to go to get the token when deployed at customer A and at customer B, without configuring all of the clients with the location of the SAML provider?

Benji raises some excellent points here...he's effectively pointing out the issue of discovering a security token service. What makes this complicated is the security token service in many of Sxip's customers is on a private network, and customers don't wish to expose the url to the general public. An anonymous discovery service either can't personalize the response to either customer a or b, or you end up exposing sts endpoint locations inside customer a or b.

Anyone have any ideas on this tricky problem?

damn.

2005-07-10T20:49:00.000-07:00

All time favorite barksdale-ism

2005-06-26T16:00:00.000-07:00

SOAP Client Widget for Tiger

2005-06-21T21:15:00.000-07:00

Thought I'd share my little experiment with Dashboard Widgets

It's a little AJAX Soap Client - provide the payload for the SOAP body, and it will post a message with wsa:Action and wsse:UserNameToken. The response is displayed back.

Milo's favorite barksdale-ism

2005-06-21T21:14:00.000-07:00

Here's what ended up on the wire

2005-06-19T19:00:00.000-07:00

This was sent to my service. As, you can see that InfoCard has automatically created a SAML 1.1 assertion bearing the email address provided in the selected InfoCard. What's not clear to me is what's going on with the action - its' using a wa-addressing action that is not defined in ws-trust...hmm. Anyone? I wish the body weren't mysteriously encryted....

[Update: Mark Wahl passed this along

"When requesting and returning security context tokens the following Action URIs are used
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT"
in WS-SecureConversation Feb '05.

Thanks Mark! ]


POST /simpleservice HTTP/1.1 Content-Type: application/soap+xml; charset="utf-8"; action="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT" 
Host: 192.168.9.11 
Content-Length: 12838 
Expect: 100-continue 
Connection: Keep-Alive  

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <s:Header>
      <a:Action u:Id="_1" s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</a:Action>
      <a:MessageID u:Id="_2">uuid:674467cc-10bd-4bd4-a4b6-fba565035d01;id=0</a:MessageID>
      <a:To u:Id="_3" s:mustUnderstand="1">http://192.168.9.10:8080/simpleservice</a:To>
      <dsig:X509Certificate xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">..../BjHqg==</dsig:X509Certificate>
      <a:ReplyTo u:Id="_4">
         <a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
      </a:ReplyTo>
      <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <u:Timestamp u:Id="_0">
            <u:Created>2005-06-20T00:44:36.734Z</u:Created>
            <u:Expires>2005-06-21T00:44:36.734Z</u:Expires>
         </u:Timestamp>
         <e:EncryptedKey Id="uuid-dfeed4a3-da17-4699-80aa-dad0cccc082e-1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
            <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
               <o:SecurityTokenReference>
                  <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-x509-token-profile-1.1#X509ThumbprintSHA1">nNpk/FqUmDNX8fvv3bk9BVjY0eQ=</o:KeyIdentifier>
               </o:SecurityTokenReference>
            </KeyInfo>
            <e:CipherData>
               <e:CipherValue>GlV7KHIY0thaICqbatPYLaSRO4dyXxsR698bm9Po88K3iQpF1TvTC4HPp415eobwvUy7mLpM8XfOKEvfZ3fk0P4FjyXhtxQOnN35D7rCxVrnIu5zZqlNev9HqeqrUW05ocYgTGjD0RIV4XdRoScPiZU96EkzIfc6QsIFhGqo6RQ=</e:CipherValue>
            </e:CipherData>
         </e:EncryptedKey>
         <c:DerivedKeyToken u:Id="_6" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
            <o:SecurityTokenReference>
               <o:Reference URI="#uuid-dfeed4a3-da17-4699-80aa-dad0cccc082e-1"/>
            </o:SecurityTokenReference>
            <c:Generation>0</c:Generation>
            <c:Length>32</c:Length>
            <c:Nonce>z3cSc/jtJ+UCF5CEQ8xsLg==</c:Nonce>
         </c:DerivedKeyToken>
         <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionId="uuid-30365992-d9e4-46ad-9443-41b1aa1cc917" Issuer="http://schemas.xmlsoap.org/ws/2004/10/identity/issuer#self" IssueInstant="2005-06-20T00:44:35.718Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
            <saml:Conditions x:Id="1" NotBefore="2005-06-20T00:44:35.500Z" NotOnOrAfter="2005-06-20T00:54:35.500Z" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://schemas.microsoft.com/2003/10/Serialization/"/>
            <saml:AttributeStatement x:Id="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://schemas.microsoft.com/2003/10/Serialization/">
               <saml:Subject x:Id="1">
                  <saml:NameIdentifier x:Id="1" Format="http://schemas.xmlsoap.org/ws/2004/10/identity#KeyThumbprint">9TGi5d7p2VFFnGtOZ5bmUwbpOJI=</saml:NameIdentifier>
                  <saml:SubjectConfirmation x:Id="1">
                     <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
                     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                        <KeyValue>
                           <RSAKeyValue>
                              <Modulus>znzfPeulynSTfQRdMtkW3CTzR3G2T3l4YqI6Csdfq4huIEySzeCd1oEZ2aUtG/WjD1ZvgcNkaS8V6JuyU2+XGArNP/szM/KMIYDWa0vSkr1WpM+HUOK58fZXDQWTEaKzWJePMfOjUQefcg3CzK1uj1jM4pAVl6Hpv4862uIdzkWQ5SYV9mKu862Sc5RqF74KggMU3N9BzjPVWBrHzFIvJIQPsUWWRhb57N5qw2GzjPBDxK3ACKdkT/MA08Lnr4hSR/f827Zv363xN1BRinqcrfJE0GVr6/LL11qvZqaKEgd0NRnyKn+IR8VJbtpGMDcR03nZhkHFP87esFOD63zUIQ==</Modulus>
                              <Exponent>AQAB</Exponent>
                           </RSAKeyValue>
                        </KeyValue>
                     </KeyInfo>
                  </saml:SubjectConfirmation>
               </saml:Subject>
               <saml:Attribute x:Id="1" AttributeName="http://schemas.microsoft.com/ws/2004/10/identity#E-Mail-Address" AttributeNamespace="http://schemas.microsoft.com/ws/2004/10/identity">
                  <saml:AttributeValue>cmort@sxip.com</saml:AttributeValue>
               </saml:Attribute>
            </saml:AttributeStatement>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
               <SignedInfo>
                  <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                  <Reference URI="#uuid-30365992-d9e4-46ad-9443-41b1aa1cc917">
                     <Transforms>
                        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     </Transforms>
                     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                     <DigestValue>6EgVjHzVJvq5p8wA9CmRAa4428I=</DigestValue>
                  </Reference>
               </SignedInfo>
               <SignatureValue>dHIsclXyt4S6/b485/Lw6t/0kAsJX3ctbJAtLZdSKoXiltOKLlOpnwrMESGDv6bwm3SjiadyF56MY0uWg8gqm65y8eO1o269CgQP4YB98LosaBnwzRXx63lzIp44rH6JcaOE0Cqq34P3cf5SxWC3BNaJpLfUbqrTw8wfHKIOxmc4bAaOMLMCV2QScbJQQYt1cE9b/mAtujl1cNzmGuDWVg2XyzwtE6HiPG8KvsgThDnz/ItzU2J9jfWBO7qXNDTM+EJt7LDn26HfixgxHDUm4W+wwxfhLGlER/KcNDWESOezBBd40diKpwIEALjZ/tAgLoGZPmnskFoaSLiDeeHTRQ==</SignatureValue>
               <KeyInfo>
                  <KeyValue>
                     <RSAKeyValue>
                        <Modulus>znzfPeulynSTfQRdMtkW3CTzR3G2T3l4YqI6Csdfq4huIEySzeCd1oEZ2aUtG/WjD1ZvgcNkaS8V6JuyU2+XGArNP/szM/KMIYDWa0vSkr1WpM+HUOK58fZXDQWTEaKzWJePMfOjUQefcg3CzK1uj1jM4pAVl6Hpv4862uIdzkWQ5SYV9mKu862Sc5RqF74KggMU3N9BzjPVWBrHzFIvJIQPsUWWRhb57N5qw2GzjPBDxK3ACKdkT/MA08Lnr4hSR/f827Zv363xN1BRinqcrfJE0GVr6/LL11qvZqaKEgd0NRnyKn+IR8VJbtpGMDcR03nZhkHFP87esFOD63zUIQ==</Modulus>
                        <Exponent>AQAB</Exponent>
                     </RSAKeyValue>
                  </KeyValue>
               </KeyInfo>
            </Signature>
         </saml:Assertion>
         <e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
            <e:DataReference URI="#_7"/>
         </e:ReferenceList>
         <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
               <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
               <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
               <Reference URI="#_0">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>t4R8JHI9sfYljoocDZ69/1HoAJU=</DigestValue>
               </Reference>
               <Reference URI="#_1">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>Q25uUOzeV9Aduvtw9eG9xMMNHrI=</DigestValue>
               </Reference>
               <Reference URI="#_2">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>f4UZdzH8TQGemsO2i2E+jIa6XDo=</DigestValue>
               </Reference>
               <Reference URI="#_3">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>QFhRuh49ZnX8S4z8iKi3diz7UDE=</DigestValue>
               </Reference>
               <Reference URI="#_4">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>zaBQWq9U/zdzkimMsCHucawY8qc=</DigestValue>
               </Reference>
               <Reference URI="#_5">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>6am03LAQSO20LZsE07ikNHHAazo=</DigestValue>
               </Reference>
            </SignedInfo>
            <SignatureValue>ZFL4QT1wu4N58VamcSyL4cJxEj3cKBCWEwNR4P06FlLKiCseyVp2SWGe1qciQCUdhZd5zQMcuUTXxlod9uN3HUPQdHZSGvvM2wTLsDnBYL7KQXgO+VHOmupGWIhI+aZiIPq1+IXv9hi5qqFb9hQ6/xB9i0iO5KZFe3bqjt67QrZDgtsFqYLT+GVkdq+4dKf+HTXsXSylm6eS5ce6gpCalTu+6XTB/8eG/kRLxFUXci4CTyipl/NLTqrFmmiln/dzPjeGrskjf2WZdmg8oXw+of46mb04fpWrE3vUqX1lfA7kdCFL3gP0bEiRgiHXOa9PhaQdOt/nt0mzfq3YHwc85w==</SignatureValue>
            <KeyInfo>
               <o:SecurityTokenReference>
                  <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">uuid-30365992-d9e4-46ad-9443-41b1aa1cc917</o:KeyIdentifier>
               </o:SecurityTokenReference>
            </KeyInfo>
         </Signature>
      </o:Security>
   </s:Header>
   <s:Body u:Id="_5">
      <e:EncryptedData Id="_7" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
         <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
         <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
               <o:Reference URI="#_6"/>
            </o:SecurityTokenReference>
         </KeyInfo>
         <e:CipherData>
            <e:CipherValue>lR2D1YctHtOdkC0bNrfP4BrpIOJkG5GxWVKm+LzkY7+1RKxhpL5IC1Z10ON8Vsg9+B7a7/....qRneyxtQ==</e:CipherValue>
         </e:CipherData>
      </e:EncryptedData>
   </s:Body></s:Envelope>

Invoking InfoCard

2005-06-19T17:45:00.000-07:00

With all that out of the way, I finally can invoke my client, and get into the InfoCard interface, as well as take a look at the resulting message enrichement

When I invoked the client, the first thing it does is validate the Identity of the service using the cert in the addessPropeties. Assuming validity, the InfoCard UI is invoked. The first thing you seen is presentation of the relying party, and potentially their terms of service, as well as prompt to either agree to their terms, or cancel the operation. I wish I had a screen shot, but there doesn't seem to be a simple means to remove a relying party from your trust list, or change its settings. I expect this will show up in future versions.

Once I accepted the terms, I'm prompted to select an InfoCard. This shows the UI for infocard actually being invoked:

Click for a larger version

A few things to notice here

1) They track which card I've previously presented, and when I did it
2) They track what the relying party already knows about me

From here, I can choose a card to submit. This talks to a local STS in the current beta, and generates a SAML assertion, which is used to enrich the SOAP call...

Now the App.config

2005-06-19T17:18:00.000-07:00

InfoCard ends up getting invoked (at least in the Indigo use cases) via a custom binding in the services configuration file (app.config or web.config depending on selfhosting or was/iis hosted services)

The config file has 3 main sections required for InfoCard usage. The first is a custom binding. The binding section basically describes the protocol indigo will use to expose or talk to services in a declarative fasion. It ships with a number of default bindings for WS-I basic profile interop, WS-*, as well as some MSFT proprietary binary optimizations. You do have the ability to define a custom binding which gives you granular control over protocol. In order to use InfoCard, you seem to need to use a custom binding. Here is an example:


<bindings>
<customBinding>
<!-- Define custom binding for InfoCard. -->
<binding configurationName="InfoCardBinding">
<security authenticationMode="IssuedTokenForCertificate" contextMode="Session">
<federationParameters>
<tokenRequestParameters>
<xmlElement>
<wst:TokenType xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsid="http://schemas.xmlsoap.org/ws/2004/10/identity" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>
</xmlElement>
<xmlElement>
<wst:Claims xmlns:wsid="http://schemas.xmlsoap.org/ws/2004/10/identity"  xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsid:Claim wsid:URI="http://schemas.microsoft.com/ws/2004/10/identity#E-Mail-Address"/>
</wst:Claims>
</xmlElement>
</tokenRequestParameters>
</federationParameters>
</security>
<httpTransport/>
</binding>
customBinding>
</bindings>

This basically says that the authentication mode is IssuedTokenForCertificate which I believe indicates "Use InfoCard" It then designates the parameters which will be passed into the WS-Trust RST - in this case stating that it wants a SAML assertion with email address attribute assertion

Next, we need special behavior section which is referenced from the endpoint configuration. This indicates how to find the local certificate to exchange for the SAML assertion. This required importing the certificate into my local trusted store:


<behavior configurationName="TrustedCredentials" returnUnknownExceptionsAsFaults="true">
<channelSecurityCredentials>
<serviceX509Certificate findValue="Fabrikam" x509FindType="FindBySubjectName" storeLocation="CurrentUser" storeName="TrustedPeople" />
</channelSecurityCredentials>
</behavior>

It's not yet clear what other credential types can be used - there seem to be many options in the core Indigo APIs, but the authenticationMode of IssuedTokenForCertificate has me a bit concerned others aren't yet supported...

Finally, a addressProperties section is required:


<addressProperties identityType="Dns" identityData="Fabrikam">
<endpointHeaders>
<dsig:X509Certificate xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">MIIDwzCCAqu....==</dsig:X509Certificate>
</endpointHeaders>
</addressProperties>

I've got to say I don't understand this at all...or more to the point, don't see how it's viable. I believe what this is doing is providing the Identity of the service itself. Since this is statically declared in the clients config, it looks like a huge distribution issue. I'm sure microsoft must have something else in mind, like fetching this over ws-mex...anyone?

That pretty much covers what is required for the client and service config files - they're pretty close to the same. Next, we'll take a look at what happens when we invoke

And the Simple Indigo Client

2005-06-19T17:13:00.000-07:00

Next, we need a simple client to go with my service.


using System;
using System.Collections.Generic;
using System.Text;

using System.Xml;
using System.ServiceModel;

namespace InfoCardClient
{

    //This replicates the services contract - just raw Messages
    [ServiceContract]
    interface IGenericMessageChannel
    {
        [OperationContract(IsOneWay = true, Action = "*")]
        void Send(Message msg);
    }

    class SimpleClient
    {
        public SimpleClient()
        {       
        }

        void SendMessage(IGenericMessageChannel channel, string input)
        {
            XmlDocument contentDocument;
            contentDocument = new XmlDocument();
            contentDocument.LoadXml("" + input + "");

            XmlNodeReader content = new XmlNodeReader(contentDocument.DocumentElement);
            MessageVersion messageVersion = MessageVersion.CreateVersion(EnvelopeVersion.Soap11);

            using (Message msg = Message.CreateMessage(messageVersion, "http://tempuri.org/ISimpleService/Receive", content))
            {
                try
                {
                    channel.Send(msg);
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: " + e.ToString());
                }

            }
        }

        public void Invoke( string input)
        {
            using (ChannelFactory channelFactory =
                        new ChannelFactory("InfoCardClientConfig"))
            {
                channelFactory.Open();
                IGenericMessageChannel channel = channelFactory.CreateChannel();
                SendMessage(channel, input);
                channelFactory.Close();
            }
        }
    }
}

I call this client from another class which is irrelevant to the InfoCard/Indigo magic.

My Simple Indigo Service

2005-06-19T17:00:00.000-07:00

Now onto some real infocard work. To begin with, I developed a simple webservice and client using Indigo. This service basically displays the raw SOAP which it is sent:


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

//This is the Indigo namespace
using System.ServiceModel;
using System.Xml;

namespace InfoCardService
{
    /**
    Here, I'm using an interface to define the service contract.  
    Service contracts are explicit in Indigo, and can be distict
    from application/class level contract as seen here.
    */
    [ServiceContract]
    interface ISimpleService
    {
        //A very raw service - interface accepts low level message type.
        [OperationContract(IsOneWay = true)]
        void Receive(System.ServiceModel.Message msg);
    }


    public partial class SimpleService : Form, ISimpleService
    {
        //selfhosting ServiceHost using generics to be types to my implementation
        ServiceHost sh;
        
        public SimpleService()
        {
            InitializeComponent();            
        }

        private void button2_Click(object sender, EventArgs e)
        {
            sh.Close(); 
            Application.Exit();
        }

        public void Receive(System.ServiceModel.Message msg)
        {
            MessageBox.Show("New Message:\n\n" + msg.ToString());            
        }

        private void Start()
        {
            sh = new ServiceHost();
            sh.Open();
        }

        static void Main(string[] args)
        {
            SimpleService service = new SimpleService();
            service.Start();
            Application.EnableVisualStyles();
            Application.Run(service);
        }

    }
}

Invoking WS-Trust from Indigo

2005-06-19T14:42:00.000-07:00

Making a WS-Trust RST Issue call from Indigo is pretty simple. I defined a custom security binding with a endpoint reference and presto...ws-trust.

To do this, I added this to the federationParameters section of a custom binding security element:

<endpoint address="http://192.168.9.10:8080/simpleservice" bindingConfiguration="WSTrustBinding" bindingSectionName="wsProfileBinding"/>

I then reference the binding from my client endpoint reference, and when I invoked my client, it makes this call:


POST /simpleservice HTTP/1.1
Content-Type: application/soap+xml; charset="utf-8" action="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue"
Host: 192.168.9.11
Content-Length: 1304
Expect: 100-continue
Connection: Keep-Alive

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
   <s:Header>
      <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
      <a:MessageID>uuid:6e984807-8946-4201-a757-2b6829a5fdb4;id=0</a:MessageID>
      <a:To s:mustUnderstand="1">http://192.168.9.10:8080/simpleservice</a:To>
      <a:ReplyTo>
         <a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
      </a:ReplyTo>
   </s:Header>
   <s:Body>
      <t:RequestSecurityToken Context="uuid-58ae93d3-a412-4ee4-97ab-288bc880b35a-2" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
         <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType>
         <t:BinaryExchange ValueType="http://schemas.microsoft.com/net/2004/07/secext/WS-SPNego">TlRMTVNTUAABAAAAt4IY4gAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==</t:BinaryExchange>
         <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
            <EndpointReference xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://schemas.microsoft.com/2003/10/Serialization/">
               <Address>http://192.168.9.10:8080/simpleservice</Address>
            </EndpointReference>
         </wsp:AppliesTo>
         <t:KeySize>256</t:KeySize>
      </t:RequestSecurityToken>
   </s:Body></s:Envelope>

Looks to be using a web serivce binding of SPNego by default. I wish I had a remote STS to play with...

The InfoCard API

2005-06-19T12:51:00.000-07:00

The InfoCard API is pretty straight forward (and I suspect in flux). There are only really 2 classes to pay attention to:

Microsoft.InfoCards.InfoCardClient

public static System.ServiceModel.Security.GenericXmlToken GetToken(System.ServiceModel.EndpointAddress endPoint, System.Collections.Generic.IEnumerable policy, System.Xml.XmlElement requiredRemoteTokenIssuer)

public static void Manage()

(Notice no constructor)

Microsoft.InfoCards.InfoCardTokenProvider

public override System.IAsyncResult BeginGetToken(System.ServiceModel.EndpointAddress target, System.AsyncCallback callback, object state)

public override System.ServiceModel.Security.Tokens.SecurityToken EndGetToken(System.IAsyncResult result)

public override System.ServiceModel.Security.Tokens.SecurityToken GetToken(System.ServiceModel.EndpointAddress target)

public InfoCardTokenProvider()

public override bool TryApplyIssuedTokenParameters(System.ServiceModel.Security.IIssuedTokenParameters parameters)

public override bool WillGetTokenCompleteSynchronously(System.ServiceModel.EndpointAddress target)

Besides that, it's all exceptions:
Microsoft.InfoCards.InfoCardException
Microsoft.InfoCards.NoDefaultCardException
Microsoft.InfoCards.ProvisioningCommunicationException
Microsoft.InfoCards.ServiceNotStartedException
Microsoft.InfoCards.StsCommunicationException
Microsoft.InfoCards.SuppressUIFailedException
Microsoft.InfoCards.UndisclosedClaimException
Microsoft.InfoCards.UnsupportedKeyGenerationTypeException
Microsoft.InfoCards.UntrustedRecipientException
Microsoft.InfoCards.UserCancellationException

A few other intersting things show up in the Indigo APIs:

Support for SAML, Kerb, X509, UserName, Windows, and WindowsUserName Tokens

Looks like support for April 04 and Feb 05 versions of WS-Trust

Today's barksdale-ism

2005-06-19T12:31:00.000-07:00

Programming InfoCard - part 1. Invoking the UI

2005-06-18T15:48:00.000-07:00

Since I'm un-employed this weekend (I'm starting a new job at Sxip Identity on Monday), I thought I'd sit down and poke around the new Microsoft.InfoCards API and Indigo.

To start with, I suppose I'd better state up front that I haven't ever used Windows as my primary Desktop OS, and this is my first dive into C# as well. Fortunately, it seems to be enough of a Java clone that the learning curve is really quick...it feels a lot like Java 1.5.

Invoking the InfoCard UI:

My first step was to get the WinFX CTP and VisualStudio Betas installed. This was pretty straightforward, but make sure you have the latest of each, as there are some linking dependencies in the .NET build that require a specific combination. Also, I'd recommend the express version of Studio, as the full version is several GB.

To start out hacking with InfoCard, I thought I'd simply invoke the InfoCard UI. The simple way to do this is to hit the ControlPanel -> Digital identities. (Note that you can start the system by running: net start "InfoCard Service" at the command prompt if the system is not started for you) The result is the following wireframe UI:

Click for a larger version

It's also quite simple to invoke this via code. To do so, you can simply use the Manage() method on Microsoft.InfoCards.InfoCardClient. Simply create a new Console application, and add a reference to the Microsoft.InfoCards assembly. Then, the following code will invoke the InfoCardUI


using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.InfoCards;

namespace ManageInfoCard
{
    class Program
    {
        static void Main(string[] args)
        {
            InfoCardClient.Manage();
        }
    }
}

That's all it takes to invoke the InfoCard system from code. More to come....

While you wait- here are some interesting links on Infocard, and Indigo which I found useful:

Indigo Docs on Infocard
A weekend with Indigo
Andy's InfoCard Blog
Simple Indigo Client
Simple Indigo Service

Daily Barksdale-ism

2005-06-18T12:33:00.000-07:00

I recently ran across an old book of Barksdale-isms from Netscape. I thought I'd share some of the choice ones.

Today's - The three rules of snakes:

Tsunami!

2005-06-14T21:07:00.000-07:00

Tsunami Alert in San Francisco - if there is one, it's will hit the bay at 9:24 tonight..

martha's vineyard

2005-06-13T11:27:00.000-07:00

Mara and I just got back form a week on MV. I went a little crazy with the camera, and ended up with a flickr photoset that's 140+ large. Enjoy!

wisco represent

2005-06-07T19:02:00.000-07:00

My good friend hamlett passed along some must haves for proud 'sconies: Illannoy.com

chappaquiddick

2005-06-07T18:59:00.000-07:00

Congrats to Barrett and Anne!

netscape directory...

2005-06-02T20:19:00.000-07:00

...has finally gone open-source!

http://directory.fedora.redhat.com/wiki/Main_Page

It's refreshing to see something positive coming out of the ashes of Netscape - between embedding IE in Netscape 8, and the low-cost ISP ads...

more traveling with mara

2005-05-30T17:42:00.000-07:00

I finally got around to putting together a slide show of our recent Mexico trip. I just can't say enough nice things about Tulum.

triplets.

2005-05-30T17:38:00.000-07:00

and since I'm being cliche'...three's a crowd.

twins.

2005-05-30T17:36:00.000-07:00

two is better than one.

freak of nature.

2005-05-30T16:37:00.000-07:00

According to Wikipedia, The phrase "cor gi" translates to "dwarf dog" in Welsh.

metaphysical-graffiti

2005-05-30T16:13:00.000-07:00

An interesting identity question that I pass on the way to work each day:

Given that the artist poses the question in the first person, I tend to trust "me." As soon as you direct the question from the third person, it's the asserted attributes of the entity that are trusted, and not the entity itself.

Of course, as the always excellent read of luke razzel's blog points out, names can be a bit tricky too.

france

2005-05-17T19:33:00.000-07:00

What could be better than traveling with Mara?

mixed media

2005-05-11T12:44:00.000-07:00

loretta lux.

jonothan winters ( a new member )

danny way.

paris hilton

Hey Crackhead!

2005-05-10T14:56:00.000-07:00

Paul Graham has 3 Simple Rules for building a startup:

Start with good people
Make something customers actually want
Spend as little money as possible

I work in the posterchild facility for Rule #3...a warehouse attic above a gay porn production facility.

What I find particularily ironic about this is that A) They seem to be doing a better job of executing on Rule #2, and B) they're called Titan Media. I mean what are the chances? Titan Media producing Blue Movies below a software startup called Blue Titan...

At this point, you're probably wondering what the heck this post has to do with crackheads. Well...I've come to have a mature understanding of a few of the subtler points of life in SOMA.

First off, apparently the music in porn is dubbed in after the movie is made. This means nothing covering up the uhmm...noise...from below. This is suprisingly disruptive to the engineering processes, and, when properly timed to coincide with important meetings, an effective deterrent to investment and customer acquisition.

The other thing I've learned (at my poor motorcycle's expense) is that, in a pinch, you can smoke crack out of sparkplugs.

This brings us all the way back to rule #1 - start with good people:

Don't Bother Calling Support.

2005-05-09T00:22:00.000-07:00

I was recently using one of BEA's many SOAP stacks, and discovered that while comprehensive, their documentation isn't actually accurate...a particularily frustrating combination.

Lucky for me, I happen to sit next to the guy who used to be in charge of all of them. He clued me into the site of manoj, who writes the server stack - apparently its where support sends people.

If you're using web services on weblogic...you'll need this: http://www.manojc.com/

Negative Assertion

2005-05-09T00:15:00.000-07:00

Here is an intersting aspect of my digital identity...online records of the skateboarding ticket I received back in college.

I'd be a little scared by this if the State of Wisconsin were at all threatning...that is assuming you're not a feral house cat Ahh....wisco...

If you're feeling especially geeky today, you can query my WI criminal record over SOAP

Google...Directory Service or Server?

2005-05-09T00:02:00.000-07:00

Another interesting scientific paper (don't worry - the last for awhile) is the Google Labs write up on GFS.

As I read this paper, I was struck with the architectural similarities to Directory Server as well as work we'd done on a system called the "distributor'". While many Directory servers have reasonably good vertical scaling capacity, there is a certain point where the management functions of a system becomes too fragile, sequential operations take to long, and the statistically low write volumes (that tend to be a directory design center & increasing liability) still result in large write volumes as a function of a user population. Deployment of a single physical system, while technically viable, starts failing to meet design constraints in ways which simply aren't an issue at low scale. Ultimately, decomposition of data into smaller logical "chunks" not only allowed better aggregate write throughput, but also allowed parallelization of time dependent operations (backup, recovery, etc).

I had a lot of fun working on this with some of my favorite people there - Steve Shoaff and Neil Wilson. I hope that Sun let's this loose. - in the meantime, read about GFS.

Stand near the edge...

2005-05-08T23:36:00.000-07:00

Here's an intesting read on how ideas emerge from holes.

So, why's this the first post to my blog?

Having spent 5 years in the IdM industry, and having done so at one company (err...3? Netscape/iPlanet/Sun? ), I recently decided to jump through a structural hole, and see what was on the other side. As it turns out, it was a small SOA startup.

8 months later I've decided to jump on the bandwagon, and I've decided to call my blog xmldap - a nice hybred between my old and new industries, which is what I intend to write about...I hope you enjoy.

The paper itself does a nice job articulating (and partially quantifying) the intangible social capital assigned to social supernodes (see the 6 degrees of bowen ). As the new generation of emergent identity systems gets designed, we must provide for liberal acceptance of tokens/assertions/claims. Physical manifestations of social networks like LinkedIn have tremendous potential as transitive "trust" overlays...picture a Web of Trust model without key management. Some powerful Identity claims exist in untapped form (eBay reputation, social webs, etc ) - as in any good protocol design, let's be liberal with what we accept.