Can't say wrong or right in terms of what additional things you may be
thinking.  However, in terms of just the SCT thing I posted, you don't need
private PKI key on clients at all.  Only the *public key on the client, the
server(s) maintain the private key.  If you have multiple servers (say a
farm), then each server can access same private key pair using any method
you prefer (i.e. db, shared file, key store, etc)  Using this public PKI
method, a hacker can not hack into other people's passwords off the wire as
they can not decrypt the AES session key that was encrypted with the public
key.  The hacker can send his own requests using the public key, but can not
decrypt any other messages from others, even if they use the same public
key.   So a hacker can not figure out your session key or password and the
session is safe within the context of the AES session.  To crack, he would
need to crack PKI and/or AES using brute force - so we are safe as PKI/AES
can be (which is not to say PKI or AES can not be cracked given time and
resources).  So to get back to your point.  I don't see what unique private
PKI key on each client is adding here as we are not using a private key for
the SCT request.  Unless your talking about some other method in addition to
the SCT session.  If so, I would love to hear about your ideas.

All that said, there is still one weakness here.  Even thou the public key
is public and not secret, we still need to protect it from
change/replacement somehow.  As a hacker who gets access to your machine may
be able to replace your public key with a public key he created from a new
key pair.  Now he could Man-In-The-Middle the session.  You would send
encrypted request using "his" public key, and he could decrypt with the
matching private key is knows already.  Then just drop the session as he has
the password or continue being in the middle and forwarding requests.  This
would be a hard attack to pull off that would require access to client
machine and some network access - but something to think about.  I think
even public Certs would be vulnerable to this type of attack given the same
access to machine and network (say an Inside-Job).

The only thing I can think of to head off that kind of attack is SN sign
your client assem with key pair *and encrypt the same public key string in
the assem (and obfuscate) and compare the two keys at some point.  This
pretty much would force a decompile to remove the key compare logic or
change the public key.  The double check also would guard against any
minor/major change to the code or resources as the loader would fail to load
the assem.  Moreover, they could not just resign the assem as the double
check using the embedded version would fail.  Raises the bar a bit more.

I like config options as well.  However, I still don't see what value this
could add to commercial software or otherwise.  I am racking my head to find
a value, but am not able to at this point.

Sure.  You have any connections into MSDN mag?  Cheers!

Effectivily, UsernameTokens(UT) is using a shared secret.  The shared secret
is the password.  The encryption key is derived from the password.  More on
that below.

The problem with using just UTs and either SendNone, SendHashed or SendPlain
is if you sign a request, you may have all the data you need to perform a
dictionary attack on the signature to get the password used to sign the
data.  Depending on the data sent, you could also do a dictionary attack on
the encrypted body to figure out what password was used to encrypt it.  If
your password is a cryptographically strong random bytes and >= 16 bytes,
then that may be ok as that is like trying to brute force an AES 16 byte
random key.  If you go that route, I would use SendNone, a 16 (or 32) byte
*random password, and encrypt and sign all requests. Also note, you can't
use DerivedKeyTokens with UTs, so that is another down side of using UTs.

GetSCTNew is a just a soap method like any other.  Yes the class derives
from SoapClient.  Are you having issues with get a SoapClient proxy working
with your SoapService?  My SCT method just returns a SCT token if you pass
the correct username/pw.  Then you can use the SCT to sign and encrypt
messages without a UT.  If you using 16 byte random password, then it is
probably still not as strong as using a SCT, but maybe good enouph for your
purposes and easier as you said.  I attached code of client class at end of
this post.

Looks like Indigo will make things much easier.  Here is client side class.

using System;
using System.Collections;
using System.Security.Cryptography;
using System.IO;
using System.Text;
using System.Diagnostics;
using Microsoft.Web.Services2;
using Microsoft.Web.Services2.Addressing;
using Microsoft.Web.Services2.Messaging;
using Microsoft.Web.Services2.Security.Tokens;
using Microsoft.Web.Services2.Security;
using System.Xml;
using Microsoft.Web.Services2.Security.Policy;
using Microsoft.Web.Services2.Security.Cryptography;
using System.Globalization;
using System.Reflection;

namespace WSESimpleTCPDLL
{
public sealed class ServiceClient : SoapClient
{
 private System.Security.Cryptography.RSACryptoServiceProvider rsaPub;
 private readonly Hashtable sctList = new Hashtable( new
CaseInsensitiveHashCodeProvider(), new CaseInsensitiveComparer() );
 private readonly object syncRoot = new object();
 private static SHA1 sha = SHA1.Create();

