; ASP
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

ASP

VIEWS: 19 PAGES: 25

  • pg 1
									ASP.Net Security

      Chapter 10
 Jeff Prosise’s Book
                Authentication
• To ascertain the caller’s identity
   – Windows authentication
   – Forms authentication
   – Passport authentication
• Windows authentication: Here, IIS does the
  authentication and makes the caller’s identity
  available to ASP.Net (via a token)
   – Most suitable when everyone that uses the
     application can login to the local machine
   – Uses the built-in security features of the OS
• Passport authentication:
  – Passport serves as a front-end to a large
    group of users registered with Microsoft
    Passport
  – Such users can be authenticated anywhere
    on the Internet by applications that present
    long credentials to Passport.
  – If Passport validates them, it returns an
    authentication ticket to the application; that in
    turn stores it as an encoded cookie
• Forms authentication
  – Relies on login forms in web pages to authenticate
    users
  – In an e-commerce application such as e-bay’s
    bidding, windows authentication is not viable since it
    is impractical to create windows accounts for all
    millions
  – In web.config, we set <authentication mode = “Forms”
    />
  – Other modes are: None, Windows, and Passport
                     Authorization
• Determines what resources a user can
  access
• ASP.Net supports:
  – ACL authorization or file authorization---e.g.,
    using NTFS file system’s ACL
  – URL authorization---relies on configuration
    directives in web.config using the
    <authorization> element
  – Authorization link
         Windows Authentication
