-----------------------------------------------------------

New Message on BDOTNET

-----------------------------------------------------------
From: LovedJohnySmith
Message 1 in Discussion




ASP.NET Authorization

        Securing
Web sites is a critical, complex issue for Web developers. A secure system
requires careful planning, and Web site administrators and programmers
must have a clear understanding of the options for securing their site.

        ASP.NET
works in concert with the Microsoft .NET Framework and Microsoft Internet
Information Services (IIS) to provide Web application security. To secure
an ASP.NET application, you must perform the two fundamental functions
described in the following table.









Authentication
           
  Assures that the user is, in fact, who the user claims to be. The
application obtains credentials (various forms of identification, such
as name and password) from a user and validates those credentials against
some authority. If the credentials are valid, the entity that submitted
the credentials is considered an authenticated identity.

Authorization
           
  Limits access rights by granting or denying specific permissions
to an authenticated identity.



        IIS can
also grant or deny access based on a user's host name or IP address. Any
further access authorization is performed by NTFS file access permission's
URL authorization.

        It is
helpful to understand how all the various security subsystems interact.
Since ASP.NET is built on the Microsoft .NET Framework, the ASP.NET application
developer also has access to all the built-in security features of the
.NET Framework, such as code access security and role-based user-access
security.



Authentication



        Authentication
is the process of obtaining identification credentials such as name and
password from a user and validating those credentials against some authority.
If the credentials are valid, the entity that submitted the credentials
is considered an authenticated identity. Once an identity has been authenticated,
the authorization process determines whether that identity has access to
a given resource.

        To enable
an authentication provider for an ASP.NET application, you only need to
create an entry for the application configuration file as follows.

// Web.config file     

<authentication mode= "[Windows|Forms|Passport|None]"/>

        The mode
is set to one of the authentication modes: Windows, Forms,
Passport, or None. The default is Windows. If the mode is
None, ASP.NET does not apply any additional authentication to the
request - this can be useful when you want to implement a custom authentication
scheme, or if you are solely using anonymous authentication and want the
highest possible level of performance.

        The authentication
mode cannot be set at a level below the application root directory. As
is the case with other ASP.NET modules, subdirectories in the URL space
inherit authentication modules unless explicitly overridden.



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 access control list (ACL)
check of the .aspx or .asmx handler file to determine if 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 URL 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 URL 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]/>

An 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.

Anonymous users are also denied.

The following example grants access to Kim
and members of the Admins role, while denying it to John and all anonymous
users:

<authorization>

    <allow users="Kim"/>

    <allow roles="Admins"/>

    <deny users="John"/>

    <deny users="?"/>

</authorization>

Both users and roles can refer to multiple
entities by using a comma-separated list, as shown in the following example.

<allow users="John, Kim, contoso\Jane"/>

Notice that the domain account (contoso\Jane)
must include both the domain and user name combination.

<authorization>

    <allow users="John"/>

    <deny users="*"/>

</authorization>

The following example lets everyone do a GET,
but only Kim can use POST.

<authorization>

    <allow verb="GET" users="*"/>

    <allow verb="POST" users="Kim"/>

    <deny verb="POST" users="*"/> 

</authorization>

Rules are applied using the following heuristics:


        Rules contained in configuration files at
lower directory levels take precedence over rules at higher directory 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 the 401 status code. 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.





Johnson Smith

Tata Consultancy Services Limited

Mailto: [EMAIL PROTECTED]

Website: http://www.tcs.com

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you received 
this message by mistake, please click the "Remove" link below. On the pre-addressed 
e-mail message that opens, simply click "Send". Your e-mail address will be deleted 
from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to