Contact   •   Products   •   Search

Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs

WCF WS-Security and WSE Nonce Authentication


WCF makes it fairly easy to access WS-* Web Services, except when you run into a service format that it doesn't support. Even then WCF provides a huge amount of flexibility to make the service clients work, however finding the proper interfaces to make that happen is not easy to discover and for the most part undocumented unless you're lucky enough to run into a blog, forum or StackOverflow post on the matter.

This is definitely true for the Password Nonce as part of the WS-Security/WSE protocol, which is not natively supported in WCF. Specifically I had a need to create a WCF message on the client that includes a WS-Security header that looks like this from their spec document:

<soapenv:Header>
  <wsse:Security soapenv:mustUnderstand="1"
      xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <wsse:UsernameToken wsu:Id="UsernameToken-8"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
      <wsse:Username>TeStUsErNaMe1</wsse:Username>
      <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"                  >TeStPaSsWoRd1</wsse:Password>
      <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"                  >f8nUe3YupTU5ISdCy3X9Gg==</wsse:Nonce>
      <wsu:Created>2011-05-04T19:01:40.981Z</wsu:Created>
    </wsse:UsernameToken>
  </wsse:Security>
</soapenv:Header>

Specifically, the Nonce and Created keys are what WCF doesn't create or have a built in formatting for.

Why is there a nonce? My first thought here was WTF? The username and password are there in clear text, what does the Nonce accomplish? The Nonce and created keys are are part of WSE Security specification and are meant to allow the server to detect and prevent replay attacks. The hashed nonce should be unique per request which the server can store and check for before running another request thus ensuring that a request is not replayed with exactly the same values.

Basic ServiceUtl Import - not much Luck

The first thing I did when I imported this service with a service reference was to simply import it as a Service Reference. The Add Service Reference import automatically detects that WS-Security is required and appropariately adds the WS-Security to the basicHttpBinding in the config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="RealTimeOnlineSoapBinding">
                    <security mode="Transport" />
                </binding>
                <binding name="RealTimeOnlineSoapBinding1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="https://notarealurl.com:443/services/RealTimeOnline"
                binding="basicHttpBinding" bindingConfiguration="RealTimeOnlineSoapBinding"
                contract="RealTimeOnline.RealTimeOnline" name="RealTimeOnline" />
        </client>
    </system.serviceModel>
</configuration>

If if I run this as is using code like this:

var client = new RealTimeOnlineClient();

client.ClientCredentials.UserName.UserName = "TheUsername";
client.ClientCredentials.UserName.Password = "ThePassword";

I get nothing in terms of WS-Security headers. The request is sent, but the the binding expects transport level security to be applied, rather than message level security. To fix this so that a WS-Security message header is sent the security mode can be changed to:

 <security mode="TransportWithMessageCredential" />

Now if I re-run I at least get a WS-Security header which looks like this:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
            xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <o:Security s:mustUnderstand="1"
                xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="_0">
        <u:Created>2012-11-24T02:55:18.011Z</u:Created>
        <u:Expires>2012-11-24T03:00:18.011Z</u:Expires>
      </u:Timestamp>
      <o:UsernameToken u:Id="uuid-18c215d4-1106-40a5-8dd1-c81fdddf19d3-1">
        <o:Username>TheUserName</o:Username>
        <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"
>ThePassword</o:Password> </o:UsernameToken> </o:Security> </s:Header>

Closer! Now the WS-Security header is there along with a timestamp field (which might not be accepted by some WS-Security expecting services), but there's no Nonce or created timestamp as required by my original service.

Using a CustomBinding instead

My next try was to go with a CustomBinding instead of basicHttpBinding as it allows a bit more control over the protocol and transport configurations for the binding. Specifically I can explicitly specify the message protocol(s) used. Using configuration file settings here's what the config file looks like:

