# Thursday, 05 April 2007

Donovan posted a link to the latest Channel 9 screencast on AzMan, in which Keith Brown talks about some of the new features coming up in the Longhorn Server version of AzMan.  It's a good video, and very encouraging to me, because it looks like the things the AzMan team has added for Longhorn are exactly the things I would have wanted. 

The programmatic interface is much simplified (thank you) and there's a new plugin model for the admin tool which allows you to work with custom principles such as ADAM principals from within the AzMan MMC snapin. 

Another interesting feature calls BizRule groups allows you to define ad hoc groups defined by script, which can then be associated with roles at runtime.  The example in the video created a group consisting of the current user's direct manager, and then assigning that group with an expense approver group.  This is a cool idea, but I'm reluctant to go back to defining application logic in VB script.  The one thing I really wish the team had done for Longhorn would be to create a managed interface for AzMan, and let us get away from COM (finally).  Since I'm writing the rest of my application in C#, I don't really want to have to maintain and deploy a bunch of COM based scripting files.  I'm not too concerned about the "COM overhead" involved with calling AzMan interfaces, but the scripting part is lame.

I'm looking forward to testing some of the new features, and trying out the performance improvements.

Thursday, 05 April 2007 10:32:08 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 04 April 2007

Scott posted today about "Mindful Coding" or "Coding Mindfully", meaning "paying full attention to what you are doing while coding".  It's an easy thing to say, and a very hard thing to do.  We are so habitualized, as a society, to not pay full attention to much of anything that it's hard to really focus on what's happening right now.  I know that between email, questions, lunch, etc. it's difficult for me to focus on the code I'm writing at any given moment.  If nothing else, it's tempting to think about how the code you are writing now will interact with or influence the code you right tomorrow or next week, or the code your neighbor is writing that you have to integrate with.  Before you know it, you aren't really paying full attention to what you are writing.  Personally, this is where I get a lot of value out of refactoring. 

Refactoring allows you to fix the problems caused by wandering attention, if it's done often enough.  Several of the commenters on Scott's post also note that pair programming is a good remedy, and I agree.  When you are collaborating with someone else, you have to focus on the collaboration, which leads to mindfulness about what you are doing right now. 

Go forth and be mindful...

Wednesday, 04 April 2007 14:48:33 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 

Since there's not way to manage an explicit "Deny" in AzMan like there is with ACL's, that has some influence on the way in which we will have to define roles.  Let's say I have a group hierarchy like this...

  • Ray's Bakery
    • Admins
    • Bill Payers
    • Corporate Headquarters
      • Finance
      • Payroll

If we have the ability to deny, we might give rights to all operations to the top level "Ray's Bakery", and then deny rights to "Payroll" for example that we don't want that group to have, but are OK for "Finance".  It's relatively easy to understand, and has the advantage of being not very much work. 

Because of the way AzMan works, however, we have to work from the top of the hierarchy down, going from most restrictive to least restrictive.  In other words, we can only assign rights to the "Ray's Bakery" group that we want ALL users to have, then grant additional rights as we go down the tree.  We might want everyone in Finance and Payroll to be able to see balances, so those rights could be assigned at the "Corporate HQ" level, while rights to transfer money from one corporate account to another might be granted only to Finance, and rights to wire transfers only to Payroll.  This should also be pretty easy to understand, but it does require a bit more thinking about.  I think a good test tool will help make it clear to users who has what rights, so it shouldn't be too hard to follow. 

For the sake of clearing up any implementation details, what I'm really describing are hierarchical groups in ADAM, which are associated with AzMan roles, so when I say "assign rights at the Finance level", I mean that the group SID for the Finance group in ADAM will be associated with an AzMan role called something like RaysBakeryFinance, which is in turn associated with the operations or tasks that comprise wire transfers. 

Wednesday, 04 April 2007 13:51:28 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  | 
# 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);
create Command object with right parameters
Collection<PSObject> results;
using (Pipeline pipeline = _runspace.CreatePipeline())
    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();
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]  |