Tài liệu Module 8: Making Applications Secure ppt

Explain that assigning Windows 2000 groups to roles is the recommended approach and as a result one tool—the Active Directory Users and Computers tool—can be used to administer both Wind

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, BackOffice, MS-DOS, Windows, Windows NT, Active Directory, PowerPoint, and Visual Basic are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Instructor Notes

This module provides students with an overview of the security features available in Microsoft® Windows® 2000 Students will learn how to use roles to secure COM+ applications both declaratively and programmatically Students will also learn how to establish the identity of their COM+ server and select the appropriate level of authentication for their application

After completing this module, students will be able to:

! Describe the major security features and security models provided by the Windows 2000 platform

! Explain how authentication and authorization works

! Describe the authentication options available to Internet solutions based on COM+ and Internet Information Services (IIS)

! Implement declarative security by using COM+ roles

! Implement programmatic security by using security context information

! Assign an identity to a COM+ application

In the labs, students will secure the Purchase Order Online application declaratively by using COM+ roles They will also implement programmatic security to determine whether a caller is a member of a particular role Finally, they will assign an identity to a COM+ application and observe the effect of the new identity

Materials and Preparation

This section provides you with the required materials and preparation tasks that are needed to teach this module

Required Materials

To teach this module, you need the following materials:

! Microsoft PowerPoint® file 1907A_08.ppt

! Module 8: Making Applications Secure

! Lab 8.1: Implementing Declarative Security

! Lab 8.2: Implementing Programmatic Security

! Lab 8.3: Assigning a COM+ Application Identity

Preparation Tasks

To prepare for this module, you should:

! Read all of the materials for this module

! Complete the labs

! Read the instructor notes and margin notes for the module

Presentation:

90 Minutes

Labs:

75 Minutes

Demonstration

This section provides demonstration procedures that will not fit in the margin notes or that are not appropriate for the student notes

Creating and Assigning a Role

This demonstration shows how to create COM+ roles and to assign them to specific components, interfaces, and methods It also shows how to add Windows 2000 group and user accounts to COM+ roles

! To perform the demonstration

1 Open the Component Services tool and select the Purchase Order application

2 Expand the Purchase Order application and select the Roles folder, which will initially be empty

3 Right-click, point to New, and then select Role

4 Enter the role name Senior Manager Point out that role names tend to be

singular, as opposed to Windows 2000 group accounts, which tend to be plural

5 Click OK to dismiss the Role dialog box

6 Repeat steps 2 to 5 to add a second role named Junior Manager

7 Point out that the roles are currently defined at the application level

8 To assign a role at the component level, select the POBusiness.bus_Order component within the Components folder Right-click and select

Properties

9 Select the Security tab of the Properties dialog box and explain that the

roles list initially displays all of the roles defined within the application (in this case, Senior Manager and Junior Manager)

10 To apply the Senior Manager role to this component, place a check mark next to the Senior Manager role Explain that this check mark means that the caller must be a member of the Senior Manager role to access the

POBusiness.bus_Order component

11 Click OK to dismiss the Properties dialog box

12 Now expand the Interfaces folder beneath POBusiness.bus_Order

13 Select and then right-click the _bus_Order interface and select Properties

14 Select the Security tab of the Properties dialog box

15 Explain that the Senior Manager role applied at the component level has been inherited implicitly by the interface Also explain that additional specific roles may be applied to this particular interface

16 Place a check mark next to the Junior Manager role to grant junior managers

access to the _bus_Order interface

17 Click OK to dismiss the Properties dialog box

18 Now expand the _bus_Order interface and then expand the Methods folder

19 Select and then right-click the Raise method and select Properties

20 Select the Security tab of the Properties dialog box and explain that roles

can be applied at the method level In this case, because all of the roles have

been granted access to the _bus_Order interface, all roles will implicitly be granted access to the Raise method

21 Click OK to dismiss the Properties dialog box

22 Explain that roles allow you to apply authorization policies without worrying about precisely which accounts will be a member of a particular role An administrator typically establishes which accounts will be a member of a particular role at deployment time

23 Select and expand the Senior Manager role within the Roles folder

24 Select the Users folder, which will initially be empty

25 Right-click and point to New, and then select User

26 From the displayed dialog box, select the Senior Managers group and click

Add

27 Click OK to dismiss the dialog box

28 Explain that you have associated the Senior Managers Windows 2000 group with the Senior Manager role Explain that assigning Windows 2000 groups

to roles is the recommended approach and as a result one tool—the Active Directory Users and Computers tool—can be used to administer both Windows 2000 and COM+ security

Assigning a COM+ Application Identity

This demonstration shows how to configure a COM+ application to run by using a specific Windows 2000 user account, as opposed to using the interactively logged-on user

! To perform the demonstration

1 Open the Component Services tool and select the Vendor Processing application

2 Right-click and select Properties

3 Select the Identity tab on the Properties dialog box

4 Explain that the Interactive User is the default setting for a new application,

but it should generally only be used for debugging purposes Select the This user option and then click Browse

