Question

This is something of an architectural question – I hope this is the right stack-exchange for this one – there doesn’t seem to be a natural home for these…

The systems I work on are distributed within a data-centre – web-servers in a DMZ then call web-services in a secure zone (through a firewall) for access to data. This currently uses asmx services with WSE, passing username and password credentials in the SOAP header. These are passed unencrypted. The view has been that this provides some measure of security (an attacker on the internet DMZ servers cannot access credentials for services accessed from the intranet DMZ server).

We’re looking to move to using WCF, but sticking with webservices. We’d like to use wsHttpBinding for best interoperability with other clients and for standards compliance. Continuing to use username authentication this seems to mandate using SSL or message encryption, which is seeming like overkill to a lot of people to be encrypting the connection within our own data-centre where we control both endpoints.

I’d be interested to know if this is what other people do and what alternatives we have. I’ve considered (and ruled out a few below)

• SecurityMode = None – don’t use any credentials. Our security people aren’t happy with this as attackers on the external web-servers could gain access to any services they like
• Use BasicHttpBinding – I think this can be configured to pass user credentials unencrypted using TransportCredentialOnly . However, somewhat concerned that BasicHttpBinding is intended as a legacy approach and less inter-operable with other technologies
• Use the Clear Username Binding – however, this is open source and my organisation don’t want to go near open source for legal reasons
• Accept that we have to move to encrypted messages even within the data-centre
• Change to using a different authentication type e.g. Windows credentials – concern that this is a potentially big change to how we currently operate these services and also whether we have access to a directory server from the DMZ.

Any thoughts on how other people use WCF within a data-centre with security zones would be greatly appreciated

Answer 1

Use BasicHttpBinding – I think this can be configured to pass user
credentials unencrypted using TransportCredentialOnly . However,
somewhat concerned that BasicHttpBinding is intended as a legacy
approach and less inter-operable with other technologies

Basic HTTP authentication is the most interoperable built-in authentication mechanism you can use however it sends passwords in a plain text. Also usage can have some little complications if you host your services in IIS and you don’t want to use windows accounts for authentication.

SecurityMode = None – don’t use any credentials. Our security people
aren’t happy with this as attackers on the external web-servers could
gain access to any services they like

Securing services in corporate environment is a must.

Change to using a different authentication type e.g. Windows
credentials – concern that this is a potentially big change to how we
currently operate these services and also whether we have access to a
directory server from the DMZ.

Once you start using Windows credentials you will have to use the same or trusted domains for both networks.

Much better option in this case are Certificates (CertificateOverTransport custom security mode). The problem with Basic authentication and UserNameToken authentication in WCF is that user name and password is transported as a plain text. That is also reason why WCF by default (and prior to .NET 4 always) demands encryption either through HTTPS or through message security. Any attacker (including internal attackers which are much more dangerous) can sniff communication either in DMZ or internal network and get all credentials he needs to access your services.

Once you start using certificates the certificate itself with the private key will be securely stored on the server in DMZ – you can even make the certificate non exportable. Once the DMZ application calls your internal service it will add information about the used certificate into SOAP header and signs the timestamp of the message. Anybody can verify the signature (and prove identity of the caller) but only holder of the private key can create one = even if attacker get access to network communication he will not be able to steal the identity. There are other security mechanism related to certificates.

UserNameToken (as you used in WSE) supports encrypted passwords but WCF doesn’t have this feature implemented.

To avoid requesting encryption for UserNameOverTransport or CertificateOverTransport you must use custom binding (works only in .NET 4 – prior version needs some KB from MS).