Security Guidance from patterns & practicesSummary

To help you build applications that meet your security objectives, the patterns & practices team at Microsoft has developed and released various forms of security guidance including application blocks, guides, and reference implementations. This document presents an overview of patterns & practices security guidance, explains common scenarios where the guidance applies, and shows you where you can download it.

Contents● Security Guidance at a Glance● About Microsoft patterns & practices● Security Guidance from patterns & practices ● Building Secure ASP.NET Applications: Authentication, Authorization and Secure

Communication● Improving Web Application Security: Threats and Countermeasures● Security Engineering● Threat Modeling Web applications● WS-I Basic Security Profile 1.0 Reference Implementation ● Web Services Security: Scenarios, Patterns and Implementation Guidance ● Security Guidance for .NET Framework 2.0 ● Security Application Block ● Cryptography Application Block ● SAML STS for WSE 3.0● Conclusion

Security Guidance at a GlanceTable 1 shows the guides, blocks and reference implementations discussed in this article.

Table 1: Security Guidance at a Glance

Guidance Type LocationBuilding Secure ASP.NET Applications: Authentication, Authorization and Secure Communication

Guidance http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp

Improving Web Application Security

Guidance http://msdn.com/secnet

Security Engineering Guidance http://msdn.com/securityengineering

Guidance Type LocationThreat Modelling Web Applications

Guidance http://msdn.com/threatmodeling

WS-I Basic Security Profile 1.0 Reference Implementation

Reference Implementation

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/MSWSIBSP.asp

Web Services Security: Scenarios, Patterns and Implementation Guidance

Guidance http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp

Security Guidance for .NET Framework 2.0

Guidance http://msdn.com/securityguidance

Security Application Block Application Block http://www.microsoft.com/downloads/details.aspx?FamilyId=5A14E870-406B-4F2A-B723-97BA84AE80B5&displaylang=en

Cryptography Application Block

Application Block http://www.microsoft.com/downloads/details.aspx?FamilyId=5A14E870-406B-4F2A-B723-97BA84AE80B5&displaylang=en

SAML STS for WSE 3.0 Emerging Practices http://www.gotdotnet.com/codegallery/codegallery.aspx?id=8da852b9-2c0d-4eb7-a2de-77222a4075f6

1.

About Microsoft patterns & practicesMicrosoft patterns & practices provide prescriptive engineering guidance to software architects and developers to help them build effective enterprise solutions and applications with the Microsoft technology platform. Formed in 2000 and previously known as the Prescriptive Architecture Guidance Group, Microsoft patterns & practices provide technical guidance that is created, reviewed and approved by Microsoft architects, product teams, consultants, product support engineers, and by Microsoft partners and customers. With a guiding principle of helping customers in the long term by providing good guidance in common problem areas, patterns & practices release guidance which most often conforms to one of the following basic types:● Application Blocks – These are reusable source code components that provide

proven solutions to common development challenges. They focus on specific recurring problem domains, such as data access, authentication, authorization, logging, user interface process and composite user interfaces. The Enterprise Library release from Microsoft patterns & practices is a consolidated set of application blocks that are packaged together to form a framework.

● Reference Implementations – These executable sample applications demonstrate guidance in action. Microsoft patterns & practices Reference Implementations cover topics such as application integration and interoperability using Web services

● Guides – This written guidance, either online or printed, provides a detailed description of technical problem domains and engineering practices. Guides cover topics, such as patterns, application architecture, integration, performance and security.

● Emerging Practices – This form of guidance is usually provided when products are under development, the technology is changing rapidly, or there are external dependencies.

Microsoft patterns & practices guidance is not centred on a single Microsoft product. Rather it provides solution guidance that is specific to particular scenarios. It describes how to use Microsoft products in the context of developing and deploying applications. Often, patterns & practices deliverables give details about how to incorporate multiple Microsoft products and technologies into one solution architecture. The architectures, designs, and implementations described in patterns & practices releases are coordinated with current and future Microsoft technical strategy.

To learn more about Microsoft patterns & practices, see http://msdn.microsoft.com/practices/gettingstarted/

Security Guidance From patterns & practicesAt the time of writing (April 2006) the following security guidance is available from patterns & practices.● Building Secure ASP.NET Applications: Authentication, Authorization and Secure

Communication ● Improving Web Application Security: Threats and Countermeasures● Threat Modelling Web Applications● Security Engineering ● Security Guidance for .NET Framework 2.0 ● The Security Application Block, which is part of Enterprise Library 2.0● The Cryptographic Application Block, which is part of Enterprise Library 2.0● Web Services Security Reference Architecture● SAML STS for WSE 3.0 QuickStart

The remainder of this article provides an overview of this security guidance, and explains the scenarios for which the guidance has been designed.

Building Secure ASP.NET Applications: Authentication, Authorization and Secure Communication