5 Select VendorApp from the Select User or Group dialog box and click

OK

6 Click OK to dismiss the Properties dialog box and explain that when the

application is next launched, it will run using the VendorApp user account Explain that the access rights and permissions established for this account will affect the capabilities of the COM+ application

Module Strategy

Use the following strategy to present this module:

! Overview of Windows 2000 Security Discuss the Windows 2000 security model and features While Windows

2000 is fully compatible with previous versions of Windows NT, Windows

98, and Windows 95, the security model has been enhanced considerably, notably by the introduction of the Kerberos authentication protocol and the increased emphasis on Internet-based security technologies Review the terminology defined in the “Security Terminology and Concepts” topic, including Public Key Cryptography

Discuss how the distributed security model has been designed to support enterprise applications Explain that security groups can be managed centrally in Active Directory to provide control over access to resources Explain that Windows 2000 supports multiple security providers for distributed applications Explain that Windows 2000 also provides a variety

of techniques to secure an Internet-enabled COM+ application

Introduce the concepts of authentication and authorization Explain how these concepts help to answer the two most basic security-related questions: how to prove that a user is who she claims and how to determine which users are allowed to perform particular operations

! Declarative Security Discuss how to use roles in COM+ applications to implement an authorization policy that controls access to applications, components, interfaces, and methods Show students how to define roles declaratively by using the Component Services tool Let them see how COM+ manages much of the authorization process automatically

The demonstration allows you to show students how to use the Component Services tool to define roles and assign them to components and interfaces

It is also used to show how to add Windows 2000 group and user accounts

to roles

! Programmatic Security Explain that students can implement security programmatically in COM+ solutions By using programmatic security, they can apply additional business logic to the authorization process in circumstances that demand it

! Setting the Identity of a Server Application Explain that COM+ applications use a default application identity that matches the security settings of the currently logged-on user The identity determines the user account under which the application will run The identity affects the privileges and access rights that the application will possess and is also important when the application needs to access a database that cares about the identity of its users Discuss the advantages of establishing a specific user account for running a COM+ application, rather than relying on the interactive user account

Discuss that it is possible to assign a different application identity to a COM+ application to meet specific security requirements Explain how to set the identity of a COM+ application and refer to Lab 8.3 as an example of how changing the identity will affect an application Explain that the identity of a COM+ application plays a pivotal role in the various security models

The demonstration allows you to show students how to set the identity of a COM+ application

There is a known problem when assigning an identity to an application that contains a component making a call to a queued component

in another application This scenario results in an error being logged in the Windows Event log with a source of the MSMQ Cryptography API and the queued method will not be called The issue is currently unresolved

! Best Practices Summarize the best practices for securing COM+ applications and mention that the practical implementation for most of these practices has been covered in the module

Note

THIS PAGE INTENTIONALLY LEFT BLANK

! Lab 8.2: Implementing Programmatic Security

! Setting the Identity of a Server Application

! Lab 8.3: Assigning a COM+ Application Identity

! Best Practices

! Review

In this module, you will learn how to implement security in an enterprise solution You will learn about the security features provided by Microsoft Windows 2000 You will also learn about the fundamental security concepts of authentication and authorization and how authorization policies are established for COM+ applications These policies govern which users should be permitted access to the various parts of the application and are defined by using roles First, you will review the security features provided by Windows 2000 and will learn about the authentication options available for intranet- and Internet-based solutions These policies govern which users should be permitted access to the various parts of the application You will then learn how to implement role-based security and how you can assign roles declaratively and

programmatically You will also learn about the various security models that you can apply to multitier systems Finally, you will learn about best practices that you should follow when managing security in enterprise solutions

Objectives

After completing this module, you will be able to:

! Describe the major security features and security models provided by the Windows 2000 platform

! Explain how authentication and authorization works

! Describe the authentication options available to Internet solutions based on COM+ and Internet Information Services (IIS)

! Implement declarative security by using COM+ roles

! Implement programmatic security by using security context information

! Assign an identity to a COM+ application

In this module, you will learn

how to implement security in

COM+ both declaratively

and programmatically

# Overview of Windows 2000 Security

! Distributed Security Model

! Public Key Cryptography

! Centralized Access Control

! Security Providers

! Authentication and Authorization

! Securing an Internet-Based Solution

In this section, you will learn about the security features provided by Windows

2000 While Windows 2000 is fully compatible with previous versions of Windows NT®, Windows 98, and Windows 95, the security model has been enhanced considerably, notably by the introduction of the Kerberos

authentication protocol and the increased emphasis on Internet-based security technologies

You will learn about the distributed security model that is designed to support enterprise applications You will then learn some of the key terminology and concepts of Windows 2000 security, including the concept of public key cryptography You will learn how you can manage security groups centrally in Active Directory™ to provide control over access to resources You will also learn how Windows 2000 supports multiple security providers to support distributed applications

Finally, you will learn about the concepts of authentication and authorization You will learn how these concepts help to answer the two most basic security-related questions: how to prove that a user is who she claims and how to determine which users are allowed to perform particular operations

