Authentication and Authorization by MindTree Campus

Note: 1. Spoofing: Attempting to gain access to a system by using a false identity 2. Tampering: Unauthorized modification of data 3. Repudiation: It is the ability of an user (legitimate or otherwise) to deny that they performed specific transactions 4. Information Disclosure: Unwanted exposure of private data 5. Denial of Service: Process of making a system or any application unavailable 6. Elevation of Privilege: It occurs when an user, with a limited privileges, assumes the identity of a privileged user, to gain privileged access to any application.

Note: 1. Authentication: Is the process of validating the identity of the user before granting access to a restricted resources. User credentials like username/password pair is used to verify the identity of a user. 2. Authorization: Is the process of verifying if the authenticated user has permission for accessing the requested resources or not. 3. Impersonation: Is the process of assuming the identity of the user while requesting for a resources. Server performs an action on behalf of the user. 4. Secure Communication: Ensuring that the messages remain private and unaltered as they cross networks 5. Encryption: The process of coding plain text to create cipher text is encryption and the process of decoding cipher text to produce plain text is called decryption 6. Principle of Least Privilege: It means that an user should be not be given any extra permission than necessary to accomplish a particular job.

Notes: 1. Access to the application is restricted based on the user’s credentials. These credentials are compared to various sources depending on the type of the security mechanism in place. 2. Security in ASP.NET is achieved in a two stages as described below: 1. Authentication: Authentication is the process of verifying the user’s credentials to determine whether the user has access to the application or not. This is achieved by fetching the user’s credentials and validating those credentials against some pre-determined authority. The user is given access to the application if the credentials are valid. Authentication fails if the credentials given by the user does not match those that already exists for verification. 2. Authorization: The next step is to restrict the access rights to the users by either granting or denying permissions. This is again dependent on the user’s credentials and is usually done once the authentication is successful.

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

Settings through configuration file: 1. Adding Custom Configuration Information in Configuration file:

<appSettings> <add key="CONNECT" value="Data Source=SQLSVR2005\SQLEXPRESS;Database=newdb;user id=TeamA;password=ATeam"/> </appSettings> 2. Retrieving Custom Configuration Information.

string str = ConfigurationManager.AppSettings["CONNECT"]; SqlConnection con = new SqlConnection(str); SqlDataAdapter da = new SqlDataAdapter("select * from emp",con); DataSet ds = new DataSet(); da.Fill(ds,"emp"); GridView1.DataSource = ds.Tables[0]; GridView1.DataBind();

Notes Provide the following additional information to the points listed on the slide: Deployment considerations: Is the application Internet or Intranet based Is the application located behind a firewall The application type: Is the web site interactive or non-interactive? Application authorization requirements For instance, you may want your application accessible to all users, or you may need to restrict certain sections to registered users, and other areas only to administrators

Notes: 1. Usage Scenario: A news site that provides local information based on a user's location (Zip Code). User need not explicitly log on. 2. Anonymous authentication gives users access to the public areas of your Web site without prompting them for a user name or password. 3. Although listed as an authentication scheme, it is not technically performing any client authentication because the client is not required to supply any credentials. 4. Instead, IIS provides stored credentials to Windows using a special user account, IUSR_machinename. 5. By default, IIS controls the password for this account. 6. Whether or not IIS controls the password affects the permissions the anonymous user has. 1. When IIS controls the password, a subauthentication DLL (iissuba.dll) authenticates the user using a network logon. The function of this DLL is to validate the password supplied by IIS and to inform Windows that the password is valid, thereby authenticating the client. However, it does not actually provide a password to Windows. 2. When IIS does not control the password, IIS calls the LogonUser() API in Windows and provides the account name, password and domain name to log on the user using a local logon. After the logon, IIS caches the security token and impersonates the account. A local logon makes it possible for the anonymous user to access network resources, whereas a network logon does not.

Notes 1. Most Internet browsers support Basic authentication. 2. IIS implements Basic authentication, which is part of the HTTP 1.0 specification, using Windows user accounts.

