Securing web services msc it ps03 cint05


Published on

web services security

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Securing web services msc it ps03 cint05

  1. 1. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 1 Securing Web services [1] Built in Authentication: (Through Membership) ASP.NET membership gives you a built-in way to validate and store user credentials. ASP.NET membership therefore helps you manage user authentication in your Web sites. One can use ASP.NET membership with ASP.NET forms authentication by using with the ASP.NET login controls to create a complete system for authenticating users. ASP.NET membership supports facilities for: Creating new users and passwords. Storing membership information (user names, passwords, and supporting data) in Microsoft SQL Server, Active Directory, or an alternative data store. Authenticating users who visit your site. You can authenticate users programmatically, or you can use the ASP.NET login controls to create a complete authentication system that requires little or no code. Managing passwords, which includes creating, changing, and resetting them. Depending on membership options you choose, the membership system can also provide an automated password-reset system that takes a user-supplied question and response. Exposing a unique identification for authenticated users that you can use in your own applications and that also integrates with the ASP.NET personalization and role-management (authorization) systems. Although membership is a self-standing feature in ASP.NET for authentication, it can be integrated with ASP.NET role management to provide authorization services for your site. Membership can also be integrated with user profile properties to provide application-specific customization that can be tailored to individual users. How Membership Works To use membership, you must first configure it for your site. The following are the basic steps you follow in order to configure membership: 1. Specify membership options as part of your Web site configuration. By default, membership is enabled. You can also specify what membership provider you want to use. The default provider stores membership information in a Microsoft SQL Server database. However, you can use other providers as well, such as a provider for Windows Live ID. You can also choose to use Active Directory to store membership information, or you can specify a custom provider. For information about membership configuration options that can be specified in the Web.config file for your ASP.NET application. Configure your application to use forms authentication.
  2. 2. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 2 2. You can also specify that some pages or folders in your application are protected and are accessible only to authenticated users. 3. Define user accounts for membership. You can do this in a variety of ways. You can use the Web Site Administration Tool, which provides a wizard-like interface for creating new users. Alternatively, you can use an ASP.NET Web page where you collect a user name and password (and optionally an email address), and then use the CreateUser membership method to create a new user in the membership system. You can then use membership to authenticate users in your application. Typically, you will provide a page where users can log in, a registration page where new users can sign up, and a change-password page where users can change their password. The ASP.NET login controls (Login, LoginView, LoginStatus, LoginName, and PasswordRecovery) encapsulate virtually all of the logic required to prompt users for credentials and validate the credentials in the membership system. If you have configured the application to use forms authentication, ASP.NET will automatically display the login page if an unauthenticated user requests a protected page. If you use the project templates that are provided in ASP.NET or use the login controls, they will automatically use the membership system to validate a user. If you create custom login controls, you must call the ValidateUser method to validate the user’s user name and password. After the user is validated, information about the user can be persisted (for example, with an encrypted cookie if the user's browser accepts cookies). The login controls perform this task automatically, but if you create custom login controls, you can call methods of the FormsAuthentication class to create the cookie and write it to the user's computer. If a user has forgotten his or her password, the login page can call membership functions that help the user recover the password or reset the password. Each time the user requests a page, ASP.NET forms authentication checks whether the user is authenticated. If a page is restricted, users who are authenticated and are members of the approved roles are allowed to view the page. Anonymous users (users who
  3. 3. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 3 are not logged in) are directed to the login page. By default, the authentication cookie remains valid for the user's session. After a user has been authenticated, the membership system makes available an object that contains information about the current user. For example, you can get properties of the membership user object to determine the user's name and email address, when the user last logged into your Web site, and so on. An important aspect of the membership system is that you never need to explicitly perform any low-level database functions to get or set user information. For example, you create a new user by calling the membership CreateUser method. The membership system handles the details of creating the necessary database records to store the user information. When you call the ValidateUser method to check a user's credentials, the membership system does all the database lookup for you. [2] Role Based Security: Role Based Security lets you identify groups of users to allow or deny based on their role in the organization. In Windows NT and Windows XP, roles map to names used to identify user groups. Windows defines several built-in groups, including Administrators, Users, and Guests. To allow or deny access to certain groups of users, add the <ROLES>element to the authorization list in your Web application's Web.config file. Example: < authorization > < allow roles="Domain NameAdministrators" / > < !-- Allow Administrators in domain. -- > < deny users="*" / > < !-- Deny anyone else. -- > < /authorization > Role-based security in the .NET Framework supports three kinds of principals: 1. Windows principals represent Windows users and their roles. 2. Generic principals represent users and roles that exist independent of Windows NT and Windows 2000 users and roles.
  4. 4. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 4 3. Custom principals can be defined by an application that is needed for that particular application. They can extend the basic notion of the principal's identity and roles. Roles are often used in financial or business applications to enforce policy. For example, an application might impose limits on the size of the transaction being processed depending on whether the user making the request is a member of a specified role. Clerks might have authorization to process transactions that are less than a specified threshold, supervisors might have a higher limit, and vice-presidents might have a still higher limit (or no limit at all). Role-based security can also be used when an application requires multiple approvals to complete an action. Such a case might be a purchasing system in which any employee can generate a purchase request, but only a purchasing agent can convert that request into a purchase order that can be sent to a supplier. .NET Framework role-based security supports authorization by making information about the principal, which is constructed from an associated identity, available to the current thread. The identity (and the principal it helps to define) can be either based on a Windows account or be a custom identity unrelated to a Windows account. .NET Framework applications can make authorization decisions based on the principal's identity or role membership, or both. A role is a named set of principal that have the same privileges with respect to security (such as a teller or a manager). A principal can be a member of one or more roles. Therefore, applications can use role membership to determine whether a principal is authorized to perform a requested action. To provide ease of use and consistency with code access security, .NET Framework role-based security provides PrincipalPermission objects that enable the common language runtime to perform authorization in a way that is similar to code access security checks. The PrincipalPermission class represents the identity or role that the principal must match and is compatible with both declarative and imperative security checks. You can also access a principal's identity information directly and perform role and identity checks in your code when needed. The .NET Framework provides role-based security support that is flexible and extensible enough to meet the needs of a wide spectrum of applications. You can choose to interoperate with existing authentication infrastructures, such as COM+ 1.0 Services, or to create a custom authentication system. Role-based security is particularly well-suited for use in ASP.NET Web
  5. 5. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 5 applications, which are processed primarily on the server. However, .NET Framework role-based security can be used on either the client or the server. [3] Code Based Security: Today's highly connected computer systems are frequently exposed to code originating from various, possibly unknown sources. Code can be attached to e-mail, contained in documents, or downloaded over the Internet. Unfortunately, many computer users have experienced firsthand the effects of malicious mobile code, including viruses and worms, which can damage or destroy data and cost time and money. Most common security mechanisms give rights to users based on their logon credentials (usually a password) and restrict resources (often directories and files) that the user is allowed to access. However, this approach fails to address several issues: users obtain code from many sources, some of which might be unreliable; code can contain bugs or vulnerabilities that enable it to be exploited by malicious code; and code sometimes does things that the user does not know it will do. As a result, computer systems can be damaged and private data can be leaked when cautious and trustworthy users run malicious or error-filled software. Most operating system security mechanisms require that every piece of code must be completely trusted in order to run, except perhaps for scripts on a Web page. Therefore, there is still a need for a widely applicable security mechanism that allows code originating from one computer system to execute with protection on another system, even when there is no trust relationship between the systems. To help protect computer systems from malicious mobile code, to allow code from unknown origins to run with protection, and to help prevent trusted code from intentionally or accidentally compromising security, the .NET Framework provides a security mechanism called code access security. Code access security allows code to be trusted to varying degrees depending on where the code originates and on other aspects of the code's identity. Code access security also enforces the varying levels of trust on code, which minimizes the amount of code that must be fully trusted in order to run.
  6. 6. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 6 Using code access security can reduce the likelihood that your code can be misused by malicious or error-filled code. It can reduce your liability because you can specify the set of operations your code should be allowed to perform as well as the operations your code should never be allowed to perform. Code access security can also help minimize the damage that can result from security vulnerabilities in your code. All managed code that targets the common language runtime receives the benefits of code access security, even if that code does not make a single code access security call. Code access security is a mechanism that helps limit the access code has to protected resources and operations. In the .NET Framework, code access security performs the following functions: Defines permissions and permission sets that represent the right to access various system resources. Enables administrators to configure security policy by associating sets of permissions with groups of code (code groups). Enables code to request the permissions it requires in order to run, as well as the permissions that would be useful to have, and specifies which permissions the code must never have. Grants permissions to each assembly that is loaded, based on the permissions requested by the code and on the operations permitted by security policy. Enables code to demand that its callers have specific permissions. Enables code to demand that its callers possess a digital signature, thus allowing only callers from a particular organization or site to call the protected code. To determine whether code is authorized to access a resource or perform an operation, the runtime's security system walks the call stack, comparing the granted permissions of each caller to the permission being demanded. If any caller in the call stack does not have the demanded permission, a security exception is thrown and access is refused. The stack walk is designed to help prevent luring attacks, in which less- trusted code calls highly trusted code and uses it to perform unauthorized actions. Demanding permissions of all callers at run time affects performance, but it is essential to help protect code from luring attacks by less-trusted code. Every developer must be familiar with the following code access security concepts in order to write effective applications targeting the common language runtime:
  7. 7. PS03CINT05 Unit-1 Mr. Pritesh N. Patel Page 7 Writing type-safe code: To enable code to benefit from code access security, you must use a compiler that generates verifiably type-safe code. Imperative and declarative syntax: Interaction with the runtime security system is performed using imperative and declarative security calls. Declarative calls are performed using attributes; imperative calls are performed using new instances of classes within your code. Some calls can be performed only imperatively, while others can be performed only declaratively. Requesting permissions for your code: Requests are applied to the assembly scope, where your code informs the runtime about permissions that it either needs to run or specifically does not want. Security requests are evaluated by the runtime when your code is loaded into memory. Requests cannot influence the runtime to give your code more permissions than the runtime would have given your code had the request not been made. However, requests are what your code uses to inform the runtime about the permissions it requires in order to run. Using secure class libraries: Your class libraries use code access security to specify the permissions they require in order to be accessed. You should be aware of the permissions required to access any library that your code uses and make appropriate requests in your code.