Distributed Web applications span products and technologies. You have many issues to consider when you secure this type of application because there are various application integration points, technologies and so on. Well designed authentication, authorization and secure distributed communication eliminate a high percentage of vulnerabilities in such applications. However, to build effective application-level authentication and authorization strategies, you must understand how to fine-tune the various security features within each product and technology area, and how to make them work together to provide an effective security strategy. This guide presents detailed guidance that helps you to design and build sound authentication, authorization and secure distributed communications strategies for your distributed ASP.NET applications.

Building Secure ASP.NET Applications is available online, and is also available for download in PDF format, on MSDN at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

Who Should Read the GuideThis guide applies to software architects and developers who plan to build, or are currently building .NET distributed Web applications by using one or more of the following technologies: ASP.NET, Web services, Enterprise Services, Remoting or ADO.NET.

Technologies the Guide Applies ToThe guide covers the following products and technologies:● ASP.NET 1.0● ASMX Web Services● Enterprise Services● .NET Remoting● ADO.NET● Windows Server 2000● SQL Server 2000

The information in the guide was built and tested on the .NET Framework Version1.0 SP2.

Highlights from the GuideThis guide is divided into four parts. The first part, Security Models, provides a foundation for the rest of the guide and it presents an overview of the security features, services and implementation technologies that span the tiers of a Web or distributed application. The second part, Application Scenarios, presents a set of common application scenarios that are categorized as intranet, extranet or Internet applications. You are then shown how to configure and implement the most appropriate authentication, authorization, and secure communication strategy for each application scenario. The third part, Securing the Tiers, contains detailed information that relates to the individual tiers that constitute an application and describes how each of these application tiers can be secured. The fourth part is a Reference section that contains supplementary information to help increase your understanding of the techniques, strategies, and security solutions that are presented in earlier chapters.

To focus your understanding of the guidance presented in this guide, consider the scenario where you want to design the authentication, authorization and communication strategy of an internet-facing ASP.NET application. Part II of the guide, Application Scenarios, dedicates a whole chapter to Internet security. The chapter gives details of two common internet application scenarios:● ASP.NET to SQL Server● ASP.NET to Remote Enterprise Services to SQL Server

For both these scenarios, the guide describes their relevant characteristics before explaining what security measures you can apply for each of them. The security summary of ASP.NET to SQL Server as described in the guide is shown in Table 1.

Table 1: Security Summary - ASP.NET to SQL Server

Category DetailAuthentication IIS is configured to allow anonymous access; the ASP.NET

Web application authenticates users with Forms authentication to acquire credentials. Validation is against a SQL Server database.

Users’ passwords are not stored in the database. Instead password hashes with salt values are stored. The salt mitigates the threat that is associated with dictionary attacks.

Windows® authentication is used to connect to the database by using the least privileged Windows account to run the ASP.NET Web application.

Authorization The ASP.NET process account is authorized to access system resources on the Web server. Resources are protected with Windows ACLs.

Access to the database is authorized by using the ASP.NET application identity.

Secure Communication

Secure sensitive data that is sent between the users and the Web application by using SSL.

Secure sensitive data that is sent between the Web server and the database server by using IPSec.

2.

Figure 1The recommended security configuration for the ASP.NET to SQL Server Internet

scenario

Improving Web Application Security: Threats and Countermeasures

The "Improving Web Application Security: Threats and Countermeasures" guide supplements the guidance that is presented in the "Building Secure ASP.NET Applications" guide. It takes a broader look at security across the tiers, and focuses on

threats and countermeasures at the network, host, and application levels and helps you build hack-resilient applications. A hack-resilient application is one that reduces the likelihood of a successful attack and mitigates the extent of damage if an attack does occur.

Improving Web Application Security: Threats and Countermeasures can be accessed online at http://msdn.com/secnet. It is also available in PDF format and can be downloaded from the above URL.

Who Should Read the GuideThis guide is for anyone concerned with planning, building, deploying, or operating Web applications. The guide contains essential information for designers, developers, system administrators, and security analysts. Designers will learn how to avoid costly security mistakes and how to make appropriate design choices early in the product development life cycle. Developers will learn how to implement defensive coding techniques and build secure code. System administrators will learn how to methodically secure servers and networks, and security analysts will learn how to perform security assessments.

Technologies the Guide Applies To● ASP.NET 1.1● Web Services● Enterprise Services● Remoting● ADO.NET● Windows Server 2000● SQL Server 2000

Highlights from the GuidanceThe guide takes a lifecycle-based approach to security and introduces a number of important security related activities that should be an integral part of your software development lifecycle. The underlying premise is that to build software that meets your security objectives, these activities must be central to your development processes.

Some of the core security related activities that are the subject of whole chapters in the guide include:● Identifying Security Objectives. This activity should be defined early in the

