|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 6
Your security team can prevent unauthorized code use by limiting the classes available to the virtual machine used by the servlet engine. You can achieve this process of code authorization by removing unnecessary entries from the classpath.
The security team has complete control over which code should be included in the classpath and can therefore authorize the code prior to inclusion. The team should ensure that the code does not have access to third-party tools or extraneous code.
In addition to code authorization, you can also authenticate the caller of back-office systems. The EJB model, for example, lets the development team specify a username and password for access to any bean deployed in a container.
Any code that attempts to connect to these beans must pass the username/password combination to the container for authorization. A failed authorization results in an exception that prevents the caller from completing its action.
In this second example, I'll explore the mechanisms built into the EJB specification for preventing unauthorized access to the business logic. While this example is based on the WebLogic Tengah server, the concepts hold true for other servers even though the syntax will differ. See Resources for the code or configuration files used in this example.
In the EJB's deployment descriptor, the following code identifies the access control entries associated with the bean:
(accessControlEntries DEFAULT [administrators basicUsers] theRestrictedMethod [administrators] ); end accessControlEntries
Notice that two user categories have been identified. Administrators have access to the bean by default and constitute the
only user group that has access to theRestrictedMethod.
Once you've authorized that the administrators have access to the bean, you now need to create properties detailing which users are in the administrators group. To do this, the weblogic.properties file must include the following lines:
weblogic.password.JoeAdministrator=joe weblogic.security.group.administrators=JoeAdministrator weblogic.password.JaneBasic=jane weblogic.security.group.basicUsers=JaneBasic
At this point, you've established the users who have access to the bean and have restricted certain specific methods. This helps limit the potential for malicious attacks on your Web server to reach the business logic stored in the beans.
The last step in this EJB authorization example is to establish the client connection to the bean. In this case, the client must specify the username/password combination properly in order to have access to the restricted bean or methods. An example client communication follows:
try{
Properties myProperties = new Properties();
myProperties.put( Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.T3InitialContextFactory");
myProperties.put(Context.PROVIDER_URL, "t3://localhost:7001");
myProperties.put(Context.SECURITY_PRINCIPAL, "JoeAdministrator");
myProperties .put(Context.SECURITY_CREDENTIALS, "joe");
ic = new InitialContext(myProperties);
...
}
catch (Exception e) { ... }
Since you've passed the JoeAdministrator user to the InitialContext, you'll have access to any method to which the administrators group has been granted access. If your application makes connections
to external beans or your beans are used by external applications, you should implement this security authorization.