1. Authorization in ASP.NET:
Authorization is a process in which you decide whether an authenticated user is
allowed to access certain page or resource. E.g. operators may not be allowed to
view certain confidential financial information that managers can view.
ASP.NET Authorization
The purpose of authorization is to determine whether an identity should be
granted the requested type of access to a given resource. There are two
fundamental ways to authorize access to a given resource:
File authorization
File authorization is performed by the FileAuthorizationModule, and is
active when you use Windows authentication. It does an ACL check to
determine whether a user should have access. Applications can further
use impersonation to get resource checks on resources that they are
accessing..
URL authorization
URL authorization is performed by the URLAuthorizationModule, which
maps users and roles to pieces of the URI namespace. This module
implements both positive and negative authorization assertions. That is,
the module can be used to selectively allow or deny access to arbitrary
parts of the URI namespace for certain sets, users, or roles.
The URLAuthorizationModule is available for use at any time. You only need
to place a list of users and/or roles in the <allow> or <deny> elements of the
<authorization> section of a configuration file.
To establish the conditions for access to a particular directory, you must place
a configuration file that contains an <authorization> section in that directory.
The conditions set for that directory also apply to its subdirectories, unless
configuration files in a subdirectory override them. The general syntax for this
section is as follows:
<[element] [users] [roles] [verbs] />
The element is required. Either the users or the roles attribute must be
included. Both can be included, but both are not required. The verbs attribute is
optional.
The permissible elements are <allow> and <deny>, which grant and revoke
access, respectively. Each element supports three attributes, which are defined in
the following table.
Attribute Description
Mr. Pritesh N. Patel Page 1

2. Roles Identifies a targeted role for this element. The associated
IPrincipal object for the request determines the role membership.
You can attach arbitrary IPrincipal objects to the context for a
given request and they can determine role membership in
whatever fashion you like. For example, the default
WindowsPrincipal class uses Windows NT groups to determine
role membership.
Users Identifies the targeted identities for this element.
Verbs Defines the HTTP verbs to which the action applies, such as
GET, HEAD, or POST.
Anonymous users are also denied.
The following example grants access to Mary, while denying it to John:
<authorization>
<allow users="Mary"/>
<deny users="John" />
<deny users="?" />
</authorization>
Both users and roles can refer to multiple entities by using a comma-
separated list such as the following:
<allow users="John, Mary, redmondbar" />
Notice that the domain account [redmondbar] must include both the domain
and user name combination.
In addition to identity names, there are two special identities, as shown in the
following table.
Identity Description
* Refers to all identities
? Refers to the anonymous identity
To allow John and deny everyone else, one might construct the following
configuration section:
<authorization>
<allow users="John" />
<deny users="*" />
</authorization>
Mr. Pritesh N. Patel Page 2

3. The following example lets everyone do a GET, but only Mary can use POST:
<authorization>
<allow verb="GET" users="*" />
<allow verb="POST" users="Mary" />
<deny verb="POST" users="*" />
</authorization>
Rules are applied using the following heuristics:
Rules at lower levels take precedence over rules at higher levels. The
system determines which rule takes precedence by constructing a
merged list of all rules for a URL, with the most recent (nearest in the
hierarchy) rules at the head of the list.
Given a set of merged rules for a URL, the system starts at the head of
the list and checks rules until the first match is found. Note that the
default configuration for ASP.NET contains an <allow users="*">
element, which authorizes all users. If no rules match, the request is
allowed unless otherwise denied. If a match is found and the match is a
<deny> element, it returns 401. Applications or sites can easily
configure a <deny users="*"> element at the top level of their site or
application to prevent this behavior.
If an <allow> matches, the module does nothing and lets the request be
processed further.
There is also a <location> tag that you can use to specify a particular file or
directory to which settings wrapped by that tag (between <location> and
</location> tags) should apply.
Windows Authentication in ASP.NET (Authentication Systems)
Introduction
Security is an important consideration in your web applications. Securing a web
application consists of two steps:
 Authenticating the user accessing the page
 Authorizing the user to access the page
Authentication is a process of determining whether a user is the one who he
claims to be. Typically this will be determined with the help of user id and
password.
ASP.NET offers various ways to authenticate and authorize users of your web site.
They are:
 Windows authentication
 Forms authentication (cookie authentication)
Mr. Pritesh N. Patel Page 3

4.  Passport authentication
[1] Windows Authentication
Windows authentication scheme uses traditional mechanisms of Basic,
NTLM/Kerberose and Digest authentication. Here IIS uses the credentials of
logged in user are used to authenticate web requests. In case integrated windows
authentication is turned off a typical gray colored dialog pops up asking for user id
and password.
Steps involved in implementing windows authentication and authorization
 Create a ASP.NET web application
 Modify web.config to set authentication mode to windows
 Modify web.config to deny access to anonymous users
 Authorize users based on their NT user groups (roles)
