wcf security
DESCRIPTION
Overview of the different security options in WCF, both through configuration and codeTRANSCRIPT
www.orbitone.com
Raas van Gaverestraat 83B-9000 GENT, Belgium E-mail [email protected] Website www.orbitone.com
Tel. +32 9 265 74 20Fax +32 9 265 74 10VAT BE 456.457.353Bank 442-7059001-50 (KBC)
22 May, 2009 Windows Communication Foundation Security, by Tom Pester
22 May, 2009Windows 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.
22 May, 2009Windows 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.
22 May, 2009Windows 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.
22 May, 2009Windows 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.
22 May, 2009Windows 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.
22 May, 2009Windows 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>
22 May, 2009Windows 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
22 May, 2009Windows 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.
22 May, 2009Windows 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>
22 May, 2009Windows 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
22 May, 2009Windows Communication Foundation Security, by Tom Pester12
Messages are unencrypted over a channel stack that is unsecure
22 May, 2009Windows Communication Foundation Security, by Tom Pester13
Messages are encyrpted over a channel stack that is unsecure
22 May, 2009Windows 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.)
22 May, 2009Windows 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).
22 May, 2009Windows 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
22 May, 2009Windows 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.
22 May, 2009Windows 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.
22 May, 2009Windows 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
22 May, 2009Windows Communication Foundation Security, by Tom Pester20
<basicHttpBinding> <binding name="basicHttp"> <security mode="TransportWithMessageCredential"> <message clientCredentialType="Certificate"/> </security> </binding></basicHttpBinding>
22 May, 2009Windows 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 May, 2009Windows Communication Foundation Security, by Tom Pester22
[ServiceContract(Name="HelloIndigoContract", Namespace="", ProtectionLevel=ProtectionLevel.Sign)]public interface IHelloIndigoService{ string HelloIndigo(string inputString);}
22 May, 2009Windows 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.
22 May, 2009Windows 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>
22 May, 2009Windows 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>
22 May, 2009Windows 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>
22 May, 2009Windows 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}
22 May, 2009Windows 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.
22 May, 2009Windows 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(){ ...}
www.orbitone.com
30 Windows Communication Foundation Security, by Tom Pester22 May, 2009