application development process. Security objectives are goals and constraints that affect the confidentiality, integrity, and availability of your data and application. If you do not know what the objectives are for your application then it is difficult to be successful with any other security activity. You use security objectives to filter the set of design guidelines that are applicable, guide threat modelling activities, determine the scope and guide the process of architecture and design reviews, help set code review objectives, guide security test planning and execution and guide deployment reviews.

● Threat Modelling. This activity is an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures relevant to your application. Use threat modelling to shape your application design to meet your security objectives, help make trade-offs during key engineering decisions, reduce risk of security issues that arise during development and operations. The threat modelling approach for Web applications that is presented in this guide forms the

basis of an extended and refined approach which you can see at http://msdn.com/threatmodeling.

● Security Architecture and Design Reviews. This process analyzes the architecture and design from a security perspective. If you have just completed the design, the design documentation can help you with this process. Regardless of how comprehensive your design documentation is, you must be able to decompose your application and be able to identify key items, including trust boundaries, data flow, entry points, and privileged code. You must also know the physical deployment configuration of your application. Pay attention to the design approaches you have adopted for those areas that most commonly exhibit vulnerabilities.

● Using Secure Principles, Practices and Design Guidelines. Web applications present a complex set of security issues for architects, designers, and developers. The most secure and hack-resilient Web applications are those that have been built from the outset with security in mind. In addition to applying sound architectural and design practices, it is important to incorporate deployment considerations and corporate security policies during the early design phases. Failure to do so can result in applications that cannot be deployed on an existing infrastructure without compromising security.

● Security Deployment Reviews. This activity ensures that configuration and deployment problems are discovered before they can result in an application vulnerability. Even the most securely designed and implemented application can be compromised by an error during deployment, by leaving it open to attack. When you review your security deployment, you can organize into categories the precautions that you must take and the settings that you must configure. By using configuration categories, you can systematically review the entire application, or pick a category and complete specific steps.

As another example of how you can use the guidance presented in "Improving Web Application Security: Threats and Countermeasures", consider the scenario were you, as a developer, want to understand the threats associated with your application's Web services and also want to learn what countermeasures can be applied for each of those threats. For this, you should begin by reading Part I of the guide, “Introduction to Threats and Countermeasures”. Part I highlights and explains the primary threats to Web applications at the network, host and application layers. It also shows you how to create threat models to help you identify and prioritize the threats that are most relevant to your particular application.

When you have acquired a sound understanding of various threats and associated countermeasures in general, you can then proceed to understand the threats and associated countermeasures that are specific to Web services. For this you can go directly to Part III of the guide, "Building Secure Web Applications", and read the chapter about "Building Secure Web Services". For example, the top threats directed at Web services, as mentioned in the chapter, are:● Unauthorized access● Parameter manipulation● Network eavesdropping● Disclosure of configuration data● Message replay

The chapter explains each of these threats in detail and also presents associated vulnerabilities and appropriate countermeasures as shown in the following example for the Unauthorized access threat.

Unauthorized AccessWeb services that provide sensitive or restricted information should authenticate and authorize their callers. Weak authentication and authorization can be exploited to gain unauthorized access to sensitive information and operations.

VulnerabilitiesVulnerabilities that can lead to unauthorized access through a Web service include:● No authentication used● Passwords passed in plaintext in SOAP headers● Basic authentication used over an unencrypted communication channel

CountermeasuresYou can use the following countermeasures to prevent unauthorized access:● Password digests in SOAP headers for authentication.● Kerberos tickets in SOAP headers for authentication.● X.509 certificates in SOAP headers for authentication.● Windows authentication.● Role-based authorization to restrict access to Web services. This can be done by

using URL authorization to control access to the Web service file (.asmx) or at the Web method level by using principal-permission demands.

Security EngineeringTechnology on its own does not make a system secure. To design, build, and deploy secure applications, you must have a good understanding of the business requirements of the application you are developing. Furthermore, you must integrate security into your application development life cycle and adapt your current software engineering practices and methodologies to include specific security-related activities. These activities are extensions to established software engineering activities, such as architecture and design reviews, code reviews and deployment reviews. Security engineering describes the set of security-related project activities that helps you to build software that meets your security objectives.

The security engineering guidance available at http://msdn.com/securityengineering builds upon and refines many of the security engineering activities introduced in "Improving Web Application Security: Threats and Countermeasures". Figure 2 shows the set of security engineering activities covered by the guidance.

{Insert figure: Security engineering activities.GIF}Figure 2Security engineering activities

Each of the activities is explained in detail and prescriptive guidance is presented to show you how to get started with each of the activities.

Who Should Read the GuideThis guide is designed to be used by team members from many different disciplines, including business analysts, architects, developers, testers, security analysts, and administrators. The guidance is task-based, and is centred on key security activities that should be performed at the various stages of the application life cycle.

