I'll post some code later on, but I wanted to make some quick points about integrating ADAM and AzMan.  I'm in the midst of building an authentication/authorization system using the two technologies together, and have some across some stumbling blocks.  There's not much documentation, particularly around AzMan, and the COM interfaces for AzMan can be a bit cumbersome.

• Storing users in ADAM and authorizing them using ADAM requires Windows 2003 Server or Vista.  There's no decent way to make this work on Windows XP.  The necessary AzMan interface, IAzClientContext2, doesn't exist on XP.  It's required for using a collection of user and group SIDs from ADAM to do access checks against AzMan.  I'll post some code later...
• IAzClientContext2 is also available on Vista, so Vista is also a viable dev platform.
• There are some confusing interactions between the AzMan UI and the programmatic API.  If you create a Role in the AzMan UI, but don't create a RoleAssignment, the programmatic call to IAzApplication2.OpenRole will fail.  If you create the role assignment, but don't actually assign any users or groups to it, OpenRole succeeds.  Conversely, if you call the programmatic IAzApplication2.CreateRole method and assign operations and users to the role in code, the RoleAssignment shows up in the UI, but not the Role itself. 
• If you assign an ADAM user to be a member of an AzMan group, it won't show up in the AzMan UI, but if you assign them directly to a Role, the ADAM user's SID will show up (as "unknown SID") under the RoleAssignment.  Either way, the call to AccessCheck works correctly.
• You must pass the complete list of group SIDs from ADAM, but fetching the user's "tokenGroups" property.  Don't use "memberOf" because it doesn't take into account groups which belong to other groups.

More detail to come...

I've read a bunch of these over the last few weeks, and thought perhaps I could duck, but Scott tagged me today, so I guess I should come clean.  Most of these arne't exactly secret, but you may not have heard me hold forth on them before

• My degree (a B.A.) is in East Asian Studies.  I spent my 4 years studying up on Buddhism, Japanese Art, and Chinese Communism.  My work study job was retrieving term papers off of floppies that had beer spilled on them, one precious sector at a time.  The first Computer Science class I ever took was at PCC after working at Intel for several years.  C++ I think it was.  Or possibly data structures.  I dropped out of a class on assembler, 'cause it was boring. 
• I love trashy food.  I was raised on 70's hippy vegetarian food, and to this day I have a deep and abiding love of chicken fried steak, chipped beef on toast, and fried SPAM. 
• I have a "simian crease" on my right hand.  Most people have two or three lines running horizontally across their palm (heart line, life line, etc).  I only have one the runs all the way across.  Common among chimpanzees and people with Down syndrome, less so among others.
• On weekends, I tend to dress like a Viking.  My whole family are long-term participants in the Society for Creative Anochronism.  I used to dress up in armor and hit people with (actually mostly be hit with) wooden swords.  I gave that part up since I'm not 18 anymore, and it hurts.
• My very first job was as an apprentice house painter.  I mostly dug ditches and drove ladders around Seattle for $6/hr.  I started the job by lowering the bottom of the boss' dirt floored basement by about 6 feet.  8 hour days of digging dirt into 5 gallon buckets, and hauling them two at a time up a flight of stairs.  I gained about 10 pounds of pure biceps. 

Not exactly shocking revalations, I admit.  Not compared to Scott's fashion obsession anyway.  I knew he was a snappy dresser, but...

I can't think of too many people I know have haven't already been tagged, so I'm not sure I'll make 5.  I nominate Jason, Stuart Celarier, John Batdorf,  Jeff B., and Don Smith.

Late last week, Rhapsody finally released a new desktop client that doesn't crash in the presence of IE7.  Hurray!  I've been gimping along with the web-based client, which is cool, but not nearly as full-featured as the desktop version.  I've been running it for several days now, and not one crash, so I'm hopeful at this point.  Just in time to listen to all that Christmas music that I'd never shell out to buy full time...

Update: I may have spoken too soon.  It works fine on my desktop at work, but crashes constantly on my laptop at home.  Sigh.

Since time immemorial (or since Marconi, anyhow) those wishing to be licensed as Radio Amateurs in the US have had to pass a Morse code test.  Relatively recently, there has been an entry level license class (Technician) that doesn't require passing the code test, but which (therefore) comes with no privileges on the HF bands (for long-distance communications). 