3. When using Basic authentication, the browser prompts the user for a user name and password. 4. This information is then transmitted across HTTP where it is encoded using Base64 encoding. 5. Although most Web servers, proxy servers, and Web browsers support Basic authentication, it is inherently insecure. 6. Because it is easy to decode Base64 encoded data, Basic authentication is essentially sending the password as plain text.

Note: 1.

As passwords can be deciphered relatively easily, use Basic authentication for 1.

Non-secure applications

Semi-secure applications

To improve the security of this authentication scheme, you can use it in combination with Secure Sockets Layer/Transport Layer Security (SSL/TLS) support to encrypt the HTTP session. However, SSL/TLS impacts performance because it encrypts and decrypts all data on each exchange. TLS is the Internet Engineering Task Force (IETF) version of Netscape's SSL, sometimes referred to as SSL 3.1

By combining Basic authentication with SSL, you can better secure your application: 1.

This prevents passwords from being deciphered

Many Internet applications use this combination

Note: 1. Digest authentication is a challenge/response mechanism, which sends a digest (also known as a hash) instead of a password over the network. 2. A digest is a fixed-size result obtained by applying a mathematical function (called a hash function or digest algorithm) to an arbitrary amount of data. 3. The fixed-size depends upon the level of encryption. For example, if a 128-bit digest consisted of 32 ASCII characters, a 40-bit digest would consist of 10 ASCII characters. 4. When a client attempts to access a resource requiring Digest authentication, IIS send a challenge to the client to create a digest and send it to the server. 5. The client concatenates the password with data known to both the server and the client. 6. The client then applies a digest algorithm (specified by the server) to the combined data. 7. The client sends the resulting digest to the server as the response to the challenge. 8. The server uses the same process as the client to create a digest using a copy of the client's password it obtains from Active Directory, where the password is stored using reversible encryption. 9. If the digest created by the server matches the digest created by the client, IIS authenticates the client. IIS uses a subauthentication DLL (iissuba.dll) to authenticate the user, resulting in a network logon. 10. By itself, Digest authentication is only a slight improvement over Basic authentication. 11. In the absence of SSL/TLS, an attacker could record communication between the client and server. 12. Using this information, the attacker can then use that information to replay the transaction

Notes: 1. NTLM:NTLM uses a challenge-response mechanism for authentication, in which clients are able to prove their identities without sending a password to the server. It consists of three messages, commonly referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3 (authentication). 2. Security level of NTLM and Kerberos: Both of these protocols are considered highly secure. With NTLM and Kerberos, the password is not transmitted over the network. NTLM uses a challenge/response mechanism. Kerberos is considered even more secure because it supports mutual authentication (that is, clients can verify the server with which they are communicating). Integrated Windows Authentication: 1. Integrated Windows authentication (formerly known as NTLM authentication and Windows NT Challenge/Response authentication) can use either NTLM or Kerberos V5 authentication and only works with Internet Explorer 2.0 and later. 2. When Internet Explorer attempts to access a protected resource, IIS sends two WWWAuthenticate headers, Negotiate and NTLM. 3. If Internet Explorer recognizes the Negotiate header, it will choose it because it is listed first. When using Negotiate, the browser will return information for both NTLM and Kerberos. 4. At the server, IIS will use Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 and later, and both are members of the same domain or trusted domains. Otherwise, the server will default to using NTLM. 5. If Internet Explorer does not understand Negotiate, it will use NTLM.

Note: 1.

2. 3. 4.

Instead of dealing with authentication and authorization issues in the ASP.NET application code, you can rely on Microsoft Internet Information Services (IIS) to authenticate the user and either pass an authenticated token to the ASP.NET application or, if unable to authenticate the user, pass an unauthenticated token. In either case, the ASP.NET application impersonates whichever token is received if impersonation is enabled. The ASP.NET application, now impersonating the client, then relies on the settings in the NTFS directories and files to allow it to gain access, or not. Be sure to format the server file space as NTFS, so that access permissions can be set.