Technologies the Guide Applies ToThe security engineering activities are not specific to any particular technology. If you are building software and you care about security, you should read the guidance. Companion checklists, which help you to ensure that you are doing the right thing with your particular choice of technology, are available for the following technologies:● .NET Framework 1.1 and 2.0● ASP.NET 1.1 and 2.0● ADO.NET 1.1 and 2.0● Enterprise Services● Remoting

● Web Services (ASMX 1.1 and 2.0)● SQL Server 2000● IIS 5 and 6.0

You should use the guidance presented in security engineering to learn more about the engineering activities that you can adopt in your organization for building more secure software. The activities you should adopt first will depend on the security objectives you have identified, as well as any outstanding problems your process or application currently has.

The following are some of the ways you can use this guidance:● Use it to learn about security engineering. Use the guide as an introduction and

then use the companion Web-based resources at http://msdn.com/securityengineering to learn more.

● Incorporate security engineering into your application life cycle. ● Create training and promote security engineering within your organization.

Highlights from the GuidanceAs an example of how you can use the guidance presented in security engineering, consider the case were you want to perform a security-related activity, for example, a security code review. Each module in the guide is self-contained and introduces and describes the security activity as a whole. Thus in the case of the Security Code Review module, the requirement for a security code review is established and its benefits are mentioned before the actual review methodology itself is described. The activity overview section of the module gives step-by-step guidance about how the review itself can be carried out. The steps that constitute the security code review activity are shown in Figure 3.

{Insert figure: Security Code Review Activity.GIF}Figure 3Code Review StepsThe code review steps are:● Step 1 - Identify security code review objectives. Establish goals and

constraints for the review.● Step 2 - Perform a preliminary scan. Use static analysis to find an initial set of

bugs and improve your understanding of where bugs are most likely to be discovered during further review.

● Step 3 - Review the code for security issues. Review the code thoroughly to find security vulnerabilities that are common to many applications. You can use the results of step 2 to focus your analysis.

● Step 4 - Review for security issues unique to the architecture. Complete a final analysis that focuses on bugs that relate to the unique architecture of your application. This step is most important if you have implemented a custom security mechanism or any feature designed specifically to mitigate a known security threat.

To help you ask the right questions while performing security code reviews, you could use the following two job aids, which are in the form of question lists:● Security Question List: ASP.NET 2.0 at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asp. You use the questions in this module to help you perform security code reviews on ASP.NET 2.0 applications.

● Security Question List: Managed Code (.NET Framework 2.0) at http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGQuestionList0002.asp. You use the questions in this module to help you perform security code reviews on managed code (.NET Framework 2.0) applications.

Threat Modelling Web ApplicationsThreat modelling is one of the security engineering related activities. It is an engineering technique that helps you identify threats, attacks, vulnerabilities and countermeasures that could affect your application.

Guidance to help you create threat models for Web Applications can be accessed online at http://msdn.com/ThreatModeling. The threat modeling approach at this location builds and refines the approach that was introduced in "Improving Web Application Security: Threats and Countermeasures".

Who Should Read the GuideThreat modeling should be read by architects and developers who are responsible for the architecture and design phases of an application.

You should use the guidance provided in Threat Modelling to help you identify the security objectives, threats, vulnerabilities and countermeasures associated with your application. Threat modeling begins early in the architecture and design phase of the application life cycle. Threat modeling helps you to shape your application's design, meet your company's security objectives, and reduce risk. As the life cycle progresses and your design and development evolve, you progressively add more detail to your threat model.

Highlights from the GuidanceAs an example of how you can use the guidance presented in Threat Modeling Web Applications, consider the scenario where you are new to threat modeling and would like to know how you can create a threat model for your application. The "Threat Modeling Web Applications" landing page located at http://msdn.com/threatmodeling, simplifies this by tabularizing the common usage scenarios and the associated resources. So in this example scenario where you want a quick start, the associated resource is How To: Create a Threat Model for a Web Application at Design Time. The How To presents an overview and a base set of considerations that you should keep in mind before you identify the actual threats associated with the application. Two considerations mentioned in the How To are:● Start with a whiteboard. It can be easier to get started by modeling on a

whiteboard before you capture information in documents or get lost in detail. A

helpful technique is to use a digital camera or whiteboard with print capability to document and distribute the information from the whiteboard.

● Use scenarios to scope the modeling activity. Identify the scenarios that are out of scope to help limit your threat modeling activity. For example, are operational practices out of scope?