<?xml version="1.0"?>
<configuration>
  <system.serviceModel>
    <bindings>
      <customBinding>
        <binding name="CustomSoapBinding">
          <security includeTimestamp="false"
                    authenticationMode="UserNameOverTransport"
                    defaultAlgorithmSuite="Basic256"
                    requireDerivedKeys="false"
                    messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
          </security>
          <textMessageEncoding messageVersion="Soap11"></textMessageEncoding>
          <httpsTransport maxReceivedMessageSize="2000000000"/>
        </binding>
      </customBinding>
    </bindings>
    <client>
      <endpoint address="https://notrealurl.com:443/services/RealTimeOnline"
                binding="customBinding"
                bindingConfiguration="CustomSoapBinding"
                contract="RealTimeOnline.RealTimeOnline"
                name="RealTimeOnline" />
    </client>
  </system.serviceModel>
  <startup>
    <supportedRuntime version="v4.0"
                      sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

This ends up creating a cleaner header that's missing the timestamp field which can cause some services problems. The WS-Security header output generated with the above looks like this:

<s:Header>
  <o:Security s:mustUnderstand="1"
              xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <o:UsernameToken u:Id="uuid-291622ca-4c11-460f-9886-ac1c78813b24-1">
      <o:Username>TheUsername</o:Username>
      <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"                 >ThePassword</o:Password>
    </o:UsernameToken>
  </o:Security>
</s:Header>

This is closer as it includes only the username and password.

The key here is the protocol for WS-Security:

messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10"

which explicitly specifies the protocol version. There are several variants of this specification but none of them seem to support the nonce unfortunately. This protocol does allow for optional omission of the Nonce and created timestamp provided (which effectively makes those keys optional). With some services I tried that requested a Nonce just using this protocol actually worked where the default basicHttpBinding failed to connect, so this is a possible solution for access to some services.

Unfortunately for my target service that was not an option. The nonce has to be there.

Creating Custom ClientCredentials

As it turns out WCF doesn't have support for the Digest Nonce as part of WS-Security, and so as far as I can tell there's no way to do it just with configuration settings. I did a bunch of research on this trying to find workarounds for this, and I did find a couple of entries on StackOverflow as well as on the MSDN forums. However, none of these are particularily clear and I ended up using bits and pieces of several of them to arrive at a working solution in the end.

The latter forum message is the more useful of the two (the last message on the thread in particular) and it has most of the information required to make this work. But it took some experimentation for me to get this right so I'll recount the process here maybe a bit more comprehensively.

In order for this to work a number of classes have to be overridden:

  • ClientCredentials
  • ClientCredentialsSecurityTokenManager
  • WSSecurityTokenizer

The idea is that we need to create a custom ClientCredential class to hold the custom properties so they can be set from the UI or via configuration settings. The TokenManager and Tokenizer are mainly required to allow the custom credentials class to flow through the WCF pipeline and eventually provide custom serialization.

Here are the three classes required and their full implementations:

public class CustomCredentials : ClientCredentials
{
    public CustomCredentials()
    { }

    protected CustomCredentials(CustomCredentials cc)
        : base(cc)
    { }

    public override System.IdentityModel.Selectors.SecurityTokenManager CreateSecurityTokenManager()
    {
        return new CustomSecurityTokenManager(this);
    }

    protected override ClientCredentials CloneCore()
    {
        return new CustomCredentials(this);
    }
}

public class CustomSecurityTokenManager : ClientCredentialsSecurityTokenManager
{
    public CustomSecurityTokenManager(CustomCredentials cred)
        : base(cred)
    { }

    public override System.IdentityModel.Selectors.SecurityTokenSerializer CreateSecurityTokenSerializer(System.IdentityModel.Selectors.SecurityTokenVersion version)
    {
        return new CustomTokenSerializer(System.ServiceModel.Security.SecurityVersion.WSSecurity11);
    }
}

public class CustomTokenSerializer : WSSecurityTokenSerializer
{
    public CustomTokenSerializer(SecurityVersion sv)
        : base(sv)
    { }