 public ServiceClient( EndpointReference endpoint ) : base( endpoint )
 {
  string xml = GetPublicKey();
  rsaPub = new System.Security.Cryptography.RSACryptoServiceProvider();
  rsaPub.FromXmlString(xml);

  sctList = new Hashtable( new CaseInsensitiveHashCodeProvider(), new
CaseInsensitiveComparer() );
  sctList = Hashtable.Synchronized(sctList);
 }

 private ServiceClient() : base()
 {
 }

 private System.Security.Cryptography.RSACryptoServiceProvider RSAPubKey
 {
  get { return rsaPub; }
 }

 public SecurityContextToken GetSCTNew(string userName, string password)
 {
  SecurityContextToken curSCT = (SecurityContextToken)sctList[userName];
  if ( curSCT != null )
  {
   if ( curSCT.IsCurrent )
    return curSCT;
   // Else, remove curSCT and continue for new one.
   sctList.Remove(userName);
  }
  // Load server's public RSA key. Could get from Assembly, file, etc.
  System.Security.Cryptography.RSACryptoServiceProvider pubRSA =
   SnkUtil.GetPublicKeyFromAssembly(Assembly.GetExecutingAssembly());

  // Create SCT Request.
  SCTMsg ki = new SCTMsg();
  byte[] key = Utils.GetRandomBytes(64); // 64 bytes each side.
  byte[] sKey = Utils.GetBytes(key, 32); // 32 bytes AES key.
  byte[] iv = Utils.GetBytes(key, 16); // Is this secure?
  // Add some random salt to the username and pw to make it so much
  // harder to figure out via a brute force attack on AES.  Nice thing
  // about use AES instead of PKI is we don't have to worry about size
  // of username or password.
  string salt =
Convert.ToBase64String(Utils.GetRandomBytes(10)).Substring(0, 10);
  string saltun = salt + userName;
  string saltpw = salt + password;
  byte[] unBytes = Encoding.UTF8.GetBytes(saltun);
  byte[] pwBytes = Encoding.UTF8.GetBytes(saltpw);
  ki.Key = pubRSA.Encrypt(key, false);
  RijndaelManaged rm = new RijndaelManaged();
  rm.Key = sKey;
  rm.IV = iv;
  ICryptoTransform encryptor = rm.CreateEncryptor();
  ki.Username = Utils.RijndaelEncrypt(encryptor, unBytes);
  ki.Password = Utils.RijndaelEncrypt(encryptor, pwBytes);
  // Add signature.  This is the msg digest encrypted with AES.
  // Note we are using the actual 64 key in the hash and not
  // the "wire" version.  Now the message itself does not
  // contain the raw data needed to brute force the hash.
  byte[] hashData =
   Encoding.UTF8.GetBytes(
   Convert.ToBase64String(key) +
   Convert.ToBase64String(ki.Username) +
   Convert.ToBase64String(ki.Password));
  byte[] msgHash = sha.ComputeHash(hashData);
  ki.Signature = Utils.RijndaelEncrypt(encryptor, msgHash);

  // Send request.
  SoapEnvelope se = new SoapEnvelope();
  se.SetBodyObject(ki);
  SCTMsg rki = (SCTMsg)base.SendRequestResponse("GetSCTNew",
se).GetBodyObject(typeof(SCTMsg));

  // Verify Signature.  Digest signed by the server's private key.
  hashData = Encoding.UTF8.GetBytes(
   Convert.ToBase64String(key) + // Server used 64 byte key.
   rki.SCTIdentifier +
   rki.SCTExpires);
  if ( ! pubRSA.VerifyData(hashData, new SHA1CryptoServiceProvider(),
rki.Signature) )
   throw new Exception("Could not verify hash.");

  // Create SCT.  Note we are not wrapping a UT on this version.
  // Not sure it is needed.  Do we have a reason?
  SecurityContextToken sct = new SecurityContextToken(rki.SCTIdentifier);
  sct.KeyBytes = iv; // SCTs require 16 byte Keys.
  DateTime expires = Utils.FromUTCDateTimeString(rki.SCTExpires);
  expires = expires.ToLocalTime();
  sct.LifeTime = new LifeTime(expires);

  // Add SCT to static Hashtable for this username.
  // This hashtable is not required if you just want to hold onto the SCT
  // yourself.
  sctList[userName] = sct;
  return sct;
 }

 // Some other web method. Anyone can call.
 [SoapMethod("Ping")]
 public string Ping(string msg)
 {
  return (string)base.SendRequestResponse("Ping",
msg).GetBodyObject(typeof(string));
 }