After you have familiarized yourself with this base set of considerations, you can then identify the various security objectives, create and then decompose your application overview and finally identify the threats and vulnerabilities relevant to your application scenario and context. A set of key questions relevant to a vulnerable category in an application, such as authentication or input data validation, are provided to assist you in identifying threats associated with that category. For example, the input and data validation section has the following set of associated questions:● How could an attacker inject SQL commands? ● How could an attacker perform a cross-site scripting attack? ● How could an attacker bypass input validation? ● How could an attacker send invalid input to influence security logic on the server? ● How could an attacker send malformed input to crash the application?

WS-I Basic Security Profile 1.0 Reference Implementation

A WS-I Profile is a named group of Web services specifications at specific version levels, along with conventions about how they work together. Profiles make it easier to discuss Web services interoperability at a level of granularity that makes sense for developers, users, and executives who make investment decisions about Web services and Web services products. The WS-I Basic Security Profile 1.0 Reference Implementation gives you early access to guidance for securing interoperable Web services based on the WS-I Basic Security Profile 1.0. It consists of a sample application and a guide that describes the design and implementation of the sample application.

The WS-I Basic Security Profile 1.0 Reference Implementation can be accessed online on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/MSWSIBSP.asp.

Who Should Use The Reference ImplementationThe reference implementation is targeted at developers and architects who want to design and implement interoperable Web services with message layer security. By reading the guide included in the reference implementation and examining the Sample Application in detail, you can gain an understanding of how conforming to the BSP 1.0 helps you to create secure Web services that are interoperable.

Technologies the Guide Applies To ● Microsoft Visual C# ● Microsoft .NET Framework version 1.1 ● Microsoft SQL Server 2000a with SP3a ● Microsoft Web Services Enhancements (WSE) 2.0

Highlights from the GuidanceThe main focus of the reference implementation is to demonstrate secure Web service interoperability by using the Basic Security Profile 1.0. The reference implementation consists of a sample application and a guide that describes the design and implementation of the sample application.

The Sample Application is a series of interdependent Web services and databases that forms a Supply Chain Management application. It is based on a scenario that involves interactions between a consumer, a retailer, a series of warehouses, and a series of manufacturers. The retailer sells consumer electronics and manages stock in three warehouses. For every order, the application first checks Warehouse A. If Warehouse A cannot fulfill the order, the retailer then checks Warehouse B, and if Warehouse B cannot fulfill the order, it checks Warehouse C. When a warehouse’s inventory of a particular product falls below a certain threshold, the warehouse orders more units from the appropriate manufacturer. Figure 4, taken from the sample application guide, illustrates how the Web services in the Sample Application communicate with each other and with the client Web application.

{Insert figure: DPE - Security p&p WS-I fig.GIF}Figure 4Relationship between the Web services in the sample application.

Web Service Security: Scenarios, Patterns and Implementation Guidance for Web Services Enhancements (WSE) 3.0

There are a considerable number of options you can choose from when securing your Web services and the right option is dependent on the requirements of your solution. This guide helps you make the necessary decisions about Web services security by presenting the most common scenarios related to securing Web services and providing a scenario-driven approach to demonstrate where different security patterns are successful.

The Web Service Security: Scenarios, Patterns and Implementation Guidance for Web Services Enhancements (WSE) 3.0 can be accessed online on MSDN at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp. It is also available in PDF format and can be downloaded from the above URL.

Who Should Read the GuideThe target audiences for this guide are architects and developers who design or implement Web services and want guidance about how they can secure those Web services. It is assumed that the audience has experience of designing and developing Web service solutions or solutions with security requirements, such as authentication, authorization, or encryption.

Technologies the Guide Applies To● WSE 3.0● Web Services● Visual Studio 2005

The Web services security should be read by architects and developers who design or implement Web services and want guidance about how they can secure those Web services The recommended approach to this guide is to read from start to finish. Most of the content in this guide is presented in the form of patterns. The patterns are grouped into two main parts: ● Part I: Core Web Service Security Patterns – This core set of patterns that are

often inter-related and used together. These patterns, categorized as authentication patterns and message protection patterns, are mentioned below: ● Authentication Patterns

Direct Authentication (SQL, ADAM, Kerberos)Brokered Authentication (Kerberos, X.509, SAML)

● Message Protection PatternsData ConfidentialityData Origin Authentication (integrity)

● Part II: Additional Web Service Security Patterns and Guidance - These additional patterns should also be applied in many cases, and they can typically be applied after you have selected the core patterns you are implementing.

Highlights from the GuidanceIn an attempt to make the guidance more productive for you, this guide uses decision matrices to help highlight key criteria that should be considered when you select one approach rather than another. For example, you may not be clear which authentication method your Web services should employ. Should you choose direct authentication or brokered authentication? Table 2 shows a couple of points from the authentication decision matrix that lists security considerations related to authentication and how each one is supported by direct authentication methods or brokered authentication methods. This should help guide you through the process of choosing between direct and brokered authentication techniques.

Table 2: Authentication Decision Matrix

