Question: I've a workflow that use a Business layer (in a separated dll)
This Business Layer check permissions using the IPrincipal roles, so workflow activities must set the Principal on current thread before calling a method on the business layer.

I've a problem when a wrokflow is resumed after a delay activity: the roles / IIdentity are lost (or worse: are wrong).

Does someone have an idea on how I can handle this case and be sure that, when resuming, it uses the IPrincipal set before the delay ?
Or do you have any idea on how to manage roles in workflows ?

Thank you!

Answer: 
My way around this has been to store the original principal as a workflow variable (IClaimsPrincipal in my case).

This has two advantages. 

Firstly, it was persisted so that if the workflow was persisted then resumed, the original principal was still there. This was also important because the original context from which the principal was obtained may no longer be available when the workflow resumes.

Secondly (specifically for workflow services), it allowed me to check whether the principal continuing the workflow by calling another service operation (essentially the same logical session via correlation) is the same user that started the session (the same principal as the variable).
The authentication information may still be available via OperationContext.Current.ServiceSecurityContext- the following articles might be of help:

<http://zamd.net/2010/07/04/using-wif-with-workflow-services/>
http://msmvps.com/blogs/theproblemsolver/archive/2010/09/21/using-the-wcf-operationcontext-from-a-receive-activity.aspx