If impersonation is enabled for a given application, ASP.NET always impersonates the access token that IIS provides to ISAPI extensions. That token can be either an authenticated user token, or the token for the anonymous user (such as IUSR_MACHINENAME). The impersonation occurs regardless of the type of authentication being used in the application. 6. Only application code is impersonated; compilation and configuration are read as the process token. The result of the compilation is put in the "Temporary ASP.NET files" directory. 7. The account that is being impersonated needs to have read/write access to this directory. 8. If an application is on a universal naming convention (UNC) share, ASP.NET will always impersonate the token provided to IIS to access that share unless a configured account is used. 9. If an explicit configured account is provided, ASP.NET will use that account in preference to the IIS UNC token. 10. Applications that do want per-request impersonation can simply be configured to impersonate the user making the request.

Notes: Login pages are generally used to pass user credentials to a web server which then authenticates it.

The user may not even be required to log in to the site by giving the username and the password explicitly as the current windows credentials can be passed to the IIS automatically when the user tries to access the site (This is dependent on which user account has been used to log in to the system and also the settings in the configuration file).

Notes: 1.

“mode” attribute = To mention the mode of authentication. Possible values are “Forms”, “Passport”, “Windows” and “None”. By default the mode is “Windows”. You have to change it to “Fomrs”, if you want to provide “Forms Authentication”.

<fomrs> element = To provide settings for Forms Authentication.

“loginUrl” attribute = You have to have a log in page if you want to provide Forms Authentication facility in your web site. “loginUrl” attribute is used to pass name of the web page that you have added in the web site for Forms Authentication.

“cookieLess” attribute = whether facility to store authentication ticket in cookies should be enabled. Sometimes some web sites contains a check box displaying “Remember Me?” or “Remember user name and password?” on the log in page. If user checks the check box then a persistent cookie is created in the user’s system hard disk else a temporary cookie is created and exits in the browser memory space. If you want user name and password should be saved in a cookie, then use “cookieLess” attribute and set it’s value to “UseCookies”.

“name” attribute = Name of the cookie to be stored at the client side. By default the name is “.aspxauth”.

“path” attribute = Path of the cookie. “/” indicates root directory.

“protection” attribute = Mention name of protection mechanism for the cookie file.

“defaultUrl” attribute = Generally, if any user requests any page, first the user will be supplied a log in page and after successful authentication, user will be redirected to the originally requested page. But, if the user requests the log in page directely, then user should be redirected to a default page, otherwise the user will be staying at the log in page even after successful authentication. “defaultUrl” attribute is used to pass the name of the default page the user should be directed to, after successful authentication.

“timeOut” attribute = Session time out duration. By default it is 20 minutes (as configured by IIS).

Note: 1. It is quite possible to store credentials in the web.config file, using <credentials> child element of <forms> element belonging to <authentication> parent element.

2. It is very useful when the web site has very few users to authenticate 3. At that point of time, instead of using a database table to store credentials you can use the above mentioned alternate technique 4. “passwordFormat” attribute = Password stored as a part of the credenetial can be encrypted and that is why, “passwordFormat” attribute of <credentials> element can be used to mention the format of the password. Possible values are – “SHA1”, “MD5” and “Clear”. “Clear” format indicates that password will not be encrypted, rather will be stored in plain text format in the web.config file.”SHA1” (Secured Hash Algorithm 1)and “MD5” (Message Digest 5) are two encryption format.

5. <user> elenemt = Stores the user id and password. 6. “name” attribute = To mention user name of the user. 7. “password” = To mention the password of the user.

Notes: 1. The idea of the example is, in this web site there are few pages such as “Home.aspx”, Default.aspx” etc. If user requests any page of this web site, then the user will be supplied a log in page. After successful authentication the user will be redirected to the originally requested page. If the user directly requests the log in page, rather than any other web page, then user will be redirected to “Home.aspx” after successful authentication. 2. So, in this example, the web site contains an extra log in page, containing two text boxes, one for user name and another for password 3. The page also contain a button (log in), by clicking which user can submit the user name and password to the server 4. Also, the page contains a check box. If the user checks the check box before clicking on Submit/Login button, then a persistent cookie will be created containing authentication ticket for the user and next time onwards if user requests any page, he/she will be able to view the page without further authenticating himself/herself.