[2] Forms authentication in ASP.NET
Introduction
Many times we use some kind of custom authentication mechanism for our web
sites. The most common way to authenticate visitors of your site is by accepting
user id and password from then which are then validated against a database table.
ASP.NET provides a very easy way to implement such mechanism via forms
authentication. Forms based authentication is also referred to as cookie
authentication because a cookie is used with each request that tells whether a
user is authenticated or not. In case of windows authentication we automatically
get windows role of the logged in user. You can also implement custom role based
security in the Form based authentication.
Steps involved in implementing forms authentication
 Configure your web application to deny anonymous access
 Modify web.config file to specify authentication mode as Forms
 Create a aspx page that accepts user id and password and sets
authentication cookie
 Modify web.config to specify a page that will be acting as login page
 Implement role based security (optional)
[3] .NET Passport Authentication
Passport is a core component of the Microsoft.NET building block services. It
enables businesses to develop and offer distributed Web services across a wide
range of applications and Passport members to use one sign-in name and
password at all participating Web sites
Mr. Pritesh N. Patel Page 4

5. Initial Request
When a client requests a resource on a server that requires Passport
authentication, the server checks the request for the presence of tickets. If a
valid ticket is sent with the request, the server responds with the requested
resource. If the ticket does not exist on the client, the server responds with a
302 status code. The response includes the challenge header, "WWW-
Authenticate: Passport1.4". Clients that are not Passport-enabled can follow the
redirection to the Passport login server. More advanced clients typically contact
the Passport nexus to determine the location of the Passport login server.
The following image illustrates the initial request to a Passport affiliate.
Passport Login Server
A Passport login server handles all requests for tickets for any resource in a
Passport Domain Authority. Before a request can be authenticated using
Passport, the client application must contact the login server to obtain the
appropriate tickets.
When a client requests tickets from a Passport login server, the login server
typically responds with a 401 status code to indicate that user credentials must
be provided. Upon the provision of these credentials, the login server responds
with the tickets required to access the server containing the originally requested
resource. The login server can also redirect the client to another server that can
provide the requested resource.
Mr. Pritesh N. Patel Page 5

6. Authenticated Request
When the client has the tickets corresponding to a given server, those tickets
are included with all requests to that server. If the tickets have not been
modified since they were retrieved from the Passport login server, and the
tickets are valid for the resource server, the resource server sends a response
that includes both the requested resource and cookies indicating that the user
is authenticated for future requests.
The additional cookies in the response are intended to speed the authentication
process. Additional requests—in the same session—for resources on servers in
the same Passport Domain Authority, all include these additional cookies.
Credentials do not need to be sent to the login server again until the cookies
expire.
IIS 6 can use Microsoft's .NET Passport to authenticate users requesting
resources from a web site or a web site virtual directory.
The benefit that this solution offers is that the credentials are stored and
managed on another server that you are not responsible for building or
maintaining. Users can authenticate using the .NET Passport service and then
be allowed access to the web site hosted on your server. The service does not
provide access control or site authorization, however. The .NET Passport server
Mr. Pritesh N. Patel Page 6

7. can only affirm that a web consumer representing himself or herself to be the
person represented by the established profile in the .NET Passport server has
successfully authenticated as that person represented by the established
profile.
The .NET Passport system is free for the web consumer to register with and
use. Web consumers log in and log out at the Passport server, and they are
directed to your web site after a successful login event. The login and logout
pages may be cobranded so that they appear to be related to the web site that
the user is logging in to.
Passport provides a nice system for everyone involved in a web-based
transaction, because users get the benefit of a single sign-on solution for any
.NET Passport authenticated web site they encounter.
The web host benefits because the hosting party does not have to build and
support the credentials system or server, but they must pay a fee to the
Microsoft .NET Passport service to establish an account with the Passport
server.
After an account is set up, the web host simply needs to build the web site to
respond to users who authenticate. This is the same effort that any web site
with an established membership and authentication mechanism would
perform regardless of where the members' credentials are hosted, except that
they now deal with only authenticated user.
The problem with the .NET Passport system, however, is that many web
consumers have not responded quickly to the solution. The web consumer
community is apprehensive about providing personal information to the .NET
Passport service.
Existing web-based vendors and portals have not adopted the use of .NET
Passport with great enthusiasm because they generally already have their own
authentication systems in place.
The benefits of providing a web single login experience are greatly minimized
when the web consumer may have to authenticate to other sites that they
patronize. Without wide acceptance of the use of .NET Passport by web sites
using it as an authentication system, the web single login system will not
benefit the web consumer.
Establishing .NET Passport Service
Before you can use the .NET Passport service, you need to prepare your site for
the service. Following is a review of the steps required for establishing a .NET
Passport server setup:
1. Register the web site through the .NET Passport service. Go to the
following URL to begin the process:
http://www.microsoft.com/net/services/passport/ developer.asp.
Here, you'll fill out a comprehensive series of forms and complete a
.NET Passport Wizard with information about yourself and your web
site. Table 7-1 summarizes the information required to perform this
step.
Mr. Pritesh N. Patel Page 7

