0

We're in a strange situation with a legacy winforms VB.NET 1.1 application using ASMX web services. Trying to send a user Token from a WindowsIdentity object as a parameter to a WebMethod. I will be adding a 'HACK: comment.

System.Security.Principal.WindowsIdentity.GetCurrent().Token

The token is of type IntPtr, the first problem is the WSDL being generated doesn't support IntPtr with the error of 'unsupported type'

I'm aware this is a big WTF question and sounds insecure, so any simple helpful alternatives are welcome but there are a lot of constraints on how we can change this system, including complications with the hosting environment. So I would just like to get our piece of data over to the web service to save a lot of other headaches.

Problem 1

Error from WSDL Generation:

Method userClass.TestSendIntPtr can not be reflected. 
--> There was an error reflecting 'token'. 
--> System.IntPtr is an unsupported type.

An alternate approach (extending the WTF factor) - trying to get around the IntPtr issue is to just put the IntPtr into a System.IO.Stream using 

BinaryFormatter.Serialize()

on the winforms app end and BF.Deserialize() on the service. But this leads to a new strange issue.

Defining the Web Service Method's signature in this fashion:

Public Class UserService
    Inherits System.Web.Services.WebService

    <WebMethod()> _
    Public Function UserToken(ByVal tokenStream As System.IO.Stream) As Boolean

The new strange issue arises on the client end as a compilation error, as if the 'System.IO' qualification of Stream is being ignored, and being interpreted as part of the UserService class...

Problem 2

Value of type 'System.IO.Stream' cannot be converted to 'USERSERVICE.Stream'.

So an answer to either question, or similar alternate approach would be great...

Nick Josevski
  • 4,156
  • 3
  • 43
  • 63
  • If only we were using WCF this wouldn't be a problem, but this is just a patch on a legacy system, no capacity for solid improvements. – Nick Josevski Jun 26 '09 at 04:58

1 Answers1

1

If an IntPtr won't work because of a lack of support in WSDL, then use a Long instead. IntPtr's are convertible to and from the Integer and Long type. You can just pass around the value as one of these types (preferably Long) and convert it back on the other end.

Convert to Long

Dim value As Long = token.ToInt64()

Convert from Long

Dim token as IntPtr = new IntPtr(value)

One thing that you should note though is that a Token is only valid in the address space of the process that created the value. If you are passing the value through a web service which resides in another process, the token will have no probative value. It will have the same physical address but you will not be able to query values against that token.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Thanks JaredPar, sending the token wasn't going to be useful. The attempt was to recreate the WindowsIdentity on the service. Only because of other difficulties preventing us from connecting to the web service that's correctly setup for integrated security. Recreating it isn't wise/practical/achievable. Thanks for taking the time to provide an answer that supports why this is the wrong approach. – Nick Josevski Jun 29 '09 at 11:46
  • I know this is an old question but I am somehow in a similar situation, only that all my 'operations' are happening in the same machine. I need to create at Login time an IntPtr pointing to the WindowsIdenity token. My initial thought is to 'persist' this IntPtr in an OAuth token so that in later calls I can impersonate this user by creating a WindowsIdentity using the IntPtr. Would that still be a viable solution considering that everything happens in one machine? Thanks. – Pepito Fernandez Jan 21 '16 at 16:41