This section includes the following topics:

! Distributed Security Model

! Public Key Cryptography

! Centralized Access Control

! Security Providers

! Authentication and Authorization

! Securing an Internet-Based Solution

Distributed Security Model

! Windows 2000 Distributed Security Features

Single Sign-On Secure Channels

Smart Cards Kerberos Authentication

Public Key Infrastructure Active Directory Integration

Security is a vital element in any distributed application Specifically, applications must use authentication to validate users and prove that they are whom they claim Applications must also implement authorization to ensure that users can only perform tasks for which they have been given permission Typically, different groups of users have different privileges when using an application For example, in a company procurement system, employees can use the application to order goods and only system administrators can amend product catalogs

As enterprise systems open to the Internet, businesses need to interact with partners, suppliers, and customers by using Internet-based technologies The issue of authenticating Internet users (proving that they are whom they claim) and securing sensitive data as it crosses public networks presents challenges in addition to providing security in a domain environment Windows 2000 addresses many of the issues relating to Internet security by using a public key infrastructure (PKI) based on public key cryptography For information about public key cryptography, see Public Key Cryptography in this module

Windows 2000 Distributed Security Features

Windows 2000 has many new features to simplify domain administration, improve performance, and integrate Internet security technology These features include:

! Integration with Active Directory Active Directory provides the store for all domain security policy and account information Using Active Directory provides significant improvement over the registry-based implementation in previous versions of Windows NT, both in performance and scalability Active Directory

supports a hierarchical namespace for user, group, and computer account information

Delivery Tip

Mention that there is

glossary of security terms in

the student notes so

students can review as

needed to prepare for this

module

Active Directory allows accounts to be grouped by organizational units rather than a flat domain account namespace This feature allows you to organize the namespace for account information to represent the departments and organizational structures found within your company Active Directory also allows account updates at any domain controller, not just the Primary Domain Controller (PDC) Multiple master replicas of Active Directory at other domain controllers are updated and synchronized automatically

Windows 2000 domains can be organized into a hierarchical domain tree The implicit domain relationships between domains allow users with accounts in one domain to be authenticated by resource servers in another domain Management of domain trusts is simplified under Windows 2000 because Active Directory supports two-way transitive trusts between domains that are part of the same Windows 2000 domain tree For example,

if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain

A also implicitly trusts Domain C This transitive trust contrasts with the one-way explicit trust model available under previous versions of Windows

NT

! Kerberos authentication protocol The Kerberos authentication protocol is used as the primary security protocol for access to resources within or across Windows 2000 domains Kerberos is a mature industry standard and includes features such as mutual authentication and support for authorization delegation from clients to servers

! Secure channel protocols providing data integrity and privacy across public networks

Using secure channel security protocols including Secure Sockets Layer (SSL 3.0) supports client authentication by mapping user credentials in the form of public key certificates to existing Windows 2000 accounts Internet browsers and servers use these protocols for mutual authentication, message integrity, and confidentiality

! Public key infrastructure Windows 2000 introduces a comprehensive public key infrastructure to the Windows platform This feature allows developers to take advantage of shared-secret or public-key security mechanisms in their applications Public key cryptography can be used in a number of areas, primarily authentication, message integrity, and confidentiality

Windows 2000 provides Microsoft Certificate Server for organizations to issue X.509 version 3 certificates to employees or business partners In Internet scenarios with clients outside of the Windows 2000 domain environment, or in disconnected situations involving Microsoft Message Queue (MSMQ), certificates can be used to convey client credentials for authentication purposes Windows 2000 provides the Crypto API to handle certificate management

! Smart cards for interactive log on Windows 2000 supports the optional use of smart cards for interactive log

on, in addition to passwords Smart cards support cryptography and secure storage for private keys and certificates

! Single Sign On The primary goal of Single Sign On (SSO) is to ensure that users only have

to enter their user name and password (or use a Smart Card) once in a session After users are logged on to their local computer, they should be able to access whatever resources to which they are entitled on whatever computer or network those resources reside, without any further requests for authentication information Authentication is taking place, of course, but it

is invisible to the user and requires no further manual intervention on their part SSO is provided natively by Windows 2000 through both Kerberos and the Secure Sockets Layer (SSL) protocol

SSO also supports logging on to mainframe systems Systems Network Architecture (SNA) Server allows a user logged on to Windows 2000 to access resources hosted on mainframes (running MVS, OS/400, and other operating systems) Authentication can take place by using mainframe-hosted security packages such as RACF, ACF2, and Top Secret

Windows 2000 Terminology and Concepts

Computer security encompasses a diverse body of knowledge covering many different concepts The following table defines some of the key security terms and concepts discussed in this module

Term Definition

a given user or group Contained with Discretionary Access Control Lists (DACLs) and System Access Control Lists (SACLs) and attached to a Security Descriptor

group membership, and the user’s privileges Attached

to processes running under Windows 2000, identifying the account under which the process is running

claims

access to which resources

