Unterschiedliche Sicherheit für verschiedene Dienstvorgänge in WCF

Question

Ich entwerfe und teste WCF-Dienste und stelle sie als SOAP-Webdienste zur Verfügung.

Ich habe meine Service-Klassen logisch unterteilt. Ich habe einen Account-Service. Um auf den Konto-Webdienst zugreifen zu können, müssen Sie einen Benutzernamen und ein Passwort sowie ein API-Token angeben. Ich schrieb eine benutzerdefinierte Klasse, die UserNamePasswordValidator zur Überwachung der Authentifizierung und einen IDispatchMessageInspector zur Überprüfung auf das Token erweiterte.

Eine Anforderung ist gerade aufgetaucht, wo wir eine Kontoüberprüfung bereitstellen möchten, ohne dass der Benutzer authentifiziert wird. Logisch sollte dieser Vorgang im Account Service bleiben. Der Dienst Verhalten ist jedoch so konfiguriert, dass er einen Benutzernamen, ein Kennwort und einen IServiceBehavior erfordert, der einen IDispatchMessageInspector hinzufügt, der alle Massagen für ein Token überprüft.

Ich habe all die verschiedenen Erweiterungspunkte über Extending Dispatchers - Microsoft und WCF Extensibility - Carlos Figueira

bewerten kann ich scheinen, einen Weg zu finden, um nur die Sicherheit auf der Betriebsebene gelten. Oder eine Möglichkeit, den Dienst so zu konfigurieren, dass bestimmte Funktionen Sicherheit/Token und andere nicht erfordern.

Ich bin neu in WCF, also könnte es etwas einfaches sein, aber ich habe es nicht gefunden. Wenn Sie einen Artikel kennen, der zeigt, wie Sie verschiedene Teile eines Dienstes auf unterschiedliche Weise sichern können, oder wenn Sie wissen, wie Sie dies tun, geben Sie mir bitte einige Informationen. Vielen Dank.

Answer 1

Da Sie Berechtigungen auf Vorgangsebene zulassen/verweigern möchten, können Sie Ihre Methoden mit PrincipalPermission Attribut festlegen.

können Sie wie folgt verwenden:

[PrincipalPermission(SecurityAction.Demand,Authenticated=false)] 
void NotAutenticationRequiredMethod() 
[PrincipalPermission(SecurityAction.Demand,Authenticated=true)] 
void AuthenticationRequiredMethod() 

Wie Sie etwas mehr „flexibel“ möchten, können Sie auch Rollen verwenden, so dass keine erneute Kompilierung erforderlich:

[PrincipalPermission(SecurityAction.Demand, Role = "CustomRole")] 

können Sie mehr lesen hier: https://msdn.microsoft.com/en-us/library/ff649821.aspx

Auf Methodenebene können Sie auch den OperationContext.Current.ServiceSecurityContext überprüfen Objekt, um zu überprüfen, ob die Anfrage von einem authentifizierten Benutzer stammt und eine Entscheidung trifft.

Denken Sie daran, dass Security verschiedene Authentifizierungen haben: hier mehr

string primaryIdentity = OperationContext.Current.ServiceSecurityContext.PrimaryIdentity.Name; 

string windowsIdentity = OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Name; 

lesen: https://sankarsan.wordpress.com/2010/07/25/identity-securitycallcontext-in-wcf/

Hoffe, es hilft.