Successfully reported this slideshow.

WCF security

3,035 views

Published on

Overview of the different security options in WCF, both through configuration and code

Published in: Technology, Business
  • Be the first to comment

WCF security

  1. 1. www.orbitone.com Raas van Gaverestraat 83 B-9000 GENT, Belgium E-mail info@orbitone.com Website www.orbitone.com Tel. +32 9 265 74 20 Fax +32 9 265 74 10 VAT BE 456.457.353 Bank 442-7059001-50 (KBC) 22 May, 2009 Windows Communication Foundation Security, by Tom Pester
  2. 2. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester2  To understand WCF security we have to explore the basic set of security principals for authentication, authorization, and message transfer protection.
  3. 3. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester3  Consider a message from sender to receiver  Authentication. We typically think about authentication as identifying the message sender. Mutual authentication involves authenticating both the sender and the message receiver, to prevent possible man-in-the-middle attacks.  Authorization. After authenticating the message sender, authorization determines what system features and functionality they are entitled to execute.  Integrity. Messages should be digitally signed to ensure they have not been altered between sender and receiver.  Confidentiality. Sensitive messages should be encrypted to ensure they cannot be openly viewed on the wire.
  4. 4. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester4  A variety of mutual authentication mechanisms are supported using token formats such as Windows tokens, username and password, certificates and issued tokens (in a federated environment)  Authorization can be based on Windows roles, ASP.NET roles or you can provide custom authorization policies.
  5. 5. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester5  The first step to securing a WCF service is defining the security policy. Once you have established requirements for authentication, authorization, and message protection it is a matter of service configuration to enforce it.
  6. 6. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester6  Your binding selection will influence the available configuration options  Beyond bindings, behaviors also provide information about client and service credentials, and affect how authorization is handled.
  7. 7. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester7  Each binding has a default set of security settings. Consider the following service endpoint that supports NetTcpBinding.  <system.serviceModel> <services> <service name="HelloIndigo.HelloIndigoService" > <endpoint contract="HelloIndigo.IHelloIndigoService" binding="netTcpBinding" /> </service> </services> </system.serviceModel>
  8. 8. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester8  Lets look at the expanded binding configuration illustrating the default settings.  <netTcpBinding> <binding name="netTcp"> <security mode="Transport"> <transport clientCredentialType="Windows" /> </security> </binding> </netTcpBinding>  NetTcpBinding is secure by default. Specifically, callers must provide Windows credentials for authentication and all message packets are signed and encrypted over TCP protocol.  In fact all standard bindings are secure by default except for Basic Http binding
  9. 9. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester9 Security Mode  Across all service bindings there are five possible security modes:  None. Turns security off.  Transport. Uses transport security for mutual authentication and message protection.  Message. Uses message security for mutual authentication and message protection.  Both. Allows you to supply settings for transport and message-level security (only MSMQ supports this).  TransportWithMessageCredential. Credentials are passed with the message and message protection and server authentication are provided by the transport layer.  TransportCredentialOnly. Client credentials are passed with the transport layer and no message protection is applied.
  10. 10. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester10  For example, this <wsHttpBinding> snippet illustrates how to require UserName credentials be passed with the message.  <wsHttpBinding> <binding name="wsHttp"> <security mode="Message"> <message clientCredentialType="UserName" /> </security> </binding> </wsHttpBinding>
  11. 11. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester11 Transfer protection  Transport vs. Message  Transport protection is only good from point-to-point.  Message protections is good end-to-end
  12. 12. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester12  Messages are unencrypted over a channel stack that is unsecure
  13. 13. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester13  Messages are encyrpted over a channel stack that is unsecure
  14. 14. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester14  Messages are unencyrpted over a channel stack that is secure (If the channel were unsecure, you could see the messages in clear text.)
  15. 15. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester15  Messages are encyrpted over an unsecure channel between the client and the service endpoint (1st hop). Notice the messages remain encrypted between the first service and second service (2nd hop).
  16. 16. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester16  Messages are unencyrpted over an secure channel between the client and the service endpoint (1st hop). Notice the messages DO NOT remain encrypted between the first service
  17. 17. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester17  Message security supports passing credentials as part of the SOAP message using interoperable standards, and also makes it possible to protect the message independent of transport all the way through to the ultimate message receiver.
  18. 18. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester18  Transport security is point to point. Since the messages themselves are not encrypted, once they go to another point, they can be potentially exposed to integrity/privacy attacks as if they were unsecure.  The big advantage of message security is that it provides end to end security. Messages leaving intermediary services retain their security.
  19. 19. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester19 Client Credential Type  The choice of client credential type depends on the security mode in place. Message security supports any of the following settings for clientCredentialType:  None  Windows  UserName  Certificate  IssuedToken
  20. 20. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester20  <basicHttpBinding> <binding name="basicHttp"> <security mode="TransportWithMessageCredential"> <message clientCredentialType="Certificate"/> </security> </binding> </basicHttpBinding>
  21. 21. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester21 Protection Level  By default, all secure WCF bindings will encrypt and sign messages. You cannot disable this for transport security, however, for message security you may wish to disable this for debugging purposes.  Protection-level settings are controlled by the contract.
  22. 22. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester22  [ServiceContract(Name="HelloIndigoContract", Namespace= "", ProtectionLevel=ProtectionLevel.Sign)] public interface IHelloIndigoService { string HelloIndigo(string inputString); }
  23. 23. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester23  For more granular control, you can also indicate message protection per operation using the OperationContractAttribute.  [ServiceContract(Name="HelloIndigoContract", Namespace=] public interface IHelloIndigoService { [OperationContract(ProtectionLevel= ProtectionLevel.Sign)] string HelloIndigo(string inputString); }  ProtectionLevel options are: None, Sign, and EncryptAndSign.
  24. 24. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester24 Algorithm Suite  Choice of algorithm suite can be particularly important for interoperability.  Each binding uses Basic256 as the default algorithm suite for message-level security  <wsHttpBinding> <binding name="wsHttp"> <security mode="Message"> <message clientCredentialType="UserName” algorithmSuite="TripleDes" /> </security> </binding> </wsHttpBinding>
  25. 25. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester25 Secure Session  Another feature of message security is the ability to establish a secure session to reduce the overhead of key exchange and validation.  A token is generated through an initial exchange between caller and service. This token is used to authorize and secure subsequent message exchanges.  <wsHttpBinding> <binding name="wsHttp"> <security mode="Message"> <message clientCredentialType="UserName" establishSecurityContext="false" /> </security> </binding> </wsHttpBinding>
  26. 26. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester26 Authorisation  <system.web> <membership defaultProvider="SqlProvider" userIsOnlineTimeWindow="15"> <providers> <clear /> <add name="SqlProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="SqlConn" applicationName="MembershipProvider" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" passwordFormat="Hashed" /> </providers> </membership> <!-- Other configuration code not shown.--></system.web>  <behaviors>  <behavior name="ServiceBehaviour">  <serviceAuthorization principalPermissionMode ="UseAspNetRoles"  roleProviderName ="SqlProvider" />  </behavior>  <!-- Other configuration code not shown. -->  </behaviors>
  27. 27. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester27  Imperatively  public string AdminsOnly() { // unprotected code PrincipalPermission p = new PrincipalPermission(null, "Administrators"); p.Demand(); // protected code }  Or declaratively  [PrincipalPermission(SecurityAction.Demand, Role = "Administrators")] public string AdminsOnly() { // protected code }
  28. 28. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester28 Impersonation  When Windows credentials are used, the service can be configured to impersonate callers so that the request thread operates under the impersonated Windows token.  This makes it possible for services to access protected Windows resources under the identity of the caller, instead of the process identity of the service-for that request.  This can be dangerous and I consider it bad practice.
  29. 29. 22 May, 2009 Windows Communication Foundation Security, by Tom Pester29  Using the OperationBehaviorAttribute you can apply impersonation rules per operation by setting the Impersonation property to one of the following:  ImpersonationOption.NotAllowed. The caller will not be impersonated.  ImpersonationOption.Allowed. The caller will be impersonated if a Windows credential is provided.  ImpersonationOption.Required. The caller will be impersonated and a Windows credential must be provided to support this.  This behavior is applied to service operations. [OperationBehavior(Impersonation = ImpersonationOption.Allowed)] public string DoSomething() { ... }
  30. 30. www.orbitone.com 30 Windows Communication Foundation Security, by Tom Pester 22 May, 2009

×