authority (CA) and comprising the owner’s name and their public key The CA vouches that the person named in the certificate owns that key

highest level, a recognized national or international organization

Credentials usually include the domain name, user name, and password In the Kerberos authentication protocol, tickets represent the client’s credentials

server as if it were that client

Term Definition

sender’s identity and to ensure the message is not modified in transit

Discretionary Access Control List (DACL)

List of Access Control Entries (ACEs) that control access permissions to a secured resource Attached to security descriptors

System Access Control List (SACL)

List of Access Control Entries (ACEs) specifying which operations on a secured object should generate audit messages

security context of a client process

mechanism used in Windows 2000

Generally, a user or service that requires authentication

data Data encrypted with the public key can only be decrypted by using the private key and vice versa

during a communication session

DACL identifying who is and who is not permitted access to the secured resource

user and group accounts

will still be able to access resources distributed across multiple computers (perhaps running different operating systems) and potentially multiple networks

Used by Kerberos to vouch for a user's identity

Public Key Cryptography

! Encryption and Decryption

! Digital Signatures

$ Used for authentication and to guarantee message integrity

$ Only someone with the private key could have created the digitalsignature

$ Anyone with access to the corresponding public key can validate the signature

$ Any modification of the signed data invalidates the signature

or transmitted shortly thereafter The receiving computer performs the same hashing function on the message and compares its result with the received hash value If they differ, the message has been changed in transit

Encryption and Decryption

Hashing does not prevent messages from being read Encryption can be used for this purpose by using one or more keys to perform encryption and decryption Encryption and decryption are mathematical transforms applied to the data The two forms generally used today are shared secret and public key encryption

! Shared secret encryption This form relies on using the same key for both encryption and decryption and is also known as symmetric encryption Shared secret encryption suffers from a number of limitations While the data can now be transferred

securely, there remains the problem of keeping keys secure Shared secret encryption typically relies on only two computers knowing the key If a third computer uses the same key, neither of the other computers will realize that the messages are coming from a third party as long as they believe the key is secret This problem makes such keys vulnerable and raises the issue

of identifying where messages and keys originate

! Public key encryptionPublic Key cryptography relies on mathematically generated key pairs and

an encryption algorithm that allows data encrypted with one of the keys to

be decrypted only by using the other key Its owner is the only identity to have the private key, while the public key is made publicly available (hence the names of the two keys) This public/private key pair serves two

! Only someone with the private key could have created the digital signature

! Anyone with access to the corresponding public key can validate the signature

! Any modification of the signed data invalidates the signature

Certificates

Certificates form the basis of secure authenticated communication and access control on the Internet They exist primarily as a simple way of delivering a public key with a guarantee that it came from the person whose name (and possibly other personal details) is also included within the certificate The public key can then be used knowing that the only person who can decrypt the associated messages is the person whose name and other details are in the certificate

The digest (or hash) of each certificate is encrypted by the private key of the issuer, and as a result, it can only be decrypted by using the issuer's public key This key confirms that the issuer of the certificate is the source of the

certificate Windows 2000 certificates are compliant with the international X.509 standards

With certificates, client can be assured of a server’s identity The server proves its identity by presenting a certificate A user who connects to a Web site that has a certificate signed by a trusted authority can be confident that the server is actually operated by the company identified in the certificate Similarly, certificates enable server applications to be confident of a client’s identity When a user connects to a Web site, the server can be assured of the client’s identity if the server receives the client’s certificate

Certificate Authorities

The purpose of CAs is to issue certificates used to convey an individual’s or an organization’s public key CAs guarantee that the public key contained within a certificate actually belongs to the person or organization whose name is on the certificate

Consider the problem that CAs aim to resolve If you were presented with a certificate supposedly containing your bank’s public key, how would you know that the public key actually belongs to your bank and not an imposter? To answer this question, you would need to carefully consider who told you that this key was your bank’s public key More specifically, do you trust the person (or agency) who told you? If you do trust this person or agency (the CA), then you can accept that the public key legitimately belong to your bank If you trust the CA, you implicitly trust the keys bound into the certificates they issue Without CAs, someone could create certificates that include public keys claiming to be from someone other than their actual identity Certificates are themselves digitally signed by the CA to prove they originate from the certifying authority

Ultimately, the success of CAs is entirely dependent on whether the party receiving the certificate trusts the authority who issued it and that the authority properly verified the certificate owner’s identity Beyond this trust, certificates

do not provide conclusive proof about the identity or trustworthiness of the user When applying for certificates, individuals must typically provide proof of identity including names, addresses, birth dates, passport numbers, and national insurance numbers

Centralized Access Control

Within the enterprise, security groups are used to control access to resources These groups are listed in access control lists (ACLs), which define permissions

on resources and objects Across the Internet, a user’s access may be based on their identity being proven by a private key signature operation and the corresponding public key certificate Windows 2000 provides features that allow a certificate presented by a remote user to be mapped to a Windows 2000 account The access rights granted to the particular account then determine what resources the user is allowed to access

Security Identifiers

The security identifier (SID) identifies the user or security group object when a user or group is used for security purposes The SID is stored as a property of user objects and security group objects in Active Directory Active Directory automatically generates the SID when the user or group is created The system ensures that SIDs are unique across a forest If a user or group is moved to another domain outside of the forest, the SID will change However, the globally unique identifier (GUID) associated with the Active Directory object will remain the same

Access Control Entries

An access control entry (ACE) grants or denies specific access rights to a resource for individual users and groups If a security group is given access permission for a resource, the security group SID will be added to the ACE that defines the granted permission

Discretionary Access Control List

Resources maintain a discretionary access control list (DACL) that consists of a list of ACEs that specify which users and groups are allowed to do what to that resource For example, when a security group is granted access permission to a resource, the ACE that holds the group's SID will be part of the DACL

belonging to that resource

DACLs may have many ACEs granting and denying permission to various individuals and groups The list may also be empty, meaning that no one has any access rights to that resource The list may be missing completely so that everyone has full permissions on that resource

In Active Directory, each object has a security descriptor property that stores a DACL defining the access to that particular object or properties on that object Other securable objects such as folders and files also have associated security descriptors containing access control lists

Access Tokens

When a user logs on to a Windows 2000 domain, an access token is automatically generated This token is used when determining which resources the user may access An access token includes:

! The user’s SID

! All of the SIDs of the security groups to which the user belongs

Every process executed on behalf of a user has a copy of the user's access token This copy includes any servers that impersonate the user or that delegate calls to other servers on the user's behalf

When a user attempts to access any resource, the service that performs the access impersonates the user It creates a new access token based on the token belonging to the user, but the new token also contains SIDs for all domain groups to which the user belongs and SIDs that apply to the domain in which the requested resource resides This new token is then used by the service to attempt to access the resource

When performing an access check, the system walks the list of ACEs in the DACL associated with the secured object to determine whether access should

be granted or denied When a user is being granted access, this process also determines the exact access rights granted to the user These rights may or may not be the same as the requested access rights The above illustration shows how the access tokens are used to check security access

Groups in Active Directory

Security (and distribution) groups have scope There are three different kinds of groups, each with a different scope

Group type Description

access control in any domain

used for access control on any domain

for access control on a single domain

If there are multiple forests, users from one forest cannot be placed in groups belonging to another forest, and groups from one forest cannot be given permission in another

For more information about security groups, see Networking Services/Active Directory/Active Directory Programmers Guide/Managing Groups in the Windows 2000 Platform SDK

Security Providers

SSPI

Authenticated RPC DCOM COM+

LDAP

Directory enabled APPs using ADSI

HTTP

Internet Explorer, Internet Information Server

SSPs

The security requirements for applications running in an enterprise environment vary greatly, some with Internet integration and some without To support these varied requirements, Windows 2000 supports multiple security providers and authentication protocols

The Security Support Provider Interface

The Security Support Provider Interface (SSPI) API serves to insulate applications from the underlying protocol details This API is a standard designed to support the security needs of applications running in a distributed environment

The SSPI is conceptually similar to Open Database Connectivity (ODBC) ODBC insulates applications from a specific database server by offering drivers that implement the standard ODBC API for client-side developers, while communicating with the database by using a proprietary interface In a similar way, security providers can implement the SSPI API in a DLL called a Security Support Provider (SSP) Applications written to work with one SSP require few, if any, modifications to work with another SSP

The primary SSPs available to COM+ applications are:

! NTLMSSP (NT LAN Manager SSP)

! Kerberos

! Snego (Simple Negotiation)

NT LAN Manager Security Support Provider

Prior to Windows 2000, the Microsoft Windows NT LAN Manager Security Support Provider (NTLMSSP) was the only SSP available This security package is based on the NTLM challenge-response protocol for authentication

In the challenge-response model, the server issues a challenge to the client by sending some data The client then uses an encoded version of the user’s password to encrypt the data provided by the server The encrypted response is then returned to the server, where it is decrypted and compared with the original data sent to the client If the data is the same, the user is authenticated

Simple Negotiation Mechanism

While NTLMSSP and Kerberos are real authentication protocols, Snego (Simple Negotiation Mechanism) is a pseudo-SSP used to negotiate between real SSPs COM+ uses Snego to decide which authentication service to use For Windows 2000 to Windows 2000 communication, Kerberos is the chosen SSP, while for Windows 2000 to Windows NT 4 communication, NTLMSSP is chosen as the lowest common denominator

SSPI and COM+

Although the SSP is a programmable interface, it is rarely called directly Instead, most applications will use other intermediate layers that wrap the SSPI and make it easier to use security providers For example, application interfaces provided by an authenticated remote procedure call (RPC) and the Distributed Component Object Model (DCOM) provide higher-level abstractions

COM+ serves to further insulate the enterprise developer from the security details COM+ handles the authentication process automatically, although you can determine authentication level requirements by using the administrative tool For more information about authentication, see Authentication and Authorization in this module The above illustration shows the relationship between COM+ security, DCOM, and authenticated RPC

Authentication and Authorization

Clearly, any form of access control policy is totally reliant on the security system being certain of the user’s identity The process of ascertaining that the user is actually who she claims and not an imposter is called authentication The process of determining which users are allowed to access which resources is called authorization An authorization policy represents this information

Authentication

COM+ handles the issue of authentication transparently by using the underlying COM services and the operating system’s SSP This approach allows the application developer to focus on the issue of authorization As described earlier, Windows 2000 offers a number of authentication packages in the form

of SSPs Windows 2000 prefers to use Kerberos, and depending on the capabilities of the client, this method will be chosen when possible Kerberos provides the client with some added protection because it supports mutual authentication This feature allows the client to authenticate the server and guard against spoof servers, in addition to allowing the server to authenticate the client As mentioned previously, it is imperative for the server to

authenticate the client to support any form of authorization policy

To use the operating system’s authentication service, both client and server specify their desired authentication levels These authentication levels provide varying degrees of security, ranging from none to the encryption of every packet of data sent between client and server The following table lists the various authentication levels

Authentication level Meaning

the server

client

modified during the transfer between client and server

authentication level prevents anyone from spying on the data when it is being transferred between client and server

The degree of security increases as you move through the levels toward packet privacy However, increased security comes at the cost of performance If encryption is being used frequently, you should consider using a network card that supports encryption because hardware encryption is considerably faster

Setting the Authentication Level

Both client and server must specify their desired authentication levels You can configure the authentication level of a COM+ server application by using the Component Services tool

! To configure the authentication level of a COM+ server application

! From the application's Properties dialog box, click the Security tab to

display the authorization and authentication options as shown in the following illustration

The client sets its own authentication level by calling the COM API

CoInitializeSecurity when it first starts For clients written in Microsoft

Visual Basic®, this function is automatically called when the client application is started

If the client and server specify different authentication levels, the higher of the two levels is chosen

For COM+ library applications that run in the address space of the client process, the authentication level is inherited from the client process The library application has no way of choosing its authentication level The

Authentication level for calls combo box on the Security page of the application’s Properties dialog box is replaced by an Enable authentication

check box for library applications This check box simply allows you to specify whether the client process should perform client authentication on calls into the library application

Note

Authentication and Authorization (continued)

! Message-Based Authentication

$ Messages are digitally signed

$ Used to verify who sent message and to guarantee message integrity

! Authorization

$ Determining which users are allowed to access which resources

$ Relies on authentication, which is essentially transparent

$ COM+ authorization uses roles

Message-Based Authentication

The COM+ Queued Components service provides asynchronous communications by using the underlying services of MSMQ Message authentication in this environment provides two services First, it provides a way to ensure message integrity, and second, it provides a way to verify who sent the message Authentication is requested by the sending application, which sets the authentication level of the message and attaches a security certificate When the message is sent, MSMQ digitally signs the message At the receiving end, MSMQ verifies the digital signature when it receives the message After message integrity is verified, MSMQ verifies who sent the message

Authorization

When the authentication process has been completed, the process of authorization begins Authorization depends on some form of authentication being used If authentication is switched off, COM+ will not be able to ascertain the client’s identity, rendering any form of authorization policy useless The COM+ authorization policy is based on the concept of a role, which is an application-wide group of users Roles allow you to determine which groups of users are allowed to access a COM+ application and interact with its components Furthermore, roles can be used to restrict access to individual interfaces and methods For more information about role-based security, see Overview of Role-Based Security in this module

Securing an Internet-Based Solution

! Anonymous Authentication

! Basic Authentication

User Password and password

Lookup Registered Users Proprietary lookup

IIS Anonymous Authentication with proprietary lookup

of supplied user details

You can use a variety of authentication techniques in an Internet-enabled COM+ application by using IIS When developing an Internet-based COM+ solution in conjunction with IIS, Web-based clients communicate with IIS and IIS acts as the client for the COM+ application The choice of authentication option used by IIS affects the client identity presented to the COM+

application

IIS authentication can be managed in a number of ways, but this authentication ultimately relies on linking each end user with a valid Windows 2000 user account IIS offers a number of authentication options

Anonymous Authentication

When using anonymous authentication, IIS does not care about the identity of the end user and accesses all Web pages and resources (including COM+ applications) by using a default anonymous user account By default, this account is named after the server machine and is of the form

IUSR_<Machine Name>; for example, IUSR_COMPUTER0 This account

is initially set up as a member of the Windows 2000 Guests group, but group membership can be changed if required The Guests group has security restrictions and limited permissions, making the account suitable for public users

When used in conjunction with a COM+ solution, the COM+ application typically has no way of distinguishing individual end users To the COM+ application, the client would always appear as IUSR_<Machine Name>

You can use IIS anonymous authentication with a Web-based solution that explicitly prompts the user for a user name (and password) This prompt is typically made on the Web site’s home page This information, when transmitted to the server over a secure link, can then be used for searching a database table of registered users Assuming the user is successfully authenticated (that is, the user’s details are located), the user can be mapped to a Windows 2000 user account for subsequent resource access Alternatively, the anonymous IUSR_<Machine Name> account can be used for resource access with the client’s user name explicitly propagated to downstream components for the purposes of performing additional business logic or auditing With either approach, a many-to-one relationship will exist between Internet users and Windows 2000 user accounts

The following illustrations show IIS acting as the intermediate client to a COM+ application It highlights the client identity that IIS presents to the COM+ application for anonymous authentication scenarios

Basic Authentication

With basic authentication, if IIS attempts to access a resource on behalf of the end user to which access is denied, then IIS will return a request denied HTTP response to the user’s browser The user’s Web browser will then display a dialog box allowing a user name and password to be entered This information

is then transmitted to the server without being encrypted If the server rejects the information, the browser repeatedly displays the dialog box until a valid user name and password is supplied or until the user closes the dialog box When IIS verifies that the user name and password match a valid Windows

2000 user account, IIS will perform subsequent resource access by using this account

When IIS is acting as a client to a COM+ application, the COM+ application will identify the client as a regular Windows 2000 user account

The following illustration shows IIS acting as the intermediate client to a COM+ application It highlights the client identity that IIS presents to the COM+ application for basic authentication

Due to the lack of encryption used when the user name and password are transmitted to the server, you should use Integrated Windows authentication when possible The reason is that this authentication uses the secure

challenge/response protocol Microsoft Internet Explorer versions 2.0 and later support challenge/response However, the advantage of basic authentication is that it is part of the HTTP specification and is supported by most browsers

Note

Securing an Internet-Based Solution (continued)

unauthorized person from using the details if they are intercepted in transit Digest authentication is supported only for domains with a Windows 2000 domain controller and is part of the HTTP 1.1 specification As a result, it requires HTTP 1.1 support from the browser

The following illustration shows IIS acting as the intermediate client to a COM+ application It highlights the client identity that IIS presents to the COM+ application for digest authentication

Integrated Windows Authentication

Integrated Windows authentication uses the conventional NTLM challenge/response protocol to perform authentication This protocol is secure because the user name and password are never transmitted over the network Unlike basic authentication, it does not initially prompt the end user for a user name and password The client’s current Windows logon credentials are used instead However, if authentication fails when this information is used (for example, because the client and server machines are in separate domains), then the browser will prompt the user for a valid user name and password

Integrated Windows authentication is secure, but the client must be running Internet Explorer (version 2.0 or later) As a result, this option is the best for intranet solutions such as the Purchase Order system used in the lab scenario The COM+ application will recognize individual clients as separate Windows

2000 user accounts and allow more sophisticated authorization logic and audit tracking

The following illustration shows IIS acting as the intermediate client to a COM+ application It highlights the client identity that IIS presents to the COM+ application for integrated authentication

Certificate Authentication

IIS can use SSL security features to allow users to authenticate Web sites and to allow the server to authenticate end users The former uses server certificates and the latter uses client certificates For end-user authentication, the client certificate can subsequently be mapped to a valid Windows user account Users logging on with client certificates can be automatically authenticated without requiring any of the aforementioned methods

In a COM+ scenario, when IIS accesses the COM+ application, it will use the particular user account’s credentials in the same way that it does for Integrated Windows authentication, digest authentication, and basic authentication

The following illustration shows IIS acting as the intermediate client to a COM+ application It highlights the client identity that IIS presents to the COM+ application for certificate authentication

# Declarative Security

! Overview of Role-Based Security

! Implementing Role-Based Security

! Demonstration: Creating and Assigning a Role

In this section, you will learn how to use roles in COM+ applications to implement an authorization policy that controls access to applications, components, interfaces, and methods You will learn how to define roles declaratively by using the Component Services tool You will see how COM+ manages much of the authorization process automatically

This section includes the following topics:

! Overview of Role-Based Security

! Implementing Role-Based Security

! Demonstration: Creating and Assigning a Role

Overview of Role-Based Security

! Roles represent an application-wide collection of users

$ Roles map well to real-world concepts such as

“Managers” and “Clerks”

Client Principal

Roles

Authorization Policy

Method Call COM+

Security Event

The COM+ application security model revolves around the concept of a role A role provides a higher level of abstraction than merely Windows 2000 user accounts and group accounts A role represents an application-wide collection

of users sharing the same security privileges By using roles, you can administratively construct an authorization policy for your application, choosing down to the method level (if necessary), which users can access which resources

Roles have an added advantage in that they enable you to apply authorization without having to worry about the details of individual user or group accounts Access to particular areas of your application is determined purely on role membership Exactly who belongs to a given role is not relevant An administrator can decide this issue at deployment time Being able to administratively assign roles is particularly beneficial because often the user and group accounts within your development domain do not match the accounts that will ultimately be used in the production domain

Roles allow you to simply secure the various parts of your application by associating particular roles with specific areas of functionality When a client calls into a COM+ application, after the authentication process is complete and COM+ is sure of the caller’s identity, the catalog is accessed to determine the role membership of the particular client COM+ then checks whether

membership of the particular role or roles permits authorized access to the current application, component, interface, and method If the client’s role membership permits access, the method is called If the client does not belong

to the appropriate role, the call is rejected, the client is denied access and a security event is generated to reflect the illegal access attempt You do not have

to write any security-related code within your components

Role-based security authorization requires authentication to occur between server and client COM+ manages this authentication automatically on your application’s behalf, provided that you have not switched authentication off

Note

Overview of Role-Based Security (continued)

You should consider this factor when determining in which applications to place your components If you specifically require one component to check security when called from another component, you must locate the components

in separate applications The above illustration shows how COM+ checks authorization levels

Implementing Role-Based Security

! Roles can be applied at a number of levels

! Implementing Declarative Security

Implementing Declarative Security

There are three main steps to implementing declarative security for a COM+ application

! To implement declarative security for a COM+ application

1 Create the roles for the application

You define roles at development time with knowledge of the category of user that will use the application At this stage, you typically do not have information about individual user accounts

2 Map Windows user and group accounts to roles

This step occurs when you deploy the application The users that are assigned to a particular group at deployment time can be different for each installation of the application

3 Enable security

You must enable security for the application as a whole You must then decide which individual components, interfaces, and methods require role-based protection

Creating and Assigning Roles

After you have created a COM+ application and added components, you can create roles for the application You define roles at the application level and then map them to components, interfaces, or methods within the application

You can choose not to map roles to components, interfaces, and methods This approach establishes an application-level authorization policy, which determines who can access any functionality within the application Typically, however, you will assign roles to individual components, interfaces, and methods enabling a more fine-grained authorization policy

! To create a role

1 Start the Component Services tool and select the application for which you are defining a role

2 Expand the application node and select the Roles folder

3 On the Action menu, point to New, and then click Role

4 Type the name of the new role and then click OK

The following illustration shows a sample Roles dialog box

Note

! To assign roles to a component

1 Using the Component Services tool, right-click the component for which

role-based authorization is to be performed and select Properties

2 On the Properties dialog box, click the Security tab to display the Security

page The Security page presents a list of all roles defined for the application, as shown in the following illustration

3 Place a check mark by each role for which you want to grant access to the component

4 Click OK to dismiss the dialog box

To enable component, interface, and method-level checking, you must

select Enforce component level access checks and Perform access checks at the process and component level on the application’s Property dialog box For

more information about enabling security, see "Enabling Security" later in this topic

Note

! To assign roles to an interface

1 Using the Component Services Administration tool, right-click the interface

for which role-based authorization is to be performed and select Properties

2 In the Properties dialog box, select the Security tab to display a dialog box

that shows the roles that the interface has inherited from higher-level role assignment, together with all the available roles defined for the application

3 Place a check mark by each additional role that you want to give access to

the interface Any role displayed in the Roles inherited by selected item(s)

list will automatically be granted access to the interface, regardless of the

role’s setting in the Roles explicitly set for selected item(s) list

4 Click OK to dismiss the dialog box

! To assign roles to a method

1 Using the Component Services tool, right-click the method for which

role-based authorization is to be performed and select Properties

2 In the Properties dialog box, select the Security tab to display a dialog box

that shows the roles that the method has inherited from higher-level role assignment, together with all the available roles defined for the application

3 Place a check mark by each additional role that you want to give access to

the method Any role displayed in the Roles inherited by selected item(s)

list will automatically be granted access to the method, regardless of the

role’s setting in the Roles explicitly set for selected item(s) list

4 Click OK to dismiss the dialog box

Mapping Users to Roles

When you deploy and install an application, you must map Windows 2000 user and group accounts to the defined roles The roles will then determine which users have access to the various areas of the application’s functionality

Using Windows 2000 Groups

The most flexible approach to administering security for COM+ is to create a Windows 2000 group account for each role in a COM+ application After the group is created, you assign each group to its respective role For example, if a COM+ application has a role called Senior Manager, you can create a Windows

2000 group called Senior Managers You can then assign the Senior Managers group to the Senior Manager role

It is good practice to use plural group names and singular role names In this example, the group contains all Senior Managers, while the role they fulfill

is that of a Senior Manager

After you have assigned Windows 2000 groups to all of the roles in your COM+ application, you can use the Active Directory Users and Computers Administration tool to add or remove users in each group For example, adding

a Windows 2000 user account named James to the Windows 2000 group Senior Managers effectively maps James to the Senior Manager role

With Windows 2000 groups, you can efficiently use one administrative tool to administer both Windows 2000 and COM+ security

! To assign Windows 2000 groups to COM+ roles

1 Using the Component Services tool, expand the application containing the roles to which you want to add Windows 2000 groups

2 Expand the Roles folder and the specific role to which you want to assign Windows 2000 groups

3 Under the specific role, right-click the Users folder, point to New, and click User to display the Select Users or Groups dialog box

4 In the Select Users or Groups dialog box, add groups (or users) to the role Note