    protected override void WriteTokenCore(System.Xml.XmlWriter writer,
                                            System.IdentityModel.Tokens.SecurityToken token)
    {
        UserNameSecurityToken userToken = token as UserNameSecurityToken;

        string tokennamespace = "o";

        DateTime created = DateTime.Now;
        string createdStr = created.ToString("yyyy-MM-ddThh:mm:ss.fffZ");

        // unique Nonce value - encode with SHA-1 for 'randomness'
        // in theory the nonce could just be the GUID by itself
        string phrase = Guid.NewGuid().ToString();
        var nonce = GetSHA1String(phrase);

        // in this case password is plain text
        // for digest mode password needs to be encoded as:
        // PasswordAsDigest = Base64(SHA-1(Nonce + Created + Password))
        // and profile needs to change to
        //string password = GetSHA1String(nonce + createdStr + userToken.Password);

        string password = userToken.Password;

        writer.WriteRaw(string.Format(
        "<{0}:UsernameToken u:Id=\"" + token.Id +
        "\" xmlns:u=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\">" +
        "<{0}:Username>" + userToken.UserName + "</{0}:Username>" +
        "<{0}:Password Type=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText\">" +
        password + "</{0}:Password>" +
        "<{0}:Nonce EncodingType=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary\">" +
        nonce + "</{0}:Nonce>" +
        "<u:Created>" + createdStr + "</u:Created></{0}:UsernameToken>", tokennamespace));
    }

    protected string GetSHA1String(string phrase)
    {
        SHA1CryptoServiceProvider sha1Hasher = new SHA1CryptoServiceProvider();
        byte[] hashedDataBytes = sha1Hasher.ComputeHash(Encoding.UTF8.GetBytes(phrase));
        return Convert.ToBase64String(hashedDataBytes);
    }

}

Realistically only the CustomTokenSerializer has any significant code in. The code there deals with actually serializing the custom credentials using low level XML semantics by writing output into an XML writer.

I can't take credit for this code - most of the code comes from the MSDN forum post mentioned earlier - I made a few adjustments to simplify the nonce generation and also added some notes to allow for PasswordDigest generation.

Per spec the nonce is nothing more than a unique value that's supposed to be 'random'. I'm thinking that this value can be any string that's unique and a GUID on its own probably would have sufficed. Comments on other posts that GUIDs can be potentially guessed are highly exaggerated to say the least IMHO. To satisfy even that aspect though I added the SHA1 encryption and binary decoding to give a more random value that would be impossible to 'guess'. The original example from the forum post used another level of encoding and decoding to string in between - but that really didn't accomplish anything but extra overhead.

The header output generated from this looks like this:

<s:Header>
  <o:Security s:mustUnderstand="1"
              xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <o:UsernameToken u:Id="uuid-f43d8b0d-0ebb-482e-998d-f544401a3c91-1"
                      xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
      <o:Username>TheUsername</o:Username>
      <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">ThePassword</o:Password>
      <o:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>PjVE24TC6HtdAnsf3U9c5WMsECY=</o:Nonce> <u:Created>2012-11-23T07:10:04.670Z</u:Created> </o:UsernameToken> </o:Security> </s:Header>

which is exactly as it should be.

Password Digest?

In my case the password is passed in plain text over an SSL connection, so there's no digest required so I was done with the code above.

Since I don't have a service handy that requires a password digest,  I had no way of testing the code for the digest implementation, but here is how this is likely to work. If you need to pass a digest encoded password things are a little bit trickier. The password type namespace needs to change to:

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#Digest

and then the password value needs to be encoded. The format for password digest encoding is this:

Base64(SHA-1(Nonce + Created + Password))

