Wednesday, December 08, 2010 12:05 AM
I'm using hosted workflow services that are integrated into a WIF STS. The workflows look at Thread.CurrentPrincipal.Identity to get information about the authenticated user. I then configured the service (via AppFabric) to use workflow persistence so that I can call a service that previously failed (workflowUnhandledException action="Abandon"). As soon as persistence was configured, all authentication information about the user was lost in the workflow.
How can I maintain the authenticated users security information when using workflow persistence?
Thursday, December 09, 2010 7:35 AMModeratorHi, Rory
->"How can I maintain the authenticated users security information when using workflow persistence?"
One solution is:
1. Create a new table in the persistence database.
2. Use PersistenceParticipant to store authenticated user info in the new created table.
In this way, authentication info is 100% in your control. and will not be deleted by the workflow runtime.
Hope this helps
This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support. My Blog:http://xhinker.com "Microsoft Windows Workflow Foundation 4.0 Cookbook"
Thursday, December 09, 2010 7:49 AM
Thanks for the reply. I tried that one and unfortunately it's a no-go.
It seems that the Thread.CurrentPrincipal has already been wiped out by the time anything happens in WF. I think the only solution is to store the credentials (somewhere????) first via a WCF extension point and then obtain them again from that place once the workflow starts executing. At that point it could then go into a PersistenceParticipant extension.
It seems like the workflow is persisted before any execution (which is what msdn doco says happens) in such a way that the credentials are wiped before the workflow (or first activity) is scheduled.
Any other ideas?
Friday, December 10, 2010 12:17 AM
Zulfiqar (http://zamd.net/2010/07/04/using-wif-with-workflow-services/) and Maurice (http://msmvps.com/blogs/theproblemsolver/archive/2010/09/21/using-the-wcf-operationcontext-from-a-receive-activity.aspx) have the answer.
The reason I didn't think this would work is because WIF documentation says that you cannot use ServiceSecurityContext to get the identity and that it can only be obtained from Thread.CurrentPrincipal.
As a note, when WIF is enabled inside WCF, the WCF
ServiceSecurityContextdoes not work for obtaining the caller’s identity and claims; the application code must use the IClaimsPrincipal to access the caller’s information. You can obtain the IClaimsPrincipal instance using
Thread.CurrentPrincipal. This is available for every authentication type as soon as WIF is enabled for the WCF application.
It looks like the identity is still available via OperationContext.Current.ServiceSecurityContext when the Receive activity executes at this point in the WCF/WIF/WF pipeline.
I'm putting together my own activity that is specific to returning an IIdentity based on the above two implementations.
- Marked As Answer by Rory_Primrose Friday, December 10, 2010 12:17 AM