 // Some other web method.  Server requires authenticated SCT.
 [SoapMethod("GetDateString")]
 public string GetDateString()
 {
  SoapEnvelope se = new SoapEnvelope();
  SecurityContextToken sct = GetSCTNew("staceyw", "1234");
  DerivedKeyToken dt = new DerivedKeyToken((IDerivableToken)sct);
  se.Context.Security.Tokens.Add(sct);
  se.Context.Security.Tokens.Add(dt);
  se.Context.Security.Elements.Add(new MessageSignature(dt));
  string r = (string)base.SendRequestResponse("GetDateString",
se).GetBodyObject(typeof(string));
  return r;
 }

 }
}

//
// Server method may look like:
//
 [SoapMethod("GetDateString")]
 public string GetDateString(string data)
 {
    if ( ! AccessIsAllowed(@"mvptools\newgroup") )
      throw new Exception("Security exception.");
    Debug.WriteLine("Is in Role: true");
    return DateTime.UtcNow.ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ",
CultureInfo.InvariantCulture);
 }

 /// <summary>
 /// Require message is signed by SCT or Derived SCT *and it is
 /// Authenticated.
 /// </summary>
 /// <param name="role"></param>
 /// <returns></returns>
 private bool AccessIsAllowed(string role)
 {
  SecurityElementCollection elements =
RequestSoapContext.Current.Security.Elements;

  // Loop through all of the security tokens (could be more than one).
  foreach( ISecurityElement securityElement in elements )
  {
   if( securityElement is MessageSignature )
   {
    MessageSignature sig = (MessageSignature)securityElement;
    if( (sig.SignatureOptions & SignatureOptions.IncludeSoapBody) != 0 )
    {
     SecurityToken sigToken = sig.SigningToken;
     // Find the token used to sign this message
     if ( sigToken is SecurityContextToken ||
      sigToken is DerivedKeyToken )
     {
      if ( sigToken.Principal.Identity.IsAuthenticated )
      {
       if ( role == null )
        return true; // Allow any role.
       if ( sigToken.Principal.IsInRole(role) )
        return true; // Allow only users in "role".
       else
        return false; // Not member.
      }
      else
       return false;  // Not authenticated.
     }
     else
      return false;   // Not one of tokens we allow.
    }
   }
  }
  return false;
 }

James,

let's see if we can address some of your concerns.

It depends. On the client side, the service proxy inherits from SoapClient.
On the server-side, the service interface inherits from SoapService.

I don't see why you are saying that's not SOAP communication... It
definitely is sending SOAP messages back and forth. I implement all my web
services that way. I need to write my own proxies rather than relying on
wsewsdl2.exe (or whatever that tool is called...), but it gives me much more
control for very little effort.

Please try the sample I supplied. Let me/us know if you have any questions
about it, after walking through it with the debugger.

<snip>

Actually, "us" is just a class that's auto-generated by the WSDL tool. It is
not a web service, it's a web service proxy.

So basically, you'd write your own "us" class. That will be a class that
inherits from SoapClient. That class' interface will resemble your server
class' interface (just like "us" does now).

OK, so you basically have a custom UsernameTokenManager. You won't need that
any longer with this implementation. Much has been written about that
lately, but the conclusion is always that unless you use SSL every time, all
the time, there is no secure way to use UsernameTokens.

OK, walk through the sample with a debugger. Take the encryption and hashing
stuff for granted. (That's black box stuff, it really has nothing to do with
this sample...) The only thing you need to understand is where a
public/private key pair is used and where a shared session key is used. If
you see RSA encryption, then it's PKI. If you see Rijndael, then that refers
to the shared session key.

If there are any non-encryption related functions you can't seem to find,
check the WSE documentation first. More than likely, there inherited from
SoapClient or SoapService, or static (Shared) methods of WSE 2.0 classes. If
you still don't seem to find the function, let me/us know.

Also review the architecture document that's included. If you don't have a
means to open Visio files (there's a free viewer available from Microsoft at
[1], but I understand if you don't want to install that), I will create  a
PDF from that file. Print it, and annotate is you like when going through
the sample.

Unfortunately, security is never "easy." If it was, people wouldn't need us
anymore, they could just drag-and-drop their way to interoperable web
services. Pray that day never comes, or that you have another job offer by
that time ;o)

Just exaggerating. But the main point still is that using usernames and
passwords is increasingly risky because of several reasons, some of which
are outlined in Keith's article at [2].

[1] http://office.microsoft.com/en-us/officeupdate/CD010798711033.aspx

[2]
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/htm
l/securusernametoken.asp