Authentication is the process of verifying user's identity.
Authorization is the process of granting privilege to authenticated user.
The user is validated using authenticated process and then the authorization process identifies if the user has access to a given resource.
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.
In ASP.NET, we can authenticate user in code or allow the user to be authenticated by other party such as MS Passport.
There are two layer of authentication in ASP.NET
IIS layer :- IIS performs authentication if it is configured to do so. By default, IIS allows anonymous access which means all the users are authenticated. All the requests pass through IIS layer and then to ASP.NET authentication process.If any user requests IIS layer for anonymous access, the user is treated as authenticated and pass to ASP.NET process.
ASP.net authentication process layer :-ASP.NET checks if impersonation is enabled in the web configuaration file i.e. web.config file. If impersonation is enabled, ASP.net acts as though it were the authenticated user otherwise it process with its own configured account.
To enable the application to authenticate users, we need to add element in the authorization section of Web.config.
Authentication modes : -
Windows Authentication :-Windows Authentication is the default authentication mechanism for ASP.NET applications .The windows authentication authenticates users based on their windows accounts. In short, it uses windows network security. It uses IIS to perform authentication.Windows authentication is best suited for the application which is meant for a corporate users.
Passport authentication :-The Passport authentication uses Microsoft's passport service to authenticate users. The new user is directed to the Microsoft site where he can register his identity. This facilitates user to access multiple sites using single user name and password. You need to install the Passport SDK to enable the Passport classes in the System.Web.Security namespace.
Form authentication :- The Form authentication collects user's credential and lets the application use own logic to authenticate users. The collected user's credential is validated using the list maintained by the application. The application maintains its own user list either using
element in the web.config file or using database. The advantage of using form authentication is that the users don't need to be the member of windows network to have access to the application.Form authentication is preferable for the applications which have diversified users from several places.
we can set authentication mode from web.config file.
<authentication mode="windows">
<authentication mode="passport">
<authentication mode="forms">
Authorization:-
Authorization determines whether an identity should be granted access to a specific resource. In ASP.NET, there are two ways to authorize access to a given resource:
File authorization :- File authorization is performed by the 'FileAuthorizationModule'. It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user's Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET process. For more information, see ASP.NET Impersonation.
URL authorization :-URL authorization is performed by the 'UrlAuthorizationModule', which maps users and roles to URLs in ASP.NET applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles.
With URL authorization, we explicitly allow or deny access to a particular directory by user name or role. To do so, we create an authorization section in the configuration file for that directory. To enable URL authorization, we specify a list of users or roles in the allow or deny elements of the authorization section of a configuration file. The permissions established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them.- The syntax is as below
<authorization>
< [ allow deny ] [ users ] [ roles ] [ verbs ] />
</authorization>
- For e.g below authorization section shows how to allow access to the abc identity and deny access to all other users
<authorization>
<allow users="abc">
<deny users="*">
</authorization>
- Here ' * ' refers to all identities and ' ? ' refers to anonymous identity
The allow or deny element is required. we must specify either the users or the roles attribute. Both can be included, but both are not required. The verbs attribute is optional.
- Attributes:-
1. users :-It will check the user accounts for this element.
2. roles :-It will check that the current request that is allowed or denied access to the resource.
3.verbs :-Defines the HTTP verbs to which the action applies, such as GET, HEAD, and POST.
- The following example grants access to Mary and members of the Admins role, while denying access to John ( unless John is a member of the Admins role ) and to all anonymous users.
<authorization>
<allow users = "Mary">
<allow roles = "Admins">
<deny users = "John">
<deny users = "?">
</authorization>
-Both users and roles can refer to multiple entities by using a comma-separated list such as in the following:
<allow users = "John, Mary, redmond\bar">
- Notice that the domain account [ redmond\bar ] must include both the domain and user name.
-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 defined in application-level configuration files take precedence over inherited rules. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent rules ( those nearest in the hierarchy ) at the head of the list.
- Given a set of merged rules for an application, ASP.NET starts at the head of the list and checks rules until the first match is found.
- If a match is found and the match is an <allow> element, the module grants access to the request.
- If a match is found and the match is a <deny> element, the request is returned with a 401 HTTP status code.
- If no rules match, the request is allowed unless otherwise denied.
Notice in the last situation, the request is allowed access even if no rules were matched. This happens so because the default configuration for ASP.NET defines an <allow users = "*"> element, which authorizes all users. By default, this rule is applied last.
To prevent this behavior, define a <deny users = "*"> element at the application level.
Like all other configuration settings, the access permissions established for a directory also apply to all of its subdirectories, unless explicitly overriden in a child configuration file.
Configuring authorization using the <location> element
The following code example demonstrates how to allow an anonymous user to gain access to the
<configuration>
<location path = "Logon.aspx">
<system.web>
<authorization>
<allow users = "?">
</authorization>
</system.web>
</location>
</configuration>
Posts