Security Consideration Direct BrokeredWhat will the service require to prove the client’s identity for authentication? Passwords, certificates, or something else?

Direct authentication requires the presentation of credentials, which are typically a user name and password. The service uses these credentials to authenticate the request.

Credentials are used to authenticate with the broker, which issues a security token. The security token is then used to authenticate with services.

Will the Web service be able to communicate with the authentication service that can validate the client’s credentials for authentication?

Direct access to the authentication service is required because authentication is performed,

Most implementations of brokered authentication do not require direct access to the authentication service.

3.

Additional ResourcesThere are a number of supplementary resources on the gotdotnet workspace including a compiled help file (CHM) version of the guide and a set of quickstart applications that use the code that is in the guide. A number of Webcasts are also available each of which discusses a particular aspect of Web service security guidance from the guide.

For more information, see:● Web Service Security Implementation QuickStarts at

http://go.microsoft.com/fwlink/?LinkId=57044● Web Service Security Community Workspace at http://go.microsoft.com/fwlink/?

LinkId=57044● MSDN Architecture Webcast: Web Services Security Patterns at

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032280306&Culture=en-US

● MSDN Architecture Webcast: Securing Web Services with X.509 Certificates in WSE 3.0 at http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032287590&Culture=en-US

● MSDN Architecture Webcast: Securing Web Services with Kerberos in WSE 3.0 at http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032287592&Culture=en-US

● MSDN Architecture Webcast: Authentication to Web Services with UsernameToken in WSE 3.0 at http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032287594&Culture=en-US

Security Guidance for .NET Framework 2.0patterns & practices developed and released Security Guidance for .NET Framework 2.0 to enhance existing security guidance contained in guides, such as "Building Secure ASP.NET Applications" and "Improving Web Application Security", and to take advantage of the new security features available in .NET Framework 2.0,. The guidance is modular and specific so it enables you to navigate and find guidance that relates to your problem more quickly.

Security Guidance for .NET Framework 2.0 can be accessed online at http://msdn.com/securityguidance

Who Should Read the GuideThis guide should be read by software architects and developers who plan to build or are currently building .NET Web applications by using .NET Framework 2.0.

Technologies the Guide Applies To● .NET Framework version 2.0● ASP.NET (1.1 and 2.0)● ASML Web Services● Enterprise Services● ADO.NET 2.0

Guidance that applies to a particular version of the .NET framework (1.1 or 2.0) is highlighted appropriately.

Highlights from the GuidanceSecurity Guidance for .NET Framework 2.0 presents actionable, modular content of various types including scenarios and solutions, guidelines, explained, checklists and How Tos.

A brief explanation of the various types of content included in the guidance is given below.● Scenarios and Solutions. These are end-to-end application scenarios that focus on

key engineering decisions. ● Guidelines. These define the recommended guidance that focuses on what to do,

why and how. ● Practices. This is concise prescriptive guidance that tells you how to perform a

particular task. ● Checklists. These are job aids to ensure that you are doing the right thing.● How Tos. These provide step-by-step task-based guidance that focuses on a

specific task. ● Explained. These articles explains how things work together with design intentions

and usage scenarios. ● Walkthrough - Narrative hand-holding to walk you through an activity. ● Template – A standardized template to help execute the activity or steps.

As an example of how you can use the guidance, consider the scenario where you want step-by-step guidance about how you can improve security when hosting multiple applications in ASP.NET 2.0. The guidance is made up of modular content. This means that when you have a specific problem, you can find specific guidance that will give you the steps to work through the problem.

The How Tos index is further organized by technology and in alphabetical order. So in the case of improving security when hosting multiple applications in ASP.NET 2.0, you know that the technology is ASP.NET 2.0 and thus you can look for the how to in the list of How Tos mentioned in the ASP.NET 2.0 section.

How Tos are self-contained. Each How To mentions the objectives of that particular How To and gives an overview of the problem before moving to the solution. So for instance,

the overview section of How To: Improve Security When Hosting Multiple Applications in ASP.NET 2.0 lists the following ways of isolating ASP.NET 2.0 applications:● Use code access security - Run each application with partial trust, for example,

by using the ASP.NET Medium trust level. This provides a constrained execution environment (which is also known as a sandbox) for each application where permissions to access system resources and resources belonging to other applications are limited.

● Use separate processes for each application - On Windows Server 2003 and IIS 6.0, run each application in its own application pool that is configured to run under a unique identity. This enables you to use Windows auditing to audit the activity of each application separately, and it enables you to configure Windows access control lists (ACLs) independently for each application.

● Use separate encryption and decryption keys - Ensure that the keys specified in the machineKey element are unique for each application. These keys are used to encrypt items, including forms authentication tickets and view state. Separate keys, help you to ensure data integrity, even if data from one application is accessed by another.

