Using an X.509 Certificate in WSE 2.0

The following code shows how to wrap an X.509 certificate in WSE 2.0.

using Microsoft.Web.Services2.Security.X509;

public static X509Certificate GetCertificate(string subjectString)
{
// create an X509 certificate store and open it for read.
X509CertificateStore store = X509CertificateStore.CurrentUserStore(X509CertificateStore.MyStore);
bool open = store.OpenRead();
if (open == false)
return null;

// Finds a X509Certificate object in the store using the certificate's name value.
X509CertificateCollection certs = store.FindCertificateBySubjectString(subjectString);
store.Close();
X509Certificate cert = (X509Certificate)certs[0];

return cert;
}

X509CertificateStore.MyStore represents the predefined system certificate store "My". This field is constant. The subjectString is the certificate's name value.

References:
Michael Stiefel, Securing Service Oriented Architecture with WSE 2.0

X.509 Certificates

You can obtain an X.509 certificate by using one of the well-known certificate authorities (CA) like Verisign, or simply by creating your own CA using Windows Certificate Services. After installing this service—which is an optional component of Windows 2000 Server or Windows Server 2003—you can point your browser to http://servername/certsrv to request the creation of a new certificate. After authorization of your request by a system administrator, you can add your newly created certificate to your private certificate store by using the same Web application at http://servername/certsrv. Please also make sure to add the certification authority's root certificate to your Web server's "Local Machine" store by manually selecting the store location (including "physical location") during the certificate import.

