250 likes | 309 Views
ASP.Net Security. Chapter 10 Jeff Prosise’s Book. Authentication. To ascertain the caller’s identity Windows authentication Forms authentication Passport authentication
E N D
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
Authentication (cont.) • 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
Authentication (cont.) • 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"; } </script>
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 = “*”/>