WS Security Header (WSE 2)

[nsyforce]

I am writing a web service that is taking advantage of WSE. I'm
starting out by just sending a userNameToken with a plain text
password. The class I'm using to implement the userNameTokenManager
works as expected with the authenticateToken method. I've debugged it
and can see where the userNameToken is being obtained. The webservice I
have has a 'helloWorld' function. When that function runs, I can't get
a hold of the userNameToken. It's as if the Ws Security header has
been removed. I've Googled, and did find where someone made the
comment that after the authentication takes place through the
userNameTokenManager, that WSE deletes the header as a security
measure.

Although I saw that mentioned, I'm not believing it. In the
userNameToken example that comes with WSE, I don't have this problem.
The service code can obtain the userNameToken. There are many samples
from Microsoft where they do this. The code in my 'helloWorld'
function is the exact same code used in these examples to get the
userNameToken.

So my question is, why would I not be able to get the userNameToken in
a helloWorld function after the authenticateToken function ran, and it
could get it? Could there be some sort of configuration issue?

One last thing to mention. My client is a windows form.

Thanks in advance

 

[nsyforce]

Here is my code for this. As I mentioned in the previous comment, I
don't have any issues with the authenticateToken function. That works
just fine. However, when the client Webservice has a 'helloworld'
function which then calls the IsMessageSigned function that is pasted
below, there is nothing in the context.Security.Elements collection.
Shouldn't there be the userNameToken?

using System;
using System.Xml;
using System.Security.Permissions;
using Microsoft.Web.Services2;
using Microsoft.Web.Services2.Security.Tokens;
using Microsoft.Web.Services2.Security;
using System.Security.Cryptography;



namespace MsWsXmlEnc
{
/*
* It is recommended that you demand that an assembly accessing
* this class already have permission to call unmanaged code.
* Because Microsoft.Web.Services2 is the only assembly that
* should call this class, you might consider further restricting
* access to assemblies only signed by Microsoft.
*
* [SecurityPermission(SecurityAction.Demand,
* Flags= SecurityPermissionFlag.UnmanagedCode)]
*/

public class AuthenticationManager : UsernameTokenManager
{
/// <summary>
/// Constructs an instance of this security token manager.
/// </summary>
public AuthenticationManager()
{
}
/// <summary>
/// Constructs an instance of this security token manager.
/// </summary>
/// <param name="nodes">An XmlNodeList containing XML elements from a
configuration file.</param>
public AuthenticationManager(XmlNodeList nodes)
: base(nodes)
{
}
protected override string AuthenticateToken(UsernameToken token)
{
string username = token.Username;
string password = token.Password;
userTokenInfoCollection.setPassword(username,password);
return password;
}

public static bool IsMessageSigned(SoapContext context)
{
//string strHeader = context.Envelope.Header.OuterXml;

foreach (ISecurityElement element in context.Security.Elements)
{
if (element is MessageSignature)
{
MessageSignature sign = element as MessageSignature;

if (Convert.ToBoolean((sign.SignatureOptions &
(SignatureOptions.IncludeSoapBody |
SignatureOptions.IncludeTo |
SignatureOptions.IncludeAction |
SignatureOptions.IncludeMessageId |
SignatureOptions.IncludeFrom))))
{
// The SOAP message is signed.
if (sign.SigningToken is UsernameToken)
// The SOAP message is signed
// with a UsernameToken.
return true;
}
}
}
return false;
}

 

[nsyforce]

Thanks for your reply. I tried the change and got the same results.
The function always returns null because there are no elements in
context.Security.Elements.

My client is passing in the SoapContext using the following:
SoapContext requestContext = RequestSoapContext.Current;
This is what I have seen in the Microsoft examples. Is there another
way I should be getting it?

 

[nsyforce]

To comment on my previous message, it's not the client passing in the
SoapContext obviously. It's the webservice that is using
RequestSoapContext.Current in the call to function to get the
userNameToken.

 

[nsyforce]

Rviary, you came through!
Don't worry about offending me. Any help you provide is much
appreciated.

I looked closer at my client code from your example and saw what I was
missing. I was missing this line...
rqContext.Security.Elements.Add(new EncryptedData(userToken));

Now I realize how stupid it was that I didn't pick up on that
previously since the fact that my elements being empty was the problem.
When I originally was coding this, for some reason I thought that
collection was used when the password was being encrypted. It just
didn't occur to me that I didn't put that line in when I originally
wrote the code.

Thanks for your help