Security Application BlockThe Enterprise Library Security Application Block is reusable and extensible source code-based guidance that simplifies development of common security functionality in .NET-based applications and helps developers implement common authorization-related functionality in their applications. Applications can use the application block to support authorization and to cache a user's authorization and authentication data.

The Security Application Block is part of the Enterprise Library for .NET Framework 2.0 and can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=5A14E870-406B-4F2A-B723-97BA84AE80B5&displaylang=en

Who Should Use this Application BlockThe Security Application Block is targeted towards developers who design or develop common user authorization and security-related caching functionality in their applications. The application block provides source code that can be used "as is," extended or modified by developers to use on enterprise development projects.

Technologies the Guide Applies To● .NET Framework 2.0

The Security Application Block includes implementations of the following functions: ● Authorization ● Security-related caching and session management

If your applications require the provided implementations, you can use the application block to provide this functionality. However, the application block is also designed to be extensible and includes generic providers for each function. You can adapt the providers to meet your own security requirements.

Highlights from the GuidanceThe Security Application Block abstracts application code from specific security providers and simplifies writing user authorization code by using security providers, such as

Microsoft Active Directory service, Authorization Manager, Active Directory Application Mode (ADAM), and other custom authorization providers. With the Security Application Block, you can change underlying security providers through configuration changes without changing the underlying application code.

As an example of how you can use the Security Application Block to perform common security tasks, consider the scenario were you must determine if a user is authorized to perform a task within your application. To enable you to quickly understand and become productive with the application blocks, the Enterprise Library includes QuickStarts that are brief, easy-to-understand illustrations of key application block features. The QuickStarts are a set of implementations that highlight common application block usage scenarios. The Security Application Block QuickStart includes the following common scenarios:● Obtaining a temporary token for an authenticated user ● Authenticating a user by using a token ● Terminating a user session (Expiring a token) ● Determining whether a user is authorized to perform a task

The Enterprise Library installation installs short cuts to the QuickStart applications associated with the various application blocks. Separate solutions exist for C# and Visual Basic. The documentation explains the scenarios. For example, you have documentation that briefly explains how you can determine whether a user is authorized to perform a task, in addition to the QuickStart solution, which you can compile and execute to see the application block in action. The following code snippets are taken from the QuickStart documentation that explains how you can determine if a user is authorized to perform a particular task1. Create a GenericPrincipal object representing the user and role information by

adding the following code. IPrincipal principal = new GenericPrincipal(new GenericIdentity("tim"), new

string[]{"Manager"});

2. Perform the authorization check by adding the following codebool authorized = ruleProvider.Authorize(principal, "Submit Order");

Cryptographic Application BlockThe Enterprise Library Cryptography Application Block is reusable and extensible source code-based guidance that simplifies development of common cryptographic functionality in .NET-based applications. Applications can use the application block for a variety of tasks, such as encrypting information, creating a hash from data and comparing hash values to verify that data has not been altered

The Cryptography Application Block is part of the Enterprise Library for .NET Framework 2.0 and can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=5A14E870-406B-4F2A-B723-97BA84AE80B5&displaylang=en

Who Should Use this Application BlockThe Cryptography Application Block is targeted towards developers who design or develop common cryptographic functionality in their applications. The application block provides source code that can be used "as is," extended or modified by developers to use on enterprise development projects.

Technologies the Guide Applies To● .NET Framework 2.0

You should consider using the Cryptography Application Block when you require hashing and/or symmetric encryption functionality. You can use these functions in conjunction with the cryptographic providers included with the application block or with your own custom cryptographic providers. A prerequisite for symmetric encryption is that the application that sends the data and the application that receives the data trust one another. Typically, this is only true if the sender and the receiver are the same application. This restriction often precludes the use of the application block for encrypting data across the network. Two other points you should consider when you use the Cryptography Application Block are how you are going to manage symmetric encryption keys and which hashing algorithm or symmetric encryption algorithm you are going to use.

Highlights from the GuidanceThe Cryptography Application Block abstracts application code from specific cryptography providers, so you can change underlying providers through configuration changes without changing the underlying application code. It is extensible and supports additional implementations of cryptography providers.

The Cryptography Application Block supports all .NET cryptography algorithms. It provides operation on strings and byte streams and allows you to:● Perform symmetric encryption● Perform symmetric decryption● Create a hash value from data● Check whether a hash value matches some text

As an example of how you can use the Cryptography Application Block to perform common cryptographic tasks, such as encryption and decryption within your application, consider the scenario were you want to encrypt a secret. To enable you to settle down quickly with the application blocks, the Enterprise Library includes QuickStarts that are brief, easy-to-understand illustrations of key application block features. The QuickStarts are a set of implementations of common application block usage scenarios. The Cryptography Application Block QuickStart includes the following common scenarios:● How to encrypt a secret● How to decrypt a secret● Getting a hash value from data● Check whether a hash value matches some text

