none
What is the Difference between UserNameForSslNegotiated & UserNameForCertificate? RRS feed

  • Question

  • Could someone please elaborate on UserNameForSslNegotiated authentication mode and when it might be used?
    Per the MSDN documentation found at this URL (http://msdn.microsoft.com/en-us/library/aa751836.aspx), it does not sound a whole lot different from UserNameForCertificate mode:


    UserNameForSslNegotiated:

    With this authentication mode, the client is authenticated using a UsernameToken which appears at the SOAP layer as a signed supporting token; that is, a token that is signed by the message signature. The service is authenticated using an X.509 certificate. The security binding element is a SymmetricSecurityBindingElement returned by the CreateUserNameForSslBindingElement method. Alternatively, set the authenticationMode attribute to UserNameForSslNegotiated.

    UserNameForCertificate:

    With this authentication mode, the client authenticates to the service using a UsernameToken that appears at the SOAP layer as a signed supporting token; that is, a token that is signed by the message signature. The service authenticates to the client using an X.509 certificate. The security binding element is a SymmetricSecurityBindingElement returned by the CreateUserNameForCertificateBindingElement method. Alternatively, set the authenticationMode attribute to UserNameForCertificate.



    Looking at the above descriptions, the only difference seems to be the static method on the SecurityBindingElement class that is used to create them.

    Thanks,
    Viji

    Wednesday, August 27, 2008 2:51 AM

All replies


  • Hi Viji

    With forCertificate the client has to get the server certificate out of band and explicitly define it in clientCredentials.ServiceCertificate configuration (or by code).

    With sslNegotiated the client doesn't need to define the server certificate as it gets it from the server via negotiation in the first request. This mode is not interopereble with non-Wcf clients.

    Thanks,
    Yaron
    Wednesday, August 27, 2008 8:18 AM
  • Why do you say that the UserNameForSslNegotiated mode is not interoperable with non-WCF clients?

    It looks like the service credential negotiation takes place by message exchanges that conform to WS-Trust specification.
    In the first leg of the negotiation, the client sends a message with a RequestSecurityToken element and the service ultimately responds in the final leg of the negotiation with the RequestSecurityTokenResponse element which encapsulates (amongst other things) the RequestedSecurityToken and RequestedProofToken elements. I don't see any Microsoft-specific exchanges here. So, why can't a Java-client negotiate with a WCF service in the same manner?

    Thanks
    Viji

    Wednesday, August 27, 2008 12:07 PM

  • WS-Trust establishes a general framework to exchange tokens. However anyone can define a new type of token or a specific negotation requirements and not every server has to implement every one. If you look at the soap envelopes of the WS-Trust request you will see

    <t:BinaryExchange ValueType=" http://schemas.xmlsoap.org/ws/2005/02/trust/tlsnego" ...

    AFAIK only MSFT has implemented support for this. You are right that in principle a JAVA soap stack may also implement it in the future, or that someone can manually generate the WS-Trust requests. However I'm not sure if there is an official SPEC for TLSNego over WS-Trust.

    Thanks,
    Yaron
    Wednesday, August 27, 2008 1:11 PM
  • Thanks, Yaron. That makes sense.

    The BinaryExchange element is in the WS-Trust specification but MSFT is leveraging the value of the ValueType attribute to do their on thing.

    Viji

     

    Wednesday, August 27, 2008 3:36 PM