Microsoft .NET security


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: Microsoft .NET security

  1. #1
    Blair Dillaway Guest

    Microsoft .NET security




  2. #2
    Michael Guest

    Re: Microsoft .NET security


    Test posting. Hello world!


    "Blair Dillaway" <blaird@microsoft.com> wrote:
    >
    >



  3. #3
    Blair Dillaway Guest

    Re: Microsoft .NET security


    Not certain why the body was lost in my earlier post,
    but here's the full text....

    Below you will find a copy of an email sent to Jason Harper
    in response to his recent article discussing Microsoft .NET
    security and privacy features (see
    <http://security.devx.com/upload/free/features/zones/
    security/articles/2000/11nov00/jh1100-1.asp> ).
    I am certain there is fairly broad interest in this topic and
    others may find the information below useful.

    Regards,
    Blair

    <--------------------------------------------------->


    Jason,

    Interesting article and you raise some good issues. There
    is a great deal of information already published on .NET
    features and functionality relevant to security and privacy.
    Obviously, we need to do a better job in communicating
    this information since you, and I must assume many
    others, seem to be unaware of it. I'm sure you can appreciate
    the problems in trying to adequately summarize an initiative
    with the scope of Microsoft .NET in the few short papers
    you cite as resources. Clearly we did not emphasize our
    security and privacy features to the extent you were expecting.

    As we release additional .NET products I'm certain you
    will see the importance we place on security and privacy
    reflected in the features and related product information.
    In particular, the .NET Framework contains a rich, and
    innovative, collection of security services. I've included a
    brief summary of those most relevant to your paper and
    additional references below. Most of this information was
    initially made public at the Microsoft Professional Developer's
    Conference in July of this year. Our first Beta was just released and is
    available at http://msdn.microsoft.com/net.

    In creating the .NET Framework, we decided it was critical to
    address the concerns of both application developers and end
    users regarding semi-trusted mobile code and componentized
    applications. In particular, it was clear we needed to provide
    end-users with an effective mechanism to constrain the behavior
    of semi-trusted code. At the same time, we needed to provide
    developers with mechanisms to: (1) indicate what authorizations
    their code needed to run; and (2) to control sharing of their
    components.

    This is a complex topic and I won't attempt to provide a
    comprehensive answer in this note. Rather, let me briefly
    summarize how we've addressed this problem. This glosses
    over a number of important details and you should read the
    references provided below if interested in how this works.
    Our approach relies on an innovative security model which
    we refer to as "Evidence-based Security". Evidence, in this
    context, refers to attributes about a piece of code. We use
    several types of code evidence in our base implementation
    to include Zone of origin, Site of origin, Authenticode publisher,and Assembly
    Strong Name (a unique, unspoofable, name
    supported by Visual Studio 7 and the .NET CLR). This is
    extensible by fully trusted code. Evidence is used as input to
    the .NET CLR security policy which determines authorizations
    for that code. These authorizations are reflected in a
    Permission set granted to code. When attempting to access a
    protected resource, the permissions of all code in the call chain are checked
    to insure they are authorized access. In essence, the behavior of code is
    constrained by the least trustworthy component. We refer to this as "Code
    Access Security". Developers can optionally mark their code with required
    permissions. We won't run this code if policy fails to grant the required
    Permissions, saving the developer from writing potentially complex runtime
    error handling code to insure graceful failure.

    This same model is used to provide a controlled sharing
    mechanism for code. In addition to the authorization Permissions
    granted to code, we also grant identity Permissions which
    reflect trustworthy Evidence. These can be used to limit who
    is allowed to call and/or subclass specific classes in code.

    Related Materials:
    PDC Presentations (see <http://msdn.microsoft.com/events/pdc/>).
    A few key presentations include:
    An Architectural Overview of the .NET Framework (3-313)
    .Net Frameworks Security (3-334)
    Security Considerations for Downloaded Controls (1-222)
    .NET Framework SDK documentation (B1)
    Building .NET Applications - Securing Your Application &
    Security Policy Management
    .NET Framework Reference - System.Security

    ASP.NET provides a rich new approach to building Web
    applications and supports dynamic page generation using
    server side code as well as Web-accessible objects
    (referred to as WebServices). In terms of the issues you raised,
    it is important to note that ASP.NET integrates with currently
    deployed Web security mechanisms. ASP.NET applications
    can take advantage of existing Web-oriented Authentication
    mechanisms. Support is included for Basic Auth, SSL
    Certificate-based Auth, NT Auth, Forms-based Auth,
    Cookie Auth, and Passport Auth. These can be customized in
    various ways as described in the SDK. The authenticated
    identities can be mapped to Win2000/NT accounts if one
    wishes to use the Windows platform access control mechanisms.
    Alternately, applications can provide their own authorization
    logic based on the authenticated identity.

    ASP.NET applications can also take advantage of existing
    mechanisms for confidentiality to include use of IPSEC
    and SSL.

    Related Materials:
    PDC Presentations (see <http://msdn.microsoft.com/events/pdc/>).
    A few key presentations include:
    Active Server Pages+ Security (4-443)
    Passport as a .NET Service (3-311)
    .NET Framework SDK documentation (B1)
    Building .NET Applications - Creating ASP.NET Web
    Applications
    .NET Framework Reference - System.Web.Security

    For applications that have special needs, we support an
    object oriented programming interface to cryptographic
    services. These include support for proven, industry standard,
    algorithms (DSA, RSA, DES, 3DES, SHA1, MD5, ...).
    Information on these can be found in the .NET Framework
    SDK Reference material under System.Security.Cryptography.
    There is also support for the W3C draft standard on XML
    Digital Signatures (see System.Security.Cryptography.Xml)
    and Microsoft is actively involved in other W3C XML-related
    security efforts that will be reflected in future products.
    Of course, the Microsoft CryptoAPI services are also still
    available for those who prefer a traditional C-API style
    of programming.

    Naturally, .NET applications hosted on Window 2000 and
    Windows NT still have access to the rich authentication,
    authorization, and security administration features of those
    platforms. Coupled with the features discussed above, we
    believe we offer our customers the best platform for building,
    deploying, maintaining, and running applications while addressing the critical
    concerns for security and privacy.

    Be interested in your thoughts once you've had a chance to
    review this and the referenced material. If you don't have the
    Beta release, you can find on-line documentation at
    <http://msdn.microsoft.com/library/default.asp?URL=/
    library/dotnet/cpguide/cpguide_start.htm>.

    You may also want to subscribe the DOTNET discussion alias
    (see <http://discuss.develop.com>).

    Regards,
    Blair Dillaway
    Software Architect, .NET Framework
    Microsoft Corp.

    CC: dotnet@discuss.develop.com; news.devx.com -
    security.internet list




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center