The code requirement has long been a hotly contested issue among amateurs.  Many have maintained that learning Morse code meant that you were "serious" about amateur radio, and would therefore be a skilled and considerate radio operator.  The problem is, since so few people actually use Morse code on the radio anymore, it has become (in my opinion, and that of many others) an artificial hoop that had to be jumped through before you could get into the high priesthood of amateur radio.  Most of the General or Extra class licensees I've talked to have never ditted or dahed once since passing the test. 

What this means for me personally is that I can finally hope to upgrade to a General class license.  I've studied all the material, and am pretty sure that I could pass the exam, but given the way the rest of my life works, I've been unable (or unwilling) to devote the time it would take to learn Morse code, so I've never taken the test. 

Of course, if I did pass the test, I'd want to get an HF-capable radio, but that's a whole different problem.

I spent about a day and a half this week trying to get a CC.NET server working with a complex combination of MSBuild (running the build script) TypeMock (the solution we're using for "mock objects") and NCover (for code coverage analysis) that proved tricky to get right.

In a typical build script, you'd create a task to run your unit tests that depends on your compile task.  And you might want to run a "clean" task first so you know you're starting from ground zero. 

Bringing a profiler into the mix changes the equation a bit.  Or in this case, two profilers that have to play nice together.  A "profiler" in this case means something that registers itself as a .NET profiler, meaning that it uses the underlying COM API in the CLR to get under the covers of the runtime.  This was originally envisioned as enabling profilers that track things like performance or memory usage that have to run outside the context of the CLR.  NCover uses this capability to do code coverage analysis, so that we can get reports of which lines of code in our platform are not being touched by our unit tests.

TypeMock is also a profiler, which causes some interesting interaction.  TypeMock uses the profiler API to insert itself between calling code and the ultimate target of that call in order to "mock" or pretend to be the target.  We use this to reduce the dependencies that our unit test code requires.  Rather than installing SQL Server on our build box, we can use TypeMock to "mock" the calls to the database, and have them return the results we expect without actually calling SQL. 

So...the problem all this interaction led to re: my build was that in order to make everything work, the profiler(s) have to be active before any of the assemblies you want to test/profile are loaded.  I had my UnitTest target set up like this:

 

with the dependencies set to that the compile and "RemoveTestResults" targets would be evaluated first.  Unfortunately, this caused the whole build to hang for upwards of an hour when this target started, but after the compile and "remove" targets had run.  I'm theorizing (but haven't confirmed) that is is because the compiler loads the assemblies in question during the build process, and they don't get unloaded by the time we get to starting TypeMock.  That apparently means a whole bunch of overhead to attach the profilers (or something).  What finally ended up working was moving the compile target inside the bounds of the TypeMock activation, using CallTarget instead of the DependsOnTargets attribute.

 

This works just fine, and doesn't cause the 1 hour delay, which makes things much easier.

I just finished Deep Survival: Who Lives, Who Dies, and Why by Laurence Gonzales, and would heartily recommend it to anyone who participates in any kind of outdoor or adventure activity, or anyone interested in the psychology of survial.  I was a little skeptical, since the book jacket made it sound like it was mostly case studies of survial situations.  While those certainly play a central role, the book is really more about the latest in brain science and psychology, and how that explains the way people behave when they get lost in the wilderness, or have to face other kinds of survival situations. 

Mr. Gonzales has definitely done his homework.  He's obviously spent a huge amount of time reading accident reports, and accounts by survivors, and picks out trends from both categories.  He then ties those trends back to the underlying brain science, which goes a long way toward explaining the (seemingly) irrational behavior often observed in people under stress. 

As someone who enjoys wilderness backpacking, as well as someone involved in disaster preparedness, I found this book completely fascinating. 

The book ends with a list of 12 tips for how to make it through a survival situation, which I found quite valuable.

One of the (many) issues I encountered in creating a duplex http binding with IssuedToken security (details here) was that when using a duplex contract, the client has to open a "server" of its own to receive the callbacks from the "server" part of the contract.  Unfortunately, there are a couple of fairly critical settings that you'd want to change for that client side "server" that aren't exposed via the configuration system, and have to be changed via code.