The Enterprise Library installation installs short cuts to the QuickStart applications associated with the various application blocks. Separate solutions exist for C# and VB.NET. Enterprise Library documentation further explains the QuickStart scenarios. Thus, in the case of encrypting a secret, you have documentation that briefly explains how you can encrypt some text, in addition to the QuickStart solution, which you can compile and execute and see the application block in action. The following code samples are taken from the QuickStart documentation explaining how you can encrypt a secret1. Declare the appropriate variables and constants.

const string symmProvider = "symprovider";

string stringToEncrypt;

string encryptedContentsBase64;

2. Obtain the text from the user. stringToEncrypt = "Sample text";

3. Call the static EncryptSymmetric method on the Cryptographer class to perform the encryption, by supplying the name of the configured symmetric provider to be used.encryptedContentsBase64 = Cryptographer.EncryptSymmetric(

symmProvider, stringToEncrypt);

SAML STS for WSE 3.0When you design Web service authentication, there is often a requirement to authenticate the client's identity if the Web service and the client do not trust each other directly and operate in heterogeneous environments that are isolated by firewalls. Brokered authentication and more specifically, brokered authentication by using Security token services (STS) is a solution in such a scenario. In brokered authentication, an authentication broker serves to bridge the trust gap between the client and the Web service. The authentication broker is trusted independently by both the client and the Web service.

STS is a Web service that authenticates a client by validating the credentials presented by the client. On successful authentication, the STS issues a security token to the client, such as a Security Assertion Markup Language (SAML) token. The client then presents the security token to the Web service. XML-Security Assertion Markup Language (SAML) tokens are cross-platform interoperable standards-based XML tokens that are used to exchange security information, including attribute statements, authentication decision statements, and authorization decision statements. SAML tokens are extensible. Microsoft products use the WS-* specifications, which include the use of SAML assertions.

This QuickStart demonstrates how to develop a STS by using WSE 3.0, which issues custom XML tokens that are based on the SAML 1.1 specification. The XML tokens can be used by a client to authenticate with a service that trusts the STS. The QuickStart includes a design document, an implementation pattern, and source code in the form of a sample application

The QuickStart is available at http://www.gotdotnet.com/codegallery/codegallery.aspx?id=8da852b9-2c0d-4eb7-a2de-77222a4075f6

Who Should Use this QuickStartThe QuickStart should be used as a starting point by developers who are interested in developing their own custom security token services. Developers using the QuickStart should have experience of developing Web services by using Visual Studio 2005 and WSE 3.0, and should also be familiar with the capabilities of a solution that brokers authentication.

Technologies the Guide Applies To● WSE 3.0● Visual Studio 2005● SAML V1.1● Web Services

This SAML STS for WSE 3.0 QuickStart is an extension of the Web Service Security guide and is a type of deliverable from patterns & practices called "Emerging Practices”. Emerging Practices is a form of guidance usually provided when products are under development, the technology is changing rapidly, or there are external dependencies. The STS design pattern appears in the guide but does not include an associated implementation pattern. This QuickStart includes the implementation pattern, called "Implementing Message Layer Security with a STS in WSE 3.0", and is accompanied by a QuickStart solution. The SAML STS for WSE 3.0 QuickStart solution contains a substantial amount of code, and it is recommended that anyone who wants to build a production system by using this code should be very familiar with all of the code within the solution.

The QuickStart should be used as a starting point by developers who want to develop their own custom security token services. It can also be used by developers to improve their understanding of the STS design pattern that is documented in the Web services security guide.

Highlights from the GuidanceThe SAML STS for WSE 3.0 QuickStart includes a design document and an implementation pattern in addition to the sample application. The design document supplements the sample application with background information and information about the design of the sample solution. The implementation pattern is based on the sample code and it demonstrates how to implement message layer security with a Security Token Service (STS) in WSE 3.0.

The STS scenario implemented in the sample solution contains the following participants:● A simple service, HelloWorld Service, which replies with a "Hello World!" message.

This service requires a token created by the SAML STS.● A Client application which consumes the HelloWorld service. This application

cannot consume the service directly because it expects some SAML assertions (such as the user name) to be given by a valid authority.

● An authority that can emit SAML assertions. Both, the client and the service trust this service.

The design document further explains the process and steps required to execute the Hello World service and the various components that constitute the STS architecture.

ConclusionThe patterns & practices team has released a wealth of security guidance to help you architect and develop solutions by using Microsoft platform technologies that meet your security objectives. For anything other than the most trivial desktop application this guidance is essential reading. Applying the guidance and using the sample code and frameworks such as the Enterprise Library can save you significant time and money, and can contribute to the overall security and robustness of your solutions.