2011-05-16 11 views
3

Existe-t-il des modèles éprouvés que tout le monde peut partager concernant les services Workflow 4.0 intégrés à Windows Identity Foundation? Nous recherchons le meilleur moyen d'inspecter le jeton et les revendications STS afin de déterminer qui est l'utilisateur en dehors du contexte de l'instance de service de flux de travail et de rendre l'objet utilisateur de l'application disponible pour le contexte de flux de travail.Services WF4 et intégration WIF

Nous souhaitons maintenir la séparation des préoccupations entre l'implémentation de service de WIF et la logique métier de workflow afin que nos services de workflow soient hautement testables. Nous avons vu quelques exemples qui pointent vers l'encapsulation de l'activité Receive avec une activité de code qui instancie une implémentation de IReceiveMessageCallback afin d'obtenir une référence à OperationContext. Link to Maurice's Blog Post. Cependant, cela signifie que les activités internes au service dépendent de l'existence du contexte d'opération et éventuellement de l'IClaimsIdentity. La meilleure solution que nous pouvons trouver jusqu'à présent est de créer une implémentation de IDispatchMessageInspector pour le service qui interroge le jeton et crée les objets utilisateur de l'application nécessaires au workflow pour les rendre disponibles au workflow via InstanceContext.Extensions. Cela semble fonctionner, mais ne se sent pas exactement solide. Toute aide ou rétroaction est grandement appréciée!

service Comportement

public class SecurityTokenServiceBehavior : IServiceBehavior, IDispatchMessageInspector 
{ 
... 
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext) 
    { 
     var claimsPrincipal = (IClaimsPrincipal)(Thread.CurrentPrincipal is GenericPrincipal ? null : Thread.CurrentPrincipal); 

     ... 

     instanceContext.Extensions.Add(new SecurityContextExtension(appUser, audit)); 
     return null; 
    } 
... 
} 

IReceiveMessageCallback

public class SecurityContextCallback : IReceiveMessageCallback 
{ 
    [DataMember] 
    public SecurityContextExtension SecurityContext { get; private set; } 

    public void OnReceiveMessage(OperationContext operationContext, ExecutionProperties activityExecutionProperties) 
    { 
     SecurityContext = operationContext.InstanceContext.Extensions.Find<SecurityContextExtension>(); 
    } 
} 

Répondre

0

Avez-vous vu this blog sur l'utilisation du ClaimsAuthorizationManager ainsi? L'utilisation de la ClaimsAuthorizationManager est la manière habituelle de vérifier l'autorisation lors de l'utilisation de WIF. Voir Dominick post here pour voir comment intégrer des contrôles dans votre code en utilisant l'attribut ClaimsAuthorize ou la méthode ClaimsAuthorize.CheckAccess() statique. Vous pouvez également jeter un coup d'œil au pack de sécurité WF CTP 1 here.

+0

Merci Maurice! Nous espérions que tu sauterais sur celui-ci. Nous avons rencontré le message ClaimsAuthorizationManager et prévoyons d'utiliser quelque chose de similaire pour l'autorisation spécifique à l'opération. Puisque WF Sec Pack est toujours CTP, nous ne nous sentons pas encore à l'aise avec l'implémentation en production. Outre l'autorisation, nous souhaitons utiliser le jeton sec pour créer un DTO identifiant l'utilisateur pour l'application et mis à la disposition de WF afin que les workflows n'aient pas à: 1) Envelopper les activités de réception avec une activité de code fournissant un IReceiveMessageCallback. 2) Avoir des dépendances WIF au sein de WF qui le rendent assez rigide pour tester – Capps