Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>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</p> </blockquote> <p>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. </p> <blockquote> <p>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</p> </blockquote> <p>Securing services in corporate environment is a must.</p> <blockquote> <p>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.</p> </blockquote> <p>Once you start using Windows credentials you will have to use the same or trusted domains for both networks. </p> <p>Much better option in this case are Certificates (<code>CertificateOverTransport</code> 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. </p> <p>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.</p> <p>UserNameToken (as you used in WSE) supports encrypted passwords but WCF doesn't have this feature implemented. </p> <p>To avoid requesting encryption for <code>UserNameOverTransport</code> or <code>CertificateOverTransport</code> you must <a href="https://stackoverflow.com/questions/4725096/how-to-use-message-security-and-username-clientcredentialtype-without-certificat#4725161">use custom binding</a> (works only in .NET 4 - prior version needs some KB from MS).</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload