Securing web services msc it ps03 cint05Document Transcript
Mr. Pritesh N. Patel Page 1
Securing Web services
 Built in Authentication: (Through Membership)
ASP.NET membership gives you a built-in way to validate and store user
credentials. ASP.NET membership therefore helps you manage user
authentication in your Web sites. One can use ASP.NET membership with
ASP.NET forms authentication by using with the ASP.NET login controls to
create a complete system for authenticating users.
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and
supporting data) in Microsoft SQL Server, Active Directory, or an
alternative data store.
Authenticating users who visit your site. You can authenticate users
programmatically, or you can use the ASP.NET login controls to create
a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting
them. Depending on membership options you choose, the membership
system can also provide an automated password-reset system that
takes a user-supplied question and response.
Exposing a unique identification for authenticated users that you can
use in your own applications and that also integrates with the ASP.NET
personalization and role-management (authorization) systems.
Although membership is a self-standing feature in ASP.NET for
authentication, it can be integrated with ASP.NET role management to
provide authorization services for your site. Membership can also be
integrated with user profile properties to provide application-specific
customization that can be tailored to individual users.
How Membership Works
To use membership, you must first configure it for your site. The following
are the basic steps you follow in order to configure membership:
1. Specify membership options as part of your Web site configuration. By
default, membership is enabled. You can also specify what
membership provider you want to use. The default provider stores
membership information in a Microsoft SQL Server database.
However, you can use other providers as well, such as a provider for
Windows Live ID. You can also choose to use Active Directory to store
membership information, or you can specify a custom provider. For
information about membership configuration options that can be
specified in the Web.config file for your ASP.NET application.
Configure your application to use forms authentication.
Mr. Pritesh N. Patel Page 2
2. You can also specify that some pages or folders in your application are
protected and are accessible only to authenticated users.
3. Define user accounts for membership. You can do this in a variety of
ways. You can use the Web Site Administration Tool, which provides a
wizard-like interface for creating new users. Alternatively, you can use
an ASP.NET Web page where you collect a user name and password
(and optionally an email address), and then use the CreateUser
membership method to create a new user in the membership system.
You can then use membership to authenticate users in your application.
Typically, you will provide a page where users can log in, a registration page
where new users can sign up, and a change-password page where users can
change their password.
The ASP.NET login controls (Login, LoginView, LoginStatus, LoginName, and
PasswordRecovery) encapsulate virtually all of the logic required to prompt
users for credentials and validate the credentials in the membership system.
If you have configured the application to use forms authentication, ASP.NET
will automatically display the login page if an unauthenticated user requests
a protected page.
If you use the project templates that are provided in ASP.NET or use the
login controls, they will automatically use the membership system to
validate a user. If you create custom login controls, you must call the
ValidateUser method to validate the user’s user name and password.
After the user is validated, information about the user can be persisted (for
example, with an encrypted cookie if the user's browser accepts cookies).
The login controls perform this task automatically, but if you create custom
login controls, you can call methods of the FormsAuthentication class to
create the cookie and write it to the user's computer.
If a user has forgotten his or her password, the login page can call
membership functions that help the user recover the password or reset the
Each time the user requests a page, ASP.NET forms authentication checks
whether the user is authenticated.
If a page is restricted, users who are authenticated and are members of the
approved roles are allowed to view the page. Anonymous users (users who
Mr. Pritesh N. Patel Page 3
are not logged in) are directed to the login page. By default, the
authentication cookie remains valid for the user's session.
After a user has been authenticated, the membership system makes
available an object that contains information about the current user. For
example, you can get properties of the membership user object to determine
the user's name and email address, when the user last logged into your Web
site, and so on.
An important aspect of the membership system is that you never need to
explicitly perform any low-level database functions to get or set user
information. For example, you create a new user by calling the membership
The membership system handles the details of creating the necessary
database records to store the user information. When you call the
ValidateUser method to check a user's credentials, the membership system
does all the database lookup for you.
 Role Based Security:
Role Based Security lets you identify groups of users to allow or deny based
on their role in the organization. In Windows NT and Windows XP, roles map
to names used to identify user groups. Windows defines several built-in
groups, including Administrators, Users, and Guests. To allow or deny
access to certain groups of users, add the <ROLES>element to the
authorization list in your Web application's Web.config file.
< authorization >
< allow roles="Domain NameAdministrators" / > < !-- Allow Administrators in
domain. -- >
< deny users="*" / > < !-- Deny anyone else. -- >
< /authorization >
Role-based security in the .NET Framework supports three kinds of
1. Windows principals represent Windows users and their roles.
2. Generic principals represent users and roles that exist independent of
Windows NT and Windows 2000 users and roles.
Mr. Pritesh N. Patel Page 4
3. Custom principals can be defined by an application that is needed for
that particular application. They can extend the basic notion of the
principal's identity and roles.
Roles are often used in financial or business applications to enforce policy.
For example, an application might impose limits on the size of the
transaction being processed depending on whether the user making the
request is a member of a specified role. Clerks might have authorization to
process transactions that are less than a specified threshold, supervisors
might have a higher limit, and vice-presidents might have a still higher limit
(or no limit at all).
Role-based security can also be used when an application requires multiple
approvals to complete an action.
Such a case might be a purchasing system in which any employee can
generate a purchase request, but only a purchasing agent can convert that
request into a purchase order that can be sent to a supplier.
.NET Framework role-based security supports authorization by making
information about the principal, which is constructed from an associated
identity, available to the current thread. The identity (and the principal it
helps to define) can be either based on a Windows account or be a custom
identity unrelated to a Windows account.
.NET Framework applications can make authorization decisions based on
the principal's identity or role membership, or both. A role is a named set of
principal that have the same privileges with respect to security (such as a
teller or a manager). A principal can be a member of one or more roles.
Therefore, applications can use role membership to determine whether a
principal is authorized to perform a requested action.
To provide ease of use and consistency with code access security, .NET
Framework role-based security provides PrincipalPermission objects that
enable the common language runtime to perform authorization in a way that
is similar to code access security checks.
The PrincipalPermission class represents the identity or role that the
principal must match and is compatible with both declarative and
imperative security checks. You can also access a principal's identity
information directly and perform role and identity checks in your code when
The .NET Framework provides role-based security support that is flexible
and extensible enough to meet the needs of a wide spectrum of applications.
You can choose to interoperate with existing authentication infrastructures,
such as COM+ 1.0 Services, or to create a custom authentication system.
Role-based security is particularly well-suited for use in ASP.NET Web
Mr. Pritesh N. Patel Page 5
applications, which are processed primarily on the server. However, .NET
Framework role-based security can be used on either the client or the
 Code Based Security:
Today's highly connected computer systems are frequently exposed to code
originating from various, possibly unknown sources. Code can be attached
to e-mail, contained in documents, or downloaded over the Internet.
Unfortunately, many computer users have experienced firsthand the effects
of malicious mobile code, including viruses and worms, which can damage
or destroy data and cost time and money.
Most common security mechanisms give rights to users based on their logon
credentials (usually a password) and restrict resources (often directories and
files) that the user is allowed to access. However, this approach fails to
address several issues: users obtain code from many sources, some of which
might be unreliable; code can contain bugs or vulnerabilities that enable it
to be exploited by malicious code; and code sometimes does things that the
user does not know it will do.
As a result, computer systems can be damaged and private data can be
leaked when cautious and trustworthy users run malicious or error-filled
software. Most operating system security mechanisms require that every
piece of code must be completely trusted in order to run, except perhaps for
scripts on a Web page.
Therefore, there is still a need for a widely applicable security mechanism
that allows code originating from one computer system to execute with
protection on another system, even when there is no trust relationship
between the systems.
To help protect computer systems from malicious mobile code, to allow code
from unknown origins to run with protection, and to help prevent trusted
code from intentionally or accidentally compromising security, the .NET
Framework provides a security mechanism called code access security.
Code access security allows code to be trusted to varying degrees depending
on where the code originates and on other aspects of the code's identity.
Code access security also enforces the varying levels of trust on code, which
minimizes the amount of code that must be fully trusted in order to run.
Mr. Pritesh N. Patel Page 6
Using code access security can reduce the likelihood that your code can be
misused by malicious or error-filled code. It can reduce your liability
because you can specify the set of operations your code should be allowed to
perform as well as the operations your code should never be allowed to
perform. Code access security can also help minimize the damage that can
result from security vulnerabilities in your code.
All managed code that targets the common language runtime receives the
benefits of code access security, even if that code does not make a single
code access security call.
Code access security is a mechanism that helps limit the access code has to
protected resources and operations. In the .NET Framework, code access
security performs the following functions:
Defines permissions and permission sets that represent the right to
access various system resources.
Enables administrators to configure security policy by associating sets
of permissions with groups of code (code groups).
Enables code to request the permissions it requires in order to run, as
well as the permissions that would be useful to have, and specifies
which permissions the code must never have.
Grants permissions to each assembly that is loaded, based on the
permissions requested by the code and on the operations permitted by
Enables code to demand that its callers have specific permissions.
Enables code to demand that its callers possess a digital signature,
thus allowing only callers from a particular organization or site to call
the protected code.
To determine whether code is authorized to access a resource or perform an
operation, the runtime's security system walks the call stack, comparing the
granted permissions of each caller to the permission being demanded.
If any caller in the call stack does not have the demanded permission, a
security exception is thrown and access is refused.
The stack walk is designed to help prevent luring attacks, in which less-
trusted code calls highly trusted code and uses it to perform unauthorized
actions. Demanding permissions of all callers at run time affects
performance, but it is essential to help protect code from luring attacks by
Every developer must be familiar with the following code access security
concepts in order to write effective applications targeting the common
Mr. Pritesh N. Patel Page 7
Writing type-safe code: To enable code to benefit from code access
security, you must use a compiler that generates verifiably type-safe
Imperative and declarative syntax: Interaction with the runtime
security system is performed using imperative and declarative security
calls. Declarative calls are performed using attributes; imperative calls
are performed using new instances of classes within your code. Some
calls can be performed only imperatively, while others can be
performed only declaratively.
Requesting permissions for your code: Requests are applied to the
assembly scope, where your code informs the runtime about
permissions that it either needs to run or specifically does not want.
Security requests are evaluated by the runtime when your code is
loaded into memory. Requests cannot influence the runtime to give
your code more permissions than the runtime would have given your
code had the request not been made. However, requests are what your
code uses to inform the runtime about the permissions it requires in
order to run.
Using secure class libraries: Your class libraries use code access
security to specify the permissions they require in order to be
accessed. You should be aware of the permissions required to access
any library that your code uses and make appropriate requests in