# Monday, 26 March 2007

A very common banking scenario is one in which Customer Service Reps (CSRs) need to act on behalf of a given user to help them through problems.  This usually occurs when a customer calls a bank, and the CSR needs to essentially log into the online banking system "as" that customer, but without knowing that user's password. 

Once they are logged in, there are some things you'd like them NOT to be able to do, like create a new bill payment payee and send bill payments to it.  'Cause that's bad.

I'm trying to figure out how that would be modeled in AzMan, since as near as I can figure there's not such thing as an explicit "deny" in AzMan.  All rights are essentially additive, and if any of a user's roles includes a grant, access is granted.  At least that's the way it seems to behave, I could be wrong. 

In a perfect world, we'd like to be able to simply model "the CSR can do everything the user can, except...". 

The only way I can figure to make this work in AzMan right now is to create the CSR role with access to all operations except those on the deny list, then when the CSR logs in, do restrict the AccessCheck against AzMan to only the CSR role, by setting the IAzClientContext's RoleForAccessCheck property.  That way, only the CSR's rights are evaluated, even if they are assigned to other roles as well. 

Not ideal, but at least it's easy to understand...

Monday, 26 March 2007 14:40:32 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Thursday, 15 March 2007

Donovan Follette, ADAM/AzMan/Identity Evangelist at Microsoft, has posted a set of links to some videos, whitepapers, and case studies on using AzMan.  Not only are these great resources, but it's great to see Donovan working to make sure that AzMan doesn't stay the "best kept secret" in Windows 2003 Server. 

One of the big questions we've had around using AzMan has been "is anyone actually using this thing?", so it's very cool to get our hands on some real case studies to answer that question in the affirmative.

Thanks Donovan!

Thursday, 15 March 2007 13:57:36 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

I'm just starting to look into the feasibility of implementing complex constraints in the world of AzMan.  I've already discovered how easy it is to create simple "accessibility" constraints (i.e. can user x execute operation y), but now we need a solution for what we think of as "parameterized" constraints, like can user x execute the transfer operation if the total amount user x wants to transfer is $y.

AzMan certainly provides the capability, in the for of "BizRules", which are scripts that can be attached to roles and other objects to perform exactly this kind of evaluation.  When your application calls CheckAccess, it can pass a set of parameters to evaluate, as well as additional objects, etc.  I have two main concerns about this that I'm going to spend the next week or so evaluating...

  1. Is this going to give us the performance we need?
  2. Is the interface too cumbersome?

Both of those concerns stem from the fact that the only interface currently provided to AzMan is COM based, which means that I'm forced to write my scripts in VBScript of JScript, and I have to pass COM objects (or at least COMVisible objects) for all my parameters at evaluation time.  That means potentially some extra marshalling overhead, although I think there are ways around that.  It also makes the interface to CheckAccess a bit clunky.

I guess I'll find out...

Thursday, 15 March 2007 13:21:44 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [3]  | 
# Wednesday, 07 March 2007

This is mostly an annoyance, but I've noticed that every time I try to attach the VisualStudio 2005 debugger to the w3wp.exe process (to debug a WCF service hosted in IIS, on Windows 2003 Server), the Attach to Process dialog automatically tries to debug Workflow and T-SQL code, not managed code.  This then causes VS.NET to crash instead of attaching the debugger. 

When I remember to set it manually to Managed instead, everything works just fine.  The drag is that there doesn't seem to be an obvious way to turn off the automatic selection.  Every time I start this process, I forget, crash the app, then remember to select manually.  Costs some extra time I'd rather not spend.

I suppose on the other hand, I could just pay more attention.

Wednesday, 07 March 2007 10:58:26 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 

It's highly encouraging to me that MS is continuing investment in ADAM.  There have been a number of naming changes for "Longhorn" Server, and ADAM hasn't escaped.  The new name is ADLDS, for Active Directory Lightweight Directory Services.  A much more appropriate name, since it says exactly what ADAM does.  It's the LDAP part, without the NOS bits of AD. 

I've noticed that the name change even shows up in a few places on the Windows 2003 Server site, which is a bit confusing.

Anyway, the take away is that not only is ADAM not going away, but it's a part of the platform that MS is committed to not only supporting but improving.  Does my heart good.

Wednesday, 07 March 2007 10:29:34 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 26 February 2007

It looks like the issue I've been having with calling AzMan via PowerShell via MMC have nothing to do with PowerShell, and is probably an AzMan issue.  I tried exactly the same scenario, but accessed a different path with my drive provider that ultimately makes a COM call to ADAM, rather than AzMan, and it worked just fine.  That makes me think it's something about the AzMan implementation. 

However, I still need to call my PowerShell drive provider from MMC, and that problem has been resolved, (many) thanks to Bruce Payette

Turns out that there's a way to get PowerShell to run in the caller's thread, rather than creating its own MTA thread.  This means that my PowerShell code will get called from MMC's STA thread directly, and the AzMan interfaces get created just fine.  Woohoo!

Previously, I was creating the Runspace and calling it thusly...

RunspaceConfiguration config = RunspaceConfiguration.Create();
PSSnapInException warning;
//load my drive provider
PSSnapInInfo info = config.AddPSSnapIn(snapInName, out warning); 
Runspace rs = RunspaceFactory.CreateRunspace(config);
rs.Open();
...
create Command object with right parameters
...
Collection<PSObject> results;
using (Pipeline pipeline = _runspace.CreatePipeline())
{
    pipeline.Commands.Add(command);
    results = pipeline.Invoke();
}

This wasn't working, I believe because MMC is calling this code on an STA thread, and PowerShell is creating its own MTA thread, which doesn't seem to be acceptible to AzMan (not sure why).