One that was really causing me problems was that for each duplex channel I opened up (and for one of our web apps, that might be 2-3 per ASP.NET page request) I had to provide a unique BaseClientAddress for each channel, which quickly ran into problems with opening too many ports (a security hassle) and insuring uniqueness of the URI's (a programming hassle).  Turns out that you can ask WCF to create unique addresses for you, specific to your chosen transport in their method of uniqueness.  However, you make that request by setting the ListenUri and ListenUriMode properties on the ServiceEndpoint (or the BindingContext).  For the client-side "server" part of a duplex contract, that turns out to be one of those settings that isn't exposed via configuration (or much of anything else, either). 

Luckily, I found an answer in the good works of Nicholas Allen (yet again).  He mentioned that you could set such a property on the BindingContext for the client side of a duplex contract.  Not only that, but Mike Taulty was good enough to post a sample of said solution. 

There's a great summary of the solution here, but to summarize even more briefly, you have to create your own BindingElement, and inject it into the binding stack so that you can grab the BindingContext as it hastens past.  Now I'm setting the ListenUri base address on a specific port, and asking WCF to do the rest by unique-ifying the URI.  Not only do I not have to keep track of them myself, but I can easily control which ports are being used on the client side, which makes both IT and Security wonks really happy.

On Scott's recommendation, Vikki and I got Brick from Netflix and watched it a few days back.  Then watched it again. 

If you like film noir, Brick is a no-brainer. 

The basic vision of the film (and it won a Sundance prize for originality of vision) is that of a classic Hammet-esque noir film, but set in a Southern Californian High School.  No, really.  And it's brilliant.  The actors all obviously got it.  There's nothing farcical or comic about the performances.  They all believe in the vision.  Which isn't to say that there aren't funny moments (such as the hero meeting with the most dangerous drug dealer in town while his Mom serves them juice and cookies) but they are funny as part of the plot, not because of the aesthetic of the film. 

Solid performances all around, and some great dialog.  The dialog is heavily spiked with both gumshoe and pseudo-modern-teen argot, so turning on the subtitles helps follow the story the first time through. 

There's a lot of depth here, especially for a directorial debut, and I think this is a film I'll go back and watch over and over again.

This took me WAY longer to figure out that either a) it shoudl have or b) I had hoped it would.  I finally got it working last week though.  I now have my client calling the server via a Dual Contract using IssuedToken security (requires a SAML token), said token being obtained from an STS written by me, which takes a custom token from the client for authentication. 

On the plus side, I know a whole bunch more about the depths of the ServiceModel now than I did before.

It turns out (as far as I can tell) that the binding I needed for client and server cannot be described in a .config file, and must be created in code.  That code looks like this on the server

 

and essentially the same on the client, with the addition of setting the clientBaseAddress on the CompositeDuplexBindingElement.

This works just fine, getting the token from the STS under the covers and then calling the Dual Contract server interface with the token. 

I ended up with a custom binding to the STS itself, mostly because I needed to pass more credentials than just user name and password.  So the STS binding gets created thusly:

 

Not as easy as I had hoped it would be, but it's working well now, so it's all good.  If you go the route of the custom token, it turns out there are all kinds of fun things you can do with token caching, etc.  It does require a fair amount of effort though, since there are 10-12 classes that you have to provide.

I've come a long way since the last issue, and I think I have most of that stuff worked out.  Now the problem is that what I really need is to be able to use the Dual Http binding, in conjunction with an STS to provide the SAML tokens.  I have it working fine (with Dual binding) as long as I issue the token myself and attach it using ClientCredentials.

The server side binding looks like this

 

the client side binding like so

 

 On the client side, I'm using the SamlClientCredentials from the SamlTokenProvider sample, and attaching it to the outgoing endpoint.

 

This all works like I would expect, and I get properly authorized on the server side.  The only catch here is that since I'm signing the SAML token with a cert I created myself, I have to set the certificateValidationMode for the issuedTokenAuthorization bit on the server side, which sadly isn't supported through the config file, so I have to tweak the ServiceHost myself.

 

Not too much trouble, but unfortunate.  Means things will be a little more interesting when it's hosted in IIS. 

So, that all works, but what I really need is for it to ask an STS for the correct token rather than creating one myself. 

I was hoping that putting this in my clientCredentials on the client side would do it

 

but it doesn't seem to. I'm assuming that's behavior that's built into the wsFederationHttpBinding, and not in wsDualHttpBinding. I'm hoping that I won't have to make the call to the STS myself, but as a last resort, that'll do...