Note: 1. The user names and passwords are stored in the web.config file using <credentials> element of the <forms> child element of the <authentication> parent element.

2. This is done, keeping in mind that the number of user is very less in this case. Such as, an web site deployed in intranet of any small scale software company, which is accessed only by Human Resource (HR) people of the organization. 3. <authorization> element = used to mention authoriation setting for Forms Authentication. 4. <deny> indicates which of the users should be allowed any which of them should not be allowed. 5. Similarly, instead of using <deny> you can use <allow> element, which servers the same purpose. 6. “<deny users =“?” />” indicates anyone else apart from the authenticated user will be denied access to any web page of this web site

7. Similarly “<deny users = “*” />“indicates every user will be denied access to any web page of this web site. 8. “<allow users =“?” />” indicates only authenticated users will be allowed access to any web page of this web site, no one else. 9. Similarly “<allow users = “*” />“indicates every user will be allowed access to any web page of this web site. This is kind of setting “Anonymous Access” for the web site.

Note: 1.

The user is being authenticated against the credentials stored in web.config file by passing the user name and password entered by the user in the “Authenticate” method of the “FormsAuthentication” class, present in “System.We.Security” namespace (which is by default is added in the web site code behind file).

“Authenticate” method two parameters, both of “string” data type. One is “username” and another is “password”, that have to verified against the user name and password stored in the web.config file. This method returns boolean value. It returns “True” indicating that the authentication is successful and “false” indicating that the authentication unsuccessful.

The “RedirectFromLoginPage” method is used to redirect the user to the originally requested page or any default page (in case, user has directly requested log in page) after successful authentication.

The “RedirectFromLoginPage” page accepts two parameters, one is of “string” type and another is of “bool” type.

“string” data type argument accepts the user name and “bool” data type argument accepts either value “True” or value “False”.

Actually, if the user checks the check box “chkPersistent” (as mentioned in the page design of the earlier slide) with text “Remember Me?”, then a persistent cookie will be created on behalf of the user. To create the persistent cookie or not, you need the pass the return value of “Checked” property of “chkPersistent” check box as the second argument and the user name entered by the user in the “tstUserId” text box as the first argument to the “RedirectFromLoginPage” method.

If the user checks the check the check box then the persistent will be created with the name mentioned in the “name” attribute and in the specified path, mentioned in the “path” attribute of the <forms> element in the associated “web.config” file.

Whether the cookie will be having any protection or not that will decided by the value supplied in the “protection” attribute of the <forms> element in the web.config file.

Also, any persistent cookie will be created or not that at all will be decided by the value passed to “cookieLess” attribute of the <forms> element of web.config file.

Note: 1. If you decide to store credentials of all the users in a database table, then you can’t use “Authenticate” method of “FormsAuthentication” class

2. You have to write code to connect with the database table 3. Then retrieve all the credentials 4. Check the user name and password entered by the user ( in the text boxes) against the ones retrieved from the database table. 5. Depending on whether the user name and password entered by the user matches to that of the database table or not, use a boolean variable to store either “True” of “ False” accordingly 6. If the boolean variable (such as, “authenticated” in this example) returns true, then redirect the user to the originally requested page or any default page (in case user requests the log in page directly) or if the boolean variable returns “False”, then do not redirect the user and display some error message on the page.

Notes: How Passport authentication works? When the participant site receives a request from a user for log on, their browser or the user agent sends the credentials to the passport service. This passport service then authenticates the user based on the credentials that it receives. Once the user has been authenticated a secure cookie is placed on their machine. The browser then presents this cookie to the passport service whenever a user tries to access any of the participating site. The passport services then gives the details about the userâ&#x20AC;&#x2122;s identity to the new site and the new site can use this information to authorize the user.

Reference