OK, thanks to Julia's help and a bunch of stuff in the newsgroups I've got
some of this working but not all...

Basically I need to be able to encrypt both sides of the communication
between client and server using a UserNameToken that passes the UserName but
not the password but is a shared secret. I cannot use X.509 or anything like
that because the number of client computers is unknown and could easily be
thousands, and the server may not necessarily have an SSL key and I don't
want to leave it up to my clients to optionally get an SSL key, because most
of them won't because they're lazy or cheap or some other "really good
reason" that will jepardize their data. <aside>Hence Shared secret, which I
used in WSE 2.0 with great effect because the shared secret password was
unique per client computer, and it was a 512 bit hash which is really hard
to break, and after every operation the hash would change (sent in the
encrypted message body by the server to the client and then stored in a
different encryption in the local database). (Yes, I know, if you break one
message, you break 'em all, but you can't use two messages to compare
between the two... I was working on an algorhythm that the server and client
would use to calculate the new hash without one sending it to the other, but
since this works, and is very secure the way it is, it wasn't high on the
list of priorities...</aside>

I was able to do this stuff in WSE 2.0 before using the now depreciated
Context.Security... stuff. No go in WSE 3.0 because it's depreciated. If I
use the depreciated functions, it works fine... I think... can't tell
because it doesn't use the policy stuff of course.

I've got the signing stuff done and working by using a Custom
UserNameTokenManager on the server and then creating the right entries in my
web.config file. Which works and is called and validates the whole deal..
assuming the client request adds a proper UserNameToken...

It still lets clients that don't use anything query my WebMethods however.

So I looked in the newsgroups here and decided I needed a policy file
because the way I was doing it before was to query the Context.Security
stuff looking for the entries... which is depreciated.

So I added the following on the server:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">

<extensions>

<extension name="usernameOverTransportSecurity"
type="Microsoft.Web.Services3.Design.UsernameOverTransportAssertion,
Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />

<extension name="wse3Trace" type="WSETracingFilter.WSEFilterAssertion,
WSETracingFilter, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=aa253a6b9020c4eb"/>

</extensions>

<policy name="RegistrationPolicy">

<usernameOverTransportSecurity />

<requireActionHeader />

<wse3Trace/>

</policy>

</policies>

Then on the Service itself:

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[Policy("RegistrationPolicy")]

public class Registration : System.Web.Services.WebService {

...

and the following on the client:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">

<extensions>

<extension name="usernameOverTransportSecurity"
type="Microsoft.Web.Services3.Design.UsernameOverTransportAssertion,
Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />

<extension name="wse3Trace" type="WSETracingFilter.WSEFilterAssertion,
WSETracingFilter, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=aa253a6b9020c4eb"/>

</extensions>

<policy name="UserNamePolicy">

<usernameOverTransportSecurity />

</policy>

</policies>

and in the client request:

Microsoft.Web.Services3.Security.Tokens.UsernameToken tok = new
Microsoft.Web.Services3.Security.Tokens.UsernameToken(UserName, Password,
Microsoft.Web.Services3.Security.Tokens.PasswordOption.SendNone);

r.SetPolicy("UserNamePolicy");

r.SetClientCredential(tok);

Note that I'm using Mike's tool to monitor the requests.... hence the added
Extension...I tried removing it and users can still just request the
WebMethod and it works.

Sorry if this is a dupe everyone. It didn't seem to go through the first
time...

All is good in that Mike's tool tells me that the username tolken is added
etc. However!

1. The contents of the message are not encrypted. They absolutely have to be
encrypted.... But the docs say that UsernameoverTransport doesn't support
it, but when I query the UserNametoken it says that it does support
encryption... Help please!

2. You can still request the WebMethods without any of this stuff and it
works.

Also...

I would like to make sure that the minimum amount of data is sent over the
wire (there could be dialup users using this!) so any suggestions on how to
get this whole system to send stuff only once on the first request etc.
would be greatly appreciated. (i.e. how do I enable SecureConversation??? Is
that even the right way to go about it?)

I wish MS would just accept that this is a scenario that they need to
support and put it in instead of making it harder and harder every time they
do this, cause people are just going to get around it (like me) and thus
likely are not going to get it right and think they have encrypted secure
communications when they don't... better to have MS do it and do it right
instead of letting people hack something together...

Thanks for any help you might be able to provide!

James Hancock