8. 2. On successful registration, your site is assigned an ID and registered
with a pending status. Microsoft will attempt to replicate the site on its
server and approve your site.
3. Build the site. Microsoft provides a .NET Passport software
development kit (SDK) that offers aid and support in your effort to
build a .NET Passport web site. The SDK is available free for download
from Microsoft's web site at
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/w
ebsrvpass.asp.
4. Petition .NET Passport services for a compliance review of the site. If
your site meets the standards, you will be required to enter into a
contractual agreement with .NET Passport services.
5. Launch the site. Obtain the encryption keys for the production site
and roll in the production code required to support the .NET Passport
integration.
Table 7-1: .NET Passport Registration Information
Item Description
Your general contact information Name, phone, address, e-
mail, and so on
Name of the site Required-Name used to
identify the site in the
Passport portal
Type of .NET Passport service Required-Choose one or
more of the following: Kids
Passport, .NET Passport
Single Sign-In, .NET
Passport Express
Purchase
Web Site Title Required-Title for the web
site
Domain Name Required-The top most
domain name for the site;
no subdomains should be
included in the name
Default Return URL Required-The URL where
customers will be
redirected from the
Passport server in an
error event
Customer Support Phone Number Telephone number
presented to customers if
they need help or support
Customer Support E-mail E-mail address presented
to customers
if they need help or
support
Mr. Pritesh N. Patel Page 8

9. Table 7-1: .NET Passport Registration Information
Item Description
Customer Support URL URL presented to
customers if they need
help or support
Privacy Policy URL Required-URL presented
to customers for your
privacy policy
Cobrand URL URL for the cobranding
file that contains the
JavaScript cobranding
variables
Cobrand CSS URL URL for the cascading
style sheet (.css) file that
will be used by the .NET
Passport pages to make
them appear cobranded
Cobrand Image URL Required-URL for the
site's logo, which should
be 468 × 60 pixels
Cobrand Image2 URL Required-URL for the
site's logo, which must be
2 × 80 pixels, and a .gif
Cobrand Image HREF Link for the logo image
Cobrand Instruction Text Required-Instructions
that will appear at the top
of the .NET Passport
Credential dialog box
Registration Return URL URL of the file that users
will be redirected to after
login by default
Terms of Use URL URL for the terms of use
Edit URL URL to the page on the
web devoted to editing
user's data on your site
Disable Copyright Checkbox that will disable
the Microsoft copyright
link presented in each
.NET Passport module
Disable Help Text Checkbox that will disable
the Microsoft help file link
presented in each .NET
Passport module
Mr. Pritesh N. Patel Page 9

10. Table 7-1: .NET Passport Registration Information
Item Description
Disable Member Services Checkbox that will disable
the Microsoft Member
Services file link
presented in each .NET
Passport module
Disable Privacy Policy Checkbox that will disable
the Microsoft privacy
policy file link presented
in each .NET Passport
module
Disable Terms of Use Checkbox that will disable
the Microsoft Terms of
Use file link presented in
each .NET Passport
module
Expire Cookie URL Required-URL for a file
that deletes the .NET
Passport cookies; this
URL is called when the
user performs a logout
function
Logout URL URL for a file that the
passport system will send
customers when they sign
out of .NET Passport by
clicking the .NET Passport
Sign Out button
The registration process identified in step 1 is rather comprehensive. You will
also be presented with the .NET Passport Wizard, and you will be expected to
establish a .NET Passport. After the wizard completes, you will see a series of
Mr. Pritesh N. Patel Page 10

11. web pages prompting you for information-some of which is mandatory to
complete the process.
Setting Up the Site for .NET Passport
If you set up a web site or a web virtual directory to authenticate users via
.NET Passport, the users will be presented with a .NET Passport login prompt
when they request a file for the first time from the web site. The circumstances
under which the user will be prompted for their credentials may vary,
depending on the site application's use of the .NET Passport service. After the
user enters a valid login and password, they are allowed to access the
requested file.
To set up IIS to provide .NET Passport authentication, follow these steps:
1. Open the IIS MMC snap-in and expand the Web Sites node in the left
panel.
2. Right-click the respective web site or virtual directory that should
authenticate using .NET Passport. Select Properties.
3. In the Properties window, select the Directory Security tab.
4. Click the Edit button under the Authentication And Access Control
section. The Authentication Methods window will open.
5. Under the Authenticated Access section, check the .NET Passport
Authentication checkbox. All other authentication methods will be
disabled, since using .NET Passport authentication is a mutually
exclusive option. Anonymous access can still be selected, however.
6. If you want, type a domain name in the Default Domain text box. This
is the domain to which usernames will be assumed to belong on the
host server after the .NET Passport server authenticates them. Realm
may be used to identify the organization or domain to which users
should be assumed to belong if the server participates in a non-
Microsoft system.
7. Click the OK button to close the Authentication Methods window, and
click the OK button to close the Properties window.
If the .NET Passport service is set properly, users will be presented with a .NET
Passport prompt that looks like the window shown in Figure 7-2, except the
configurations described in Table 7-1 will exist in place of the default values
shown in Figure 7-2.
Mr. Pritesh N. Patel Page 11

12. Figure 7-2: .NET Passport login prompt with the default configurations
Mr. Pritesh N. Patel Page 12