• Maps incoming requests to accounts on the web server
• Used to serve a well defined user group that may be controlled
  through windows accounts
   – Basic authentication: transmits a user name and password in each
     request; IIS maps them to an account on the web server and generates
     a token.
       • Suppose a web page is placed in the virtual directory
       • Suppose IIS is configured to disallow anonymous access to that directory
         and to require basic authentication
       • When a user attempts to access it for the first time (via HTTP request, a
         401 is returned indicating that it requires basic authentication
       • The user’s browser then prompts the user for windows user name/password
       • Problem: User name/password sent in plain text between the browser and
         the web server with each request; user needs a windows account
   – Digest authentication: User name/password are sent as an encrypted
     token with each request
Windows Authentication (Cont.)

• Integrated windows authentication:
With Integrated Windows authentication (formerly called
  NTLM, and also known as Windows NT
  Challenge/Response authentication), the user name and
  password (credentials) are hashed before being sent
  across the network. When you enable Integrated
  Windows authentication, the client browser proves its
  knowledge of the password through a cryptographic
  exchange with your Web server, involving hashing.
                        IIS Security
• Internet Information Services---a web server
• IIS protects a server in four ways:
   – Web applications are deployed in virtual directories that are
     URL-addressable on the server. Remote clients cannot
     automatically access files outside this directory.
   – IIS assigns every request a token---a windows security principal;
     OS and .Net check this token prior to allowing access
   – It can enable/disable requests based on IP addresses and
     domains
   – Supports SSL and HTTPs
   – IIS supports four types of authentication:
       •   Basic authentication (user name/password)
       •   Digest authentication (user name/password)
       •   Integrated windows authentication
       •   SSL client authentication
         Forms Authenticatrion
• Authenticates a user by asking the user to type
  credentials (e.g., user name/password) into a web form.
• Entries in web.config can identify login page
• When a user accesses for the 1st time, ASP.Net redirects
  the user to the login page.
• If the login is successful, ASP.Net issues a ticket in the
  form of a cookie and redirects the user to the page
  originally requested.
• The cookie enables the user not to login everytime.
  Lifetime of a cookie is dictated by your application.
  Example Application with Forms
         Authentication
• Application contains two pages:
  – PublicPage.aspx --- viewed by anyone
  – ProtectedPage.aspx --- available only to
    authenticated users (validated by login page)
• LoginPage.aspx---asks for a user name
  and a password
• Web.config---stores valid user names and
  passwords
                    PublicPage.aspx
<html>
 <body>
  <h1>Public Page</h1>
  <hr>
  <form runat="server">
    <asp:Button Text="View Secret Message" OnClick="OnViewSecret"
     RunAt="server" />
  </form>
 </body>
</html>

<script language="C#" runat="server">
 void OnViewSecret (Object sender, EventArgs e)
 {
    Response.Redirect ("Secret/ProtectedPage.aspx");
 }
</script>
                                            LoginPage.aspx
<html>
 <body>
  <h1>Please Log In</h1>
  <hr>
  <form runat="server">
    <table cellpadding="8">
     <tr>
       <td>
        User Name:
       </td>
       <td>
        <asp:TextBox ID="UserName" RunAt="server" />
       </td>
     </tr>
     <tr>
       <td>
        Password:
       </td>
       <td>
        <asp:TextBox ID="Password" TextMode="password"
          RunAt="server" />
       </td>
     </tr>
     <tr>
       <td>
        <asp:Button Text="Log In" OnClick="OnLogIn"
          RunAt="server" />
       </td>
       <td>
       </td>
     </tr>
    </table>
  </form>
  <hr>
  <h3><asp:Label ID="Output" RunAt="server" /></h3>
 </body>
</html>

<script language="C#" runat="server">
 void OnLogIn (Object sender, EventArgs e)
 {
   if (FormsAuthentication.Authenticate (UserName.Text,
       Password.Text))
       FormsAuthentication.RedirectFromLoginPage (UserName.Text,
          false);
   else
       Output.Text = "Invalid login";
 }
Web.config in the main directory
<configuration>
 <system.web>
  <authentication mode="Forms">
    <forms loginUrl="LoginPage.aspx">
     <credentials passwordFormat="Clear">
       <user name="Jeff" password="imbatman" />
       <user name="John" password="redrover" />
       <user name="Bob" password="mxyzptlk" />
       <user name="Alice" password="nomalice" />
       <user name="Mary" password="contrary" />
     </credentials>
    </forms>
  </authentication>
 </system.web>
</configuration>
  Web.config in the secret subdirectory (to
       deny unauthenticated users)
<configuration>
 <system.web>
  <authorization>
    <deny users="?" />
  </authorization>
 </system.web>
</configuration>
   Why is the earlier example not
             realistic?
• Unreasonable to store passwords in clear
  text
• Storing a large number of
  names/passwords in Web.config is
  unrealistic. Instead, store them in a
  database.
• Modified Login.aspx is in the next few
  slides
<%@ Import NameSpace="System.Data.SqlClient" %>

<html>
 <body>
  <h1>Please Log In</h1>
  <hr>
  <form runat="server">
   <table cellpadding="8">
    <tr>
      <td>
       User Name:
      </td>
      <td>
       <asp:TextBox ID="UserName" RunAt="server" />
      </td>
    </tr>
    <tr>
      <td>
       Password:
      </td>
      <td>
       <asp:TextBox ID="Password" TextMode="password"
         RunAt="server" />
      </td>
    </tr>
    <tr>
      <td>
       <asp:Button Text="Log In" OnClick="OnLogIn"
         RunAt="server" />
      </td>
<td>
        <asp:Button Text="Log In" OnClick="OnLogIn"
          RunAt="server" />
       </td>
       <td>
        <asp:CheckBox Text="Keep me signed in" ID="Persistent"
          RunAt="server" />
       </td>
     </tr>
    </table>
  </form>
  <hr>
  <h3><asp:Label ID="Output" RunAt="server" /></h3>
 </body>
</html>
•   <script language="C#" runat="server">
•    void OnLogIn (Object sender, EventArgs e)
•    {
•      if (CustomAuthenticate (UserName.Text, Password.Text))
•          FormsAuthentication.RedirectFromLoginPage (UserName.Text,
•             Persistent.Checked);
•      else
•          Output.Text = "Invalid login";
•    }

•    bool CustomAuthenticate (string username, string password)
•    {
•      SqlConnection connection = new SqlConnection
•         ("server=localhost;database=weblogin;uid=sa;pwd=");

•      try {
•         connection.Open ();

•         StringBuilder builder = new StringBuilder ();
•         builder.Append ("select count (*) from users " +
•            "where username = \'");
•         builder.Append (username);
•         builder.Append ("\' and cast (rtrim (password) as " +
•            "varbinary) = cast (\'");
•         builder.Append (password);
•         builder.Append ("\' as varbinary)");

•         SqlCommand command = new SqlCommand (builder.ToString (),
•           connection);

•         int count = (int) command.ExecuteScalar ();
•         return (count > 0);
•      }
•      catch (SqlException) {
•         return false;
•      }
•      finally {
•         connection.Close ();
•      }
•    }
•   </script>
 New Web.config in main directory
<configuration>
 <system.web>
  <authentication mode="Forms">
    <forms loginUrl="LoginPage.aspx" />
  </authentication>
 </system.web>
</configuration>
 Authentication Cookie Lifetime
• Timeout value is controlled by:
  – In Machine.config file:
     • <forms … timeout=“30”>
  – In local Web.config file:
     configuration>
      <system.web>
       <authentication mode="Forms">
        <forms loginUrl="LoginPage.aspx" timeout = “30”/>
       </authentication>
      </system.web>
     </configuration>
  Forms Authentication and Role-
         based Security
• Previous example, all authenticated users
  have access; what if we want to restrict
  access to a few? (Here, * means all; ?
  means unauthenticated users)
  – In Web.config of the secret page:
     <authorization>
     <allow users = “John, Alice” />
     <deny users=“*” />
     </authorization>
• Alternately, deny access to Jeff, Bob, and Mary
  explicitly.
     <authorization>
     <deny users = “?” />
     <deny users = “Jeff, Bob, Mary” />
     <allow users=“*” />
     </authorization>
• Order sensitive statement execution
• Still not practical when a large number of users
  are involved
• Solution: Role based control
Using role-based authorization:
            Step 1
 In Web.config file of the secret directory:
 <configuration>
  <system.web>
   <authorization>
     <allow roles="Manager" />
     <deny users="*" />
   </authorization>
  </system.web>
 </configuration>
     Step 2: Mapping users to roles
void Application_AuthenticateRequest (Object sender, EventArgs e)
 {
    HttpApplication app = (HttpApplication) sender;

     if (app.Request.IsAuthenticated &&
         app.User.Identity is FormsIdentity) {
         FormsIdentity identity = (FormsIdentity) app.User.Identity;

         // Find out what role (if any) the user belongs to
         string role = GetUserRole (identity.Name); //From DB

         // Create a GenericPrincipal containing the role name
         // and assign it to the current request
         if (role != null)
             app.Context.User = new GenericPrincipal (identity,
                new string[] { role });
     }
 }
              Multiple roles?
if (role != null)
            app.Context.User = new GenericPrincipal
    (identity,
               new string[] { role });
The 2nd parameter is a string and hence could be:
new string[] { “Manager”, “Developer”});

In Web.config we can say:
<allow roles = “Manager, developer”/>
<deny users = “*”/>

								
To top