dotnet web services enhancements: Hi Paul,
You can get it from the web service using the method:

Microsoft.Web.Services3.SoapContext.Current.IdentityToken

Regards,
Pablo Cibraro
http://weblogs.asp.net/cibrax

[quoted text, click to view]

Hi all,
I've been getting this warning:

Microsoft.Web.Services3.SoapContext.Security is obsolete:
SoapContext.Security is obsolete. Consider deriving from
SendSecurityFilter or ReceiveSecurityFilter and creating a custom
policy assertion that generates these filters.

So I'm guessing that it would be very bad form to use this to get at my
UsernameToken then, like WSE 2 samples would have you do.

I'm not sure that building a Filter would work in my case, as the
service will be calling in to something that authenticates user details
by function (to check that they are allowed to run the function) - and
not only requires the username and password from the UsernameToken, but
also two extra things encoded in the "any" element of the
UsernameToken. By the time it gets down to the webservice, it seems
that only a SecurityToken is available, which only has the identity
username easily available in it. Attempting to downcast to
UsernameToken fails. Yet the custom UsernameTokenManager is in place
and seems to be working.

May be I'm missing the point somewhere, I'm getting a feeling that MS
push down this route for a good reason.

But is there anyway to get to the UsernameToken in a non-obsolete way
in the Webservice code?

Microsoft.Web.Services3.SoapContext.Current is null in my [WebMethod],
so IdentityToken is inaccessible.

Okay, but you actually did give me something to think about:

[WebMethod]
public string EchoTest(string message)
{
string echo;

UsernameToken token = null;
SecurityContextToken securityContextToken =
RequestSoapContext.Current.IdentityToken as SecurityContextToken;

if (null != securityContextToken)
{
token = securityContextToken.BaseToken as
UsernameToken;
}

if (null == token)
{
echo = message + " - said goodness knows who.";
}
else
{
echo = message + " - said " + token.Username + " " +
token.Password + " " + KeyMaster.GetUserType(token) + " " +
KeyMaster.GetUserLocation(token);
}

return echo;
}


Works!

I noticed though, when putting things to the Any property of the
UsernameToken (type of Microsoft.Web.Services3.Xml.ElementList) -
although on the client side you might have more then one thing in the
list, it seems that only the first element is ever serialised and gets
back to as far as the webservice.

I got around this by creating an XmlElement that has the things I want
as child nodes of the first thing in the ElementList (taken care of by
that KeyMaster class).

Anyway as far as I am aware all of the above doesn't use anything that
is obsolute.