![[Note]](images.admon/note.gif) | |
|
Security types
The security infrastructure of WebSphere Application Server is broadly divided into the following types of security (illustrated in figure below) from the administrative console:
Administrative security protects resources such as the administrative console, wsadmin, and scripts. When administrative security is enabled, naming security, authentication of HTTP clients, and use of SSL transports are also enabled.
Application security protects access to applications. It provides application isolation and requirements for authenticating application users. Application security for servlets is achieved by defining security constraints that determine how the web content is to be protected. Application security for EJB methods is achieved by assigning security roles to them.
Java 2 security protects the local system from applications that are deployed to WebSphere Application Server. When Java 2 security is enabled, it provides an access control mechanism to manage the access of an application to system-level resources.
The Java security model offers access control to system resources, including file system, system property, socket connection, threading, and class loading. Application code must explicitly grant the required permission to access a protected resource.
This type of security model is called Java 2 security because this type of security was first introduced in Java Version 2. It replaces the signed code and sandbox model that was used in earlier versions. Java 2 uses security policy files, which can control the access to the resources by applications. A WebSphere Application Server application has its own policy files, so that it can use files and directories on the host operating system. Also, the deployed applications inside WebSphere Application Server can use their own policy files.
NOTE: When Java 2 security is disabled, access to local resources is not restricted. If you want to use the Java 2 security policies for your application, enable Java 2 security in the administrative console (ISC).
Consider using Java 2 security only for specific situations where one or more application resources need this type of protection. Enabling Java 2 security can cause a significant impact on performance.
