BEA’s Web Logic Container or IBM’s WebSphere Container provides low-level system functionality such as managing security. This is always preferable to providing an individual’s methods of securing an enterprise application. It is better to allow the containers to perform their routine, but essential, security tasks.
Developers must always secure a J2EE application in a web services environment. Sun and the Java community have developed numerous ways to secure enterprise applications. The following is a partial list of elements Java uses:
Java Security Domain Controller
Java Security Guard
Java Security Key
Java Security Principal
Java Security Privilege
Java Security Access Control
Refer to J2EE: The Complete Reference, by Jim Keogh (McGraw-Hill/Osborne, 2002), as an invaluable resource for learning more about the various methods of securing a web application in J2EE.
Access control is the process of determining who can access specified resources on a server. This includes both authentication and authorization. Developers have numerous methods for providing security in ASP.NET. You can use SSL to protect communications, Windows-based authentication, or Passport authentication. Yet another method is using Forms-Based (Cookie) authentication.
ASP.NET provides a new feature called Code Access Security (CAS). CAS is Microsoft’s answer to preventing untrusted code from performing undesirable actions on systems, resulting in compromise of mission-critical data. CAS allows developers to specify the level of security a given application must have. It gives you the option of using the <securityPolicy> and <trust> tags in the Web.config file. ASP.NET offers a preconfigured set of Code Access Security templates mapped to trust levels in Machine.config. Depending on the level of trust specified in the <trust> tag, the proper set of Code Access Security permissions is applied to the application. This feature provides fine-grained control over application security.
Security should receive top priority in an application, and ASP.NET provides many important methods for guaranteeing tight security. Developers can select impersonation as a means of providing tight security. Trusted connections use Windows security to connect to an SQL Server database without the need for providing a user ID and password. A best practice is to set up a trusted connection by taking the following steps:
Configure the application to use Windows authentication.
Add the <identity> tag to the configuration file, which enables ASP.NET to impersonate the identity of the client submitting the request:
Add all desired Windows accounts to the SQL Server security database.
Add Trusted_Connection=yes to the connection string used to gain access to SQL Server:
Select one of the accounts previously added to the SQL Server security database and log in to the ASP.NET application.
Typically, all client applications request access to resources. A client view is a set of restrictions on resources that a client can access, embedded within an application. By assigning clients to a group or specific role and granting or denying access to specific resources, you control client requests. For example, a client view might include specific databases, tables, or rows.
An alternative to a client view is a controller, which limits access to a resource. This is known as a resource guard. A client request contains an ID that is compared to a client’s configuration. Access is either permitted or denied on the basis of the client’s configuration file.
Applying a best practice in this context means using security measures provided by an operating system such as Windows or a DBMS or network. In a J2EE JVM environment, it is best to call on a servlet to intercept a client’s request, process it, validate it, and redirect the request to a specified EJB for fulfillment. Finally, use a Java Server Page to return the results to the client.
In .NET, you should use the Code Access Security features to limit access to code and resources. By employing permissions, you can define what a user can access.
If client access is limited to a particular DBMS, it is prudent to assign multiple users to a group profile and then assign permissions to that group. If this is not acceptable, remove the logic embedded within an application and use an external resource guard. The resource guard becomes shareable by multiple clients.