and it can be handled in the code above with this code (that's commented in the snippet above):

 string password = GetSHA1String(nonce + createdStr + userToken.Password);

The entire WriteTokenCore method for digest code looks like this:

protected override void WriteTokenCore(System.Xml.XmlWriter writer,
                                        System.IdentityModel.Tokens.SecurityToken token)
{
    UserNameSecurityToken userToken = token as UserNameSecurityToken;

    string tokennamespace = "o";

    DateTime created = DateTime.Now;
    string createdStr = created.ToString("yyyy-MM-ddThh:mm:ss.fffZ");

    // unique Nonce value - encode with SHA-1 for 'randomness'
    // in theory the nonce could just be the GUID by itself
    string phrase = Guid.NewGuid().ToString();
    var nonce = GetSHA1String(phrase);

    string password = GetSHA1String(nonce + createdStr + userToken.Password);

    writer.WriteRaw(string.Format(
    "<{0}:UsernameToken u:Id=\"" + token.Id +
    "\" xmlns:u=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd\">" +
    "<{0}:Username>" + userToken.UserName + "</{0}:Username>" +
    "<{0}:Password Type=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#Digest\">" +
    password + "</{0}:Password>" +
    "<{0}:Nonce EncodingType=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary\">" +
    nonce + "</{0}:Nonce>" +
    "<u:Created>" + createdStr + "</u:Created></{0}:UsernameToken>", tokennamespace));        
}

I had no service to connect to to try out Digest auth - if you end up needing it and get it to work please drop a comment…

How to use the custom Credentials

The easiest way to use the custom credentials is to create the client in code.

Here's a factory method I use to create an instance of my service client: 

public static RealTimeOnlineClient CreateRealTimeOnlineProxy(string url,
                                                                string username,
                                                                string password)
{
    if (string.IsNullOrEmpty(url))
        url = "https://notrealurl.com:443/cows/services/RealTimeOnline";
            
    CustomBinding binding = new CustomBinding();  
var security = TransportSecurityBindingElement.CreateUserNameOverTransportBindingElement(); security.IncludeTimestamp = false; security.DefaultAlgorithmSuite = SecurityAlgorithmSuite.Basic256; security.MessageSecurityVersion = MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10; var encoding = new TextMessageEncodingBindingElement(); encoding.MessageVersion = MessageVersion.Soap11; var transport = new HttpsTransportBindingElement(); transport.MaxReceivedMessageSize = 20000000; // 20 megs binding.Elements.Add(security); binding.Elements.Add(encoding); binding.Elements.Add(transport); RealTimeOnlineClient client = new RealTimeOnlineClient(binding, new EndpointAddress(url)); // to use full client credential with Nonce uncomment this code: // it looks like this might not be required - the service seems to work without it client.ChannelFactory.Endpoint.Behaviors.Remove<System.ServiceModel.Description.ClientCredentials>(); client.ChannelFactory.Endpoint.Behaviors.Add(new CustomCredentials()); client.ClientCredentials.UserName.UserName = username; client.ClientCredentials.UserName.Password = password; return client; }

This returns a service client that's ready to call other service methods.

The key item in this code is the ChannelFactory endpoint behavior modification that that first removes the original ClientCredentials and then adds the new one. The ClientCredentials property on the client is read only and this is the way it has to be added.

 

Summary

It's a bummer that WCF doesn't suport WSE Security authentication with nonce values out of the box. From reading the comments in posts/articles while I was trying to find a solution, I found that this feature was omitted by design as this protocol is considered unsecure. While I agree that plain text passwords are rarely a good idea even if they go over secured SSL connection as WSE Security does, there are unfortunately quite a few services (mosly Java services I suspect) that use this protocol. I've run into this twice now and trying to find a solution online I can see that this is not an isolated problem - many others seem to have struggled with this. It seems there are about a dozen questions about this on StackOverflow all with varying incomplete answers. Hopefully this post provides a little more coherent content in one place.

Again I marvel at WCF and its breadth of support for protocol features it has in a single tool. And even when it can't handle something there are ways to get it working via extensibility. But at the same time I marvel at how freaking difficult it is to arrive at these solutions. I mean there's no way I could have ever figured this out on my own. It takes somebody working on the WCF team or at least being very, very intricately involved in the innards of WCF to figure out the interconnection of the various objects to do this from scratch. Luckily this is an older problem that has been discussed extensively online and I was able to cobble together a solution from the online content. I'm glad it worked out that way, but it feels dirty and incomplete in that there's a whole learning path that was omitted to get here…

Man am I glad I'm not dealing with SOAP services much anymore. REST service security - even when using some sort of federation is a piece of cake by comparison :-) I'm sure once standards bodies gets involved we'll be right back in security standard hell…

Make Donation
Posted in WCF  Web Services  


Feedback for this Post

 
# re: WCF WS-Security and WSE Nonce Authentication
by Yaron Naveh November 24, 2012 @ 1:25pm
In these kinds of situations I like to emit the security header myself using a message inspector (or a custom encoder if required) rather than hook up to the security pipeline. In some cases this can save you from implementing 10+ classes.

For your scenario you may also want to look at this implementation of the username token profile for wcf http://blogs.msdn.com/b/aszego/archive/2010/06/24/usernametoken-profile-vs-wcf.aspx
# re: WCF WS-Security and WSE Nonce Authentication
by Donatas Mačiūnas December 19, 2012 @ 2:34am
Thank you very much for this! We had this same issue with Java webservice and your solution worked perfectly.

Just something I noticed with fiddler:
by default WCF outputs password header like this:
"<{0}:Password {0}:Type=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#Digest\">"
note: {0}:Type, your solution is missing {0}: before Type attribute (it still works though)
# re: WCF WS-Security and WSE Nonce Authentication
by Alexander Shiryaev March 01, 2013 @ 6:37am
Created date should be in UTC:
DateTime created = DateTime.UtcNow;
string createdStr = created.ToString("yyyy-MM-ddTHH:mm:ss.fffZ");
# re: WCF WS-Security and WSE Nonce Authentication
by Balaji April 10, 2013 @ 8:02am
Thank you! i understand how painful it was to figure this.
# re: WCF WS-Security and WSE Nonce Authentication
by Charlie May 04, 2013 @ 9:40am
Hi, After spending nights and days on this for a beginner like me,,, I came to the point where I generated a Clientproxyclas using svcutil.exe. And then came to the understanding that I would need some custom bindings to accomodate nonce.. But How do I get to see the Soap XML. The SVClog file just shows some applicationdata and events..
# re: WCF WS-Security and WSE Nonce Authentication
by Steve July 29, 2013 @ 7:41pm
This post was super helpful! I had visited probably about 10 different pages and none outlined the solution so thoroughly. I am now getting my header constructed properly but am still getting an error back from the service "com.sun.xml.wss.impl.WssSoapFaultException: Authentication of Username Password Token Failed". I'm following up with the service host since I believe I'm following the proper steps now.
# re: WCF WS-Security and WSE Nonce Authentication
by Rick Strahl July 30, 2013 @ 2:00am
@Steve - the easiest way to check is to have the provider give you a service trace with credentials and then let you recreate that trace with the same credentials. That way you can double check the encoding. I've found that in some cases the encoding of the nonce can be different and double checking whether they match can be useful to experimenting and finding the exact right combo.
# re: WCF WS-Security and WSE Nonce Authentication
by Steve July 30, 2013 @ 1:42pm
Thanks @Rick, it was a huge pain figuring out a workable request with the client but it ended up working for me using this approach:

string rawNonce = Guid.NewGuid().ToString();
var nonce = Convert.ToBase64String(Encoding.UTF8.GetBytes(rawNonce));
string password = GetSHA1String(rawNonce + createdStr + userToken.Password);

I was hashing the nonce string and then rehashing the nonce string again as part of the overall password hash.

Either way, I was totally lost before your post so you still really helped a ton! Thanks!
# re: WCF WS-Security and WSE Nonce Authentication
by kbusch October 28, 2013 @ 10:14pm
After an all day search, this post saved me today. Thank you for taking the time to write this up and share. You make the internet work!
# re: WCF WS-Security and WSE Nonce Authentication
by tmanthey November 08, 2013 @ 3:10am
You can actually see the message that goes over the wire in svcTraceViewer.

You just have to set logMessagesAtTransportLevel="true"

so <messageLogging logEntireMessage="true" logMalformedMessages="true"
logMessagesAtServiceLevel="false" logMessagesAtTransportLevel="true"
# re: WCF WS-Security and WSE Nonce Authentication
by Dave Lee November 12, 2013 @ 11:21am
Thank you so much for sharing this. I had to make a couple of minor tweaks because the service that I am calling is over HTTP and not HTTPS.

 CustomBinding binding = new CustomBinding();
 
var security = TransportSecurityBindingElement.CreateUserNameOverTransportBindingElement();
security.AllowInsecureTransport = true; // [DLee 11-12-2013] Added
security.IncludeTimestamp = false;
security.DefaultAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
security.MessageSecurityVersion = MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;
 
var encoding = new TextMessageEncodingBindingElement();
encoding.MessageVersion = MessageVersion.Soap11;
 
var transport = new HttpTransportBindingElement(); // [DLee 11-12-2013] new HttpsTransportBindingElement();
transport.MaxReceivedMessageSize = 20000000; // 20 megs
# re: WCF WS-Security and WSE Nonce Authentication
by Sabari February 11, 2014 @ 1:46am
Can you please tell me how we can achieve this using .net 2.0 framework.
# re: WCF WS-Security and WSE Nonce Authentication
by Mohankumar February 25, 2014 @ 4:45am
Very helpful. thanks a lot.

I would like to know how we can expose the WCF service with OASIS security ?
can you help on this as well ?
# re: WCF WS-Security and WSE Nonce Authentication
by Tom April 30, 2014 @ 6:36am
Super Tutorial, Solved our Problem in 5min after trying 4 days!!!!!!
# re: WCF WS-Security and WSE Nonce Authentication
by Carlos Garcia June 13, 2014 @ 2:58pm
Hi, i have read the article and i´m triyng to implement it. But i cannot find the Namespace for the RealTimeOnlineClient class. Can somebody tell me where to find it?
# re: WCF WS-Security and WSE Nonce Authentication
by Rick Strahl June 13, 2014 @ 6:10pm
@Carlos - that's an application specific class. That class is going to be your WCF client class.
# re: WCF WS-Security and WSE Nonce Authentication
by Dennis June 23, 2014 @ 9:31pm
@Steve - the simple rawnonce is what made the difference for me. This page helped confirm I was on the right track. You comment made it work. I have been only trying for 10 hours so far to get this all to work. The last 5 was this one issue. I was trying in a language I never used before (apex, salesforce) and thanks to your comment was able to do so.
# re: WCF WS-Security and WSE Nonce Authentication
by Scott Eastin July 06, 2014 @ 9:41am
I just wanted to say this article was a giant help. There is barely anything out there about how to solve these types of problems and this article was the solution to the developer hell I have been in for the last week. Thanks again and I owe you several beers!

Scott
# re: WCF WS-Security and WSE Nonce Authentication
by John Herron July 06, 2014 @ 11:22am
Hi Rick - I'm getting an h:Security section before the o:Security section. The web service I'm calling fails because of this with a "user could not be authenticated" error. If I capture the message with fiddler then remove the section or change the h:Security spelling it works. Did you remove the section from your post or does it include it? I need a way to remove the h:Security section.

Thanks
John
# re: WCF WS-Security and WSE Nonce Authentication
by Moises August 27, 2014 @ 6:15am
Oh! you saved my life with this post. It explains it so clearly and all the steps together. Thank you very much!
# re: WCF WS-Security and WSE Nonce Authentication
by nikz2 October 23, 2014 @ 8:19am
FOR PASSWORD DIGEST! It works, but need some changes,
1st
"<{0}:Password Type=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#Digest\">" +
change to
"<{0}:Password Type=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest\">" +

2nd as described here
http://stackoverflow.com/questions/19438000/working-algorithm-for-passworddigest-in-ws-security
 


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2014