You can use the Certification Creation Tool (makecert.exe) to create an X.509 certificate for testing purposes and then convert it to an SPC (software publisher's certificate). The following command creates a new X.509 certificate and a private key file.

makecert -sv TestPrivateKey.pvk TestCert.cer

Then you can convert the X.509 certificate into an SPC with the SPC Test tool (cert2spc.exe), as follows:

cert2spc TestCert.cer TestSPC.spc

You can sign an assembly with an SPC as follows:

signcode -spc TestSPC.spc -v TestPrivateKey.pvk Test.dll

If you right-click the assembly in the Windows Explorer and select the Properties menu item, you will see that a Digital Signature tab is available.

You might get an X.509 certificate from other people. To use it in your programs, you need to install it in the local machine store. To install X.509 certificates, open a MMC console with the Certificates snap-in. In the console tree, under Personal, click Certificates. Open the certificate import wizard by opening the context menu, click Import. Follow the instructions in the Wizard to import the certificates. You may install in the Local Computer Personal Certificates account in a similar way.

References:
Ingo Rammer, Using Role-Based Security with Web Services Enhancements 2.0
Adam Freeman and Allen Jones, Programming .NET Security
Michael Stiefel, Securing Service Oriented Architecture with WSE 2.0

Using the ASP.NET Credentials Management Infrastructure in a Windows Forms Application

Juval Lowy published an article Unify Windows Forms and ASP.NET Providers for Credentials Management recently. In his article, Juval showed us how to use the ASP.NET credentials management infrastructure in a Windows Forms application. This includes how to use the ASP.NET 2.0 security providers model customly as well as many small coding tips. It's really an excellent article.

As a side note, I learned from his article that the ASP.NET providers require a few nontrivial permissions, including unmanaged code access permisions, unrestricted SQL Server client access permissions, and minimal ASP.NET Hosting permissions.

To address the elevated permission issue in smart client environments, Juval suggested to use a Web service, a very good approach.

Network Sniffers

I use Network Monitor to watch network communications. It only allows me to watch the communications between the local machine to a remote machine. The full-blown version of Network Monitor does allow you to watch network communications between two remote computers and is included in SMS.

A coworker recommended me "ethereal", another popular protocol sniffer. "ethereal" does allow you to watch network communications between two remote machines. You can download a free copy from http://www.ethereal.com/distribution/win32/.

Microsoft Internet Security and Acceleration (ISA) Server 2004 is a rule-based firewall with packet-level, circuit-level, and application-level filtering capabilities. So it can also be used to watch Internet traffic. I never use ISA before and plan to use it.

Securing Service Oriented Architecture with WSE 2.0

Michael Stiefel gave an excellent talk on securing service oriented architecture with WSE 2.0 at a group meeting of the .NET Developer Association tonight. I like his sample very much. You can get his sample and the pdf file of his presentation from Securing Service Oriented Architecture with WSE 2.0 .

Manipulate Privileges in Managed Code

In his article Manipulate Privileges in Managed Code Reliably, Securely, and Efficiently, Mark Pustilnik offered two solutions on how to manipulate token privileges from managed code: the first, simpler one, is tailored to the .NET Framework 1.1 and can be used today. The second solution incorporates several advanced features available only in the .NET Framework 2.0.

I particularly like his first two sections on privileges and how to change them.

Constrained Execution Regions in the .NET Framework 2.0

Within the .NET Framework 2.0 is ReliabilityContractAttribute, a custom attribute that defines a contract specifying the reliability guarantees that a method makes in the face of exceptional conditions. Constrained execution regions help implement code that satisfies the contract specified by the ReliabilityContractAttribute by moving CLR-induced failures to either before or after a block of code that executes under some constraints. CLR-induced failures include running out of memory while JITing code, as well as aborting a thread.

A brief introduction to constrained execution regions (CERs) is given in Mark Pustilnik's article Manipulate Privileges in Managed Code Reliably, Securely, and Efficiently.

Access to ACLs with the .NET Framework

With the .NET Framework 1.x, access to ACLs can only be granted to users via a series of cumbersome platform invocation (P/Invoke) calls.

The .NET Framework 2.0 allows developers to manipulate security settings of objects in a few easy steps using managed code. It does so by introducing the concepts of security objects and rules. The framework classes will be included in the new System.Security.AccessControl namespace.

Programming the inheritance part of the access control is not easy. Sementics part is easy, but the logical part is hard. Here is a list of terms being used:

• Explicit rules
• Inherited rules
• Container inherit
• Object inherit
• Inherit only
• No-propagate inherit

The Framework now models Windows security descriptors, allowing you to programmatically read and modify access control lists (ACL), take ownership of objects, convert between security descriptor description language (SDDL) strings and binary security descriptors, and more.

Read Mark Pustilnik's article Safety in Windows: Manage Access to Windows Objects with ACLs and the .NET Framework in more detail.

Some Basic Facts About Access Control

The follow are some basic facts about access control. The notes are taken from Keith Brown's book The .NET Developer's Guide to Windows Security.

Each object protected by the Windows discretionary access control system must have some state associated with it to track its security settings. This little bundle of state is often referred to as a "security descriptor." Logically, here's what that state must contain:

• Owner SID
• Group SID
• DACL: Discretionary Access Control List
• SACL: System Access Control List
• Control flags

The owner SID is the user that is always allowed to control the DACL of the object. This means that the owner can control who is allowed to use the object and in what ways. The owner SID can be a user or a group. The latter is a special case that occurs only with the local Administrators group. The operating system has traditionally set the default owner SID for administrators to be the Administrators local group. On Windows XP, the default policy has changed: Administrators have personal ownership of objects they create, just as normal users do. On Windows Server 2003, the default policy is what it has always been: Administrators are treated specially, and they share ownership of objects by default.

The group SID, also known as the "primary group," isn't used at all by Win32 applications. It's actually there to support UNIX applications that run in the optional POSIX subsystem.

The discretionary access control list (DACL) contains a list of permissions granted or denied to various users and groups. The reason it's called "discretionary" is that the owner of the object is always allowed to control its contents. Contrast this to the system access control list (SACL), over which the owner has no special control. In fact, usually the owner of an object isn't even allowed to read it. The SACL is designed for use by security officers, and it specifies what actions will be audited by the system.

Access Control Lists (ACL; rhymes with "cackle") are used in two ways in Windows security. One type of ACL is designed to gate access, and the other is designed to audit access. The DACL in a security descriptor is used to gate access whereas the SACL is used for auditing.

Finally, there are two control flags that arguably should be part of the DACL and SACL headers but instead are specified as part of the security descriptor.

• SE_DACL_PROTECTED
• SE_SACL_PROTECTED

These flags control the flow of inherited Access Control Entries (ACE)s in a hierarchical system.

Each record in an ACL is called an Access Control Entry, or ACE, and includes the SID of a single user or group along with a 32-bit access mask that specifies the permissions being granted, denied, or audited. Each entry also includes a set of flags used to determine how it participates in ACL inheritance, if at all.

When performing access checks, ACEs are evaluated in order, from top to bottom, until either all requested permissions are granted or one or more requested permissions are denied.