However, according to Bruce's suggestion, I changed it to look like this...

Runspace rs = RunspaceFactory.CreateRunspace();
rs.Open();
PSSnapInException warning;
//load my drive provider
rs.RunspaceConfiguration.AddPSSnapIn(snapinName, out warning);
Runspace.DefaultRunspace = rs;
EngineIntrinsics _exec = rs.SessionStateProxy.GetVariable("ExecutionContext") as EngineIntrinsics;
ScriptBlock sb = _exec.InvokeCommand.
    NewScriptBlock("my script block");
Collection<PSObject> results = sb.Invoke();

This causes the PowerShell call to happen on the caller's (MMC's) thread, and everyone is happy. 

Monday, 26 February 2007 11:09:26 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Thursday, 22 February 2007

Update:  OK this is even wierder.  If I call into the PowerShell Runspace from inside a WinForms app marked STAThread, but first I create my own MTA thread and use it to make the call to the Runsapce, everything works.  However, from within MMC, even if I create the MTA thread myself to call the Runsapace on, it fails with the same "Interface not registered" error.

 

 

Our plan is to build PowerShell Cmdlets and drive providers to expose our management interfaces, then layer an MMC interface on top of them to provide a GUI management tool. 

Yesterday, I ran into the first hitch in that plan...

My PowerShell drive provider makes use of the AzMan COM interfaces to deal with Operations, Roles, and Tasks.  That works great from within PowerShell, and it does all the stuff it needs to.  However, when I started running the PowerShell stuff through a Runspace inside of MMC, the AzMan calls started failing with "Interface not registered".  Hmm.  So, on a hunch, I tried the same PowerShell calls (again using a Runspace) inside a WinForms app.  Same problem.  Even though they work fine in PowerShell (which obviously makes me doubt that the interface isn't registered). 

On another hunch, I changed the COM threading model attribute on the WinForms app from [STAThread] to [MTAThread].  Everything worked just peachy.  Dang. 

Turns out that MMC always calls snap-ins on an STA thread, and for the life of my I can't find any way to change that behavior.  I still don't know why the problem manifests itself quite this way.

To further qualify the problem, I called the AzMan interfaces directly from within the WinForms app, and it worked in both STA and MTA threads.  So apparently it has something to do with launching the Runspace from an STA thread, and then making the COM calls from PowerShell (which uses an MTA thread). 

I'm hoping that I won't have to abandon the MMC -> PowerShell concept for this particular part of the product, but right now I'm not sure how to resolve this.

Thursday, 22 February 2007 12:57:24 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 21 February 2007

Rhapsody (my online music provider of choice) has continued to make improvements to their online, browser based version of their music player.  The most recent addition is support for the "My Library" feature that's long been present in their desktop player.  You can add albums or songs to your library for future recall, rather than having to search for them again, and just like in the desktop client, it's portable across machines.

Since I've had nothing but trouble with their desktop client lately, this makes the online version a lot more attractive.  It works in Firefox, and supposedly even under Linux, which is pretty sweet.  $25 bucks a quarter, zillions of albums, and works anywhere there's a 'net connection.  Can't beat that.

Wednesday, 21 February 2007 10:42:43 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 19 February 2007

I'm finally taking the time to get to know PowerShell, and I'm pretty much as impressed as I expected to be given the rave reviews from Scott and others. 

In rewriting our core platform, we're committed to exposing management operations through both PowerShell and MMC, so I've been building out some PS Cmdlets, and now a "drive provider" to make it easy for an end user to navigate through our authentication system.  In the end, the user will be able to "CD" into our authentication system, and navigate the available groups (ADAM) roles, and operations (both from AzMan) like they were directories and files in a file system. 

It's taken me a while to get my head around the PS drive provider model, but now that I (mostly) have, I totally get how flexible a model it is.  You can choose different levels of functionality to support, including adding new items to the tree, "cd"-ing into multiple levels of hierarchy, etc.  Once I grokked the stateless model used by the drive providers, it made sense as an easy way to expose hierarchical data to PS, in a way that's intuitive to users. 

Once that stuff is done, we'll layer an MMC interface on top of the PS Cmdlets, so we won't have to reinvent the wheel functionality wise. 

Very exciting times...

ADAM | AzMan | Work | PowerShell
Monday, 19 February 2007 11:06:24 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 15 February 2007

I just finished a couple of pretty interesting books...

 


The Devil's Teeth: A True Story of Obsession and Survival Among America's Great White Sharks

The Devil's Teeth is all about a journalist who gets involved with the biologists studying great white sharks in the Farallones, islands about 20 miles due West of San Francisco.  It's an interesting portrait, not only of the harsh reality of life for a shark, but of the harsh reality of the people who live to study them.  Not an easy job.  Unfortunately, the author's obsession with the sharks leads to her violation of the rules of the study, which ultimately result in the lead biologist losing his job.  I notice that part gets downplayed significantly.  Other than that, it's a very well written account.

 


Adrift: Seventy-six Days Lost at Sea

 Adrift is about the truly remarkable adventure of Steven Callahan, who survived in an inflatable life raft for 76 days in the North Atlantic.  Only one other man is recorded as having survived at see that long solo.  Callahan's sailboat was sunk (he thinks by running into a whale) while only a few days out from the Canary Islands, headed for the Caribbean.  Using only the tools in his raft and survival kit, he manages to provide himself with enough food and water to make it all the way to Guadeloupe, where he was rescued by some fishermen.  Callahan showed some pretty amazing competence and ingenuity, which makes this a very interesting read.

Thursday, 15 February 2007 10:30:00 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  |