Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

WCF security

on

  • 2,818 views

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

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

Statistics

Views

Total Views
2,818
Views on SlideShare
2,818
Embed Views
0

Actions

Likes
3
Downloads
135
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

WCF security WCF security Presentation Transcript

  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    2
    To understand WCF security we have to explore the basic set of security principals for authentication, authorization, and message transfer protection.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    3
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    4
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    5
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    6
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    7
    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>
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    8
    Lets look at the expanded binding configuration illustrating the default settings.
    <netTcpBinding>  <binding name="netTcp">    <security mode="Transport">      <transport clientCredentialType="Windows" />    </security>  </binding></netTcpBinding>
    NetTcpBindingis 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
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    9
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    10
    For example, this <wsHttpBinding> snippet illustrates how to require UserNamecredentials be passed with the message.
    <wsHttpBinding>  <binding name="wsHttp">    <security mode="Message">      <message clientCredentialType="UserName" />    </security>  </binding></wsHttpBinding>
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    11
    Transfer protection
    Transport vs. Message
    Transport protection is only good from point-to-point.
    Message protections is good end-to-end
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    12
    Messages are unencrypted over a channel stack that is unsecure
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    13
    Messages are encyrpted over a channel stack that is unsecure
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    14
    Messages are unencyrpted over a channel stack that is secure(If the channel were unsecure, you could see the messages in clear text.)
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    15
    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).
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    16
    Messages are unencyrpted over an secure channel between the client and the service endpoint (1st hop).  Notice the messages DO NOT remain encryptedbetween the first service
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    17
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    18
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    19
    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
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    20
    <basicHttpBinding>  <binding name="basicHttp">    <security  mode="TransportWithMessageCredential">      <message  clientCredentialType="Certificate"/>    </security>  </binding></basicHttpBinding>
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    21
    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 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    22
    [ServiceContract(Name="HelloIndigoContract", Namespace="", ProtectionLevel=ProtectionLevel.Sign)]public interface IHelloIndigoService{  string HelloIndigo(string inputString);}
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    23
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    24
    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>
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    25
    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>
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    26
    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">
    <serviceAuthorizationprincipalPermissionMode ="UseAspNetRoles"
    roleProviderName ="SqlProvider" />
    </behavior>
    <!-- Other configuration code not shown. -->
    </behaviors>
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    27
    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}
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    28
    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.
  • 22 May, 2009
    Windows Communication Foundation Security, by Tom Pester
    29
    Using the OperationBehaviorAttributeyou 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
    Windows Communication Foundation Security, by Tom Pester
    22 May, 2009