Tech Off Thread

6 posts

Lack of Managed Authentication

Back to Forum: Tech Off
  • User profile image
    aza

    Hi,

    The two biggest holes I have encountered in the .Net libraries are probably NTFS file access and user authentication. I fully appreciate that shifting from a Win32 API to a new API (in this case .Net) is a "huge" task and hopefully these two aspects are coming...

    In the meantime I have a question about what would be a good way to handle non-repudiability in an Active Directory environment.

    The System.Security.Principal.WindowsIdentity class lets me know the authenticated user is and the System.Net.NetworkCredential class even lets me make use of the authenticated user's credentials when using IIS. But what if the application needs to digitally sign a SOAP request or do some other cryptographic type operation on behalf of a user?

    I got a little bit excited with the release of WSE2 when I saw the multitude of classes and support available for digital signatures. However after playing around with it a bit I found that the classes to create security tokens from an XML signature, or similar, were all inaccessible and could only be used by way of an IIS SOAP extension, thus allowing only very narrow usage scenarios.

    I appreciate that using the Win32 API it is possible to serialise Windows security tokens but this is a task that would take weeks to month(s) rather then the day(s) that we, as .Net developers, are now expected to operate under.

    The ability to utilise single sign on and at the same time leverage distributed computing paradigms such as web services and remoting all require user authentication. Not having a managed API is a major, major disadvantage to being able to utilise one of the most basic services of a Windows environment!

    Thanks,
    Aaron

  • User profile image
    spod

    Hi aaron

    i think my team is building what you are looking for ( as part of longhorn ), but i'm not quite clear from your mail on a couple of specifics ( so might be completely off the mark Smiley )


    When u say "you can sign soap requests on behalf of the user" do you mean you would like the user to be automatically assoicated with a cert / private/public key pair  that can be used for digitally signing etc? Or are you just looking for a way to interface with the certificate api in managed code?



  • User profile image
    aza

    spod wrote:

    When u say "you can sign soap requests on behalf of the user" do you mean you would like the user to be automatically assoicated with a cert / private/public key pair  that can be used for digitally signing etc? Or are you just looking for a way to interface with the certificate api in managed code?

    Hi spod,

    Any samples coming before Longhorn perchance? Wink.

    In answer to your question no I am not really looking for more cryptographic hooks for signing, encryption etc., What's currently available in the .Net BCL is more than suficcient.

    What is missing, at least for me, is the key management piece. Obviously this is not something that can be provided by a library alone it also depends very heavily on the underlying platform. What I am talking about is hooks into the coupling of Active Directory and cryptographic mechanisms. 

    A simple example of what I was trying to articulate in my last post is:

    An application running on machine A signs a message on behalf of user A and then sends the message to an application running on machine B. The application on machine B is able to verify that the message came from user A using the platform's security services, i.e. Active Directory.  

    There are numerous more use cases especially around getting remote processes to use delegation and impersonation, particularly with regards to web services and remoting (IIS mechanisms are not always suitable).

    I do have the managed SSPI example that is available on msdn and this has temporarily filled my gaps in the past. But I look forward to having more managed access into the Window's security infrastructure.

    A positive side benefit is that my C++ got a workout trying to solve some of these problems Smiley.

    Aaron

  • User profile image
    spod

    It does sound like what we are building. I'll talk to people and see how much i can tell you publically about it all...

    Like you say, a lot of this is platform stuff, so is unlikely to show up before longhorn ( certainly that's the timeframe we are targetting... )

    I hear you on the c++ workout...my favorite part is that the unmanaged crypto apis are big-endian, and the .net framework equivalents little-endian, so you have to watch byte order during interop etc. It's been a while since i've had to worry about that Smiley 

  • User profile image
    aza

    Hi spod,

    Seeing as how you are going to be asking some questions in the platform security area...Wink

    Is there any update on the status of Palladium (aka Trusted Computing Platform, aka NGSCB, aka La Grande etc. etc.)? Is it still on the roadmap or have the rather ironic concerns of privacy advocates caused a rethink (I say ironic because the same advocates often desire a more secure platform and not because I consider privacy irrelevant)?

    One among many reasons I ask this is that from an application developer's perspective I see a big need for an application secure store. The user should always be able to remove the application, including the store, but an application often needs to have a security layer that is not dependent on the user.

    An example would be a peer-to-peer application. The application wants to expose services on participating peers but only to instances of the same or designated applications. Today the only security mechanisms available, on any PC platform (since it's a hardware problem), are user based.

    Aaron

  • User profile image
    aza

    Seems like Intel is assuming it's full steam ahead with LaGrande and Longhorn.

    http://www.intel.com/cd/ids/developer/asmo-na/eng/97003.htm

    An interesting point in the article is the mention of the need for the NGSCB software to run alongside the OS and mediate access for application to secure hardware functions. So computers will now have two OS'? Or even three with the BIOS' getting more and more advanced. Sigh.. it's just as well WinFX is going to abstract away all this complexity for us poor application developers.

    By the way does anybody know any of those memory drugs I am pretty sure my head is nearly full but there's still Yukon, Longhorn etc. etc. to go.

    Aaron

    P.S. Please excuse me for conversing with myself.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.