Posts tagged authz

I thought I posted the follow up but must’ve got sidetracked.

Scenario:
User John does an update request on John.Manager => launches authorization workflow, which uses the public client to create a request to the middle tier on John’s behalf?

If you enable delegation on your public proxy WCF bindings, you can in your activities impersonate the user credentials with this call:
(actually, you may only need to be impersonation since you’re impersonated call never leaves the box to talk to the fim service)

ServiceSecurityContext.Current.WindowsIdentity.Impersonate();

Then, if you use the public client in your code to make calls to the fim service, you will be under that user’s credentials and can kick off other necessary MPRs.

Couple of salient points:

1. All code that follows that impersonation call will be under the users credentials. Makes sense right? So what happens if you have a create activity or an update activity in your workflow? It fails b/c that thread is under the user context so any connections to the sql fim store to run any sprocs will fail b/c that user doesn’t have access to the DB.

2. ServiceSecurityContext is backed by a [ThreadStatic] attribute. ThreadStatic means an variable is scoped only to the current thread. Which means if you fork a new thread, that context is lost. So why does this matter to us? Well, when workflows passivate or get persisted to the DB (ex: when an activity is waiting on input from an approver), that context gets lost. So when your code comes back up, you no longer have access to ServiceSecurityContext.

3. If you’re under the impersonated context when the workflow passivates….wild things may happen. Haven’t tested it.

4. You no longer have parenting of requests. There are no longer chains of requests so if you cancel a parent request, the new request you spawned may

5. You have to handle the logic of how to wait on the new request you just spawned: does your activity proceed if there’s an authz workflow kicked off? Does it wait on the input? What if there’s an authn workflow? Does it handle the child requests interactive action workflows? Yup, it’s very nasty and hairy to solve in the general case (there is a reason why the FIM team doesn’t have this enabled by default)

Here’s what I would suggest (haven’t had time to fully explore this, just used this to implement delegation as a proof of concept):

1. Store the WindowsIdentity locally when overriding OnActivityExecutionLoad

2. Have very simple defined cases of when you kick off requests that spawn new AuthZ workflows. Don’t try to solve the general case. Any case that requires chainign of requests => pain

3. Keep the impersonation scope very limited and defined:

using(ServiceSecurityContext.Current.WindowsIdentity.Impersonate())

{

//Code to call public client to talk to FIM service

}//Impersonation is always reverted this way

4. For auditing/reporting, the child request that gets created this way will have the user as the actorID. Just be aware.