Introduction: Security
WAS provides many plug-in points to integrate with enterprise software components to provide end-to-end security. Security infrastructure and mechanisms protect J2EE resources and admin resources, addressing the enterprise security requirements.
- Administrative security
- Administrative security determines whether security is used at all, the type of registry against which authentication takes place, and other values, many of which act as defaults. Proper planning is required because incorrectly enabling admin security can lock you out of the admin console or cause the server to abend.
- Application security
- Application security enables security for the applications in the environment. This type of security provides application isolation and requirements for authenticating application users.
- Java 2 security
- Java 2 security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. Java 2 security guards access to system resources such as file I/O, sockets, and properties. J2EE security guards access to Web resources such as servlets, JSPs and EJB methods.
- The Security Configuration Wizard
- The Security Configuration Wizard guides you through the process of completing the basic requirements to secure the application serving environment.
- Multiple security domains
- WebSphere Security Domains provide the flexibility to use different security configurations in WAS. WSDs are also referred to as multiple security domains, or simply, security domains. Configure different security attributes, such as the UserRegistry, for different applications.
- Standalone custom registries
- A standalone custom registry is a customer-implemented registry that implements the UserRegistry Java interface, as provided by WAS ND. A custom-implemented registry can support virtually any type of an account repository from a relational database, flat file, and so on. The custom user registry provides considerable flexibility in adapting product security to various environments where some form of a registry or repository other than federated repositories, standalone LDAP registry or local operating system registry already exists in the operational environment.
- Local operating system registries
- With the registry implementation for the local operating system, the WAS authentication mechanism can use the user accounts database of the local operating system.
- Standalone LDAP registries
- WebSphere Application WAS security provides and supports the implementation of most major LDAP directory servers, which can act as the repository for user and group information.
- Select a registry or repository
- WAS provides implementations that support multiple types of registries and repositories including the local operating system registry, a standalone LDAP registry, a standalone custom registry, and federated repositories.
- Federated repositories
- Federated repositories enable you to use multiple repositories with WAS. These repositories, which can be file-based repositories, LDAP repositories, or a sub-tree of an LDAP repository, are defined and theoretically combined under a single realm.
- Lightweight Third Party Authentication
- LTPA is intended for distributed, multiple appserver and machine environments. LTPA supports forwardable credentials and SSO. LTPA can support security in a distributed environment through cryptography. This support permits LTPA to encrypt, digitally sign, and securely transmit authentication-related data, and later decrypt and verify the signature.
- Kerberos (KRB5) authentication mechanism support for security
- The Kerberos authentication mechanism enables interoperability with other applications (such as .NET, DB2 and others) that support Kerberos authentication. It provides SSO end-to-end interoperable solutions and preserves the original requester identity.
- RSA token authentication mechanism
- An authentication mechanism defines rules about security information, such as whether a credential is forwardable to another Java process, and the format of how security information is stored in both credentials and tokens. The Rivest Shamir Adleman (RSA) token authentication mechanism simplifies the security environment for flexible management topology, that is, the topology where we can locally or remotely submit and manage admin jobs through a job manager that manages applications, perform product maintenance, modify configurations, and control the appserver run time. The RSA authentication mechanism is only used for server-to-server admin authentication (admin connector and file transfer requests). The RSA authentication mechanism does not replace LTPA or Kerboros for use by applications.
- Trust associations
- Trust association enables the integration of IBM WAS security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while WAS applies its own authorization policy onto the resulting credentials that are passed by the proxy server.
- Single sign-on for authentication
- With SSO support, Web users can authenticate once when accessing both WAS resources, such as HTML, JSPs, servlets, enterprise beans, and Lotus Domino resources, such as documents in a Domino database, or accessing resources in multiple WAS domains.
- Single sign-on for HTTP requests using SPNEGO Web authentication
- We can securely negotiate and authenticate HTTP requests for secured resources in WAS by using the SPNEGO as the Web authentication service for WAS.
- Single sign-on for HTTP requests using SPNEGO TAI (deprecated)
- WAS provides a TAI that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources in WAS.
- Job manager security
- When performing a job manager registration process there are a number of WebSphere Application WAS security impacts to consider.
- Java Authentication and Authorization Service
- JAAX is a standard Java API that supports the Java 2 security authorization to extend the code base on the principal as well as the code base and users.
- Programmatic login for JAAS
- Programmatic login is a type of form login that supports application presentation site-specific login forms for the purpose of authentication.
- Security attribute propagation
- With Security attribute propagation, WAS can transport security attributes (authenticated Subject contents and security context information) from one server to another in the configuration. WAS might obtain these security attributes from either an enterprise user registry, which queries static attributes, or a custom login module, which can query static or dynamic attributes. Dynamic security attributes, which are custom in nature, might include the authentication strength used for the connection, the identity of the original caller, the location of the original caller, the IP address of the original caller, and so on.
- Authentication protocol for EJB security
- We can choose from two authentication protocols:
- z/OS Secure Authentication Service (z/SAS)
- CSIv2
- Authorization technology
- Authorization information determines whether a user or group has the necessary privileges to access resources.
- Fine-grained admin security
- In releases before WAS version 6.1, users granted admin roles could administer all of the resource instances under the cell. WAS is now more fine-grained, meaning that access can be granted to each user per resource instance.
- Fine-grained admin security in heterogeneous and single-server environments
- Fine-grained admin security can be used in heterogeneous or single-server environments with some restrictions.
- Secure communications using SSL
- The SSL protocol provides transport layer security including authenticity, data signing, and data encryption to ensure a secure connection between a client and server that uses WAS. The foundation technology for SSL is public key cryptography, which guarantees that when an entity encrypts data using its private key, only entities with the corresponding public key can decrypt that data.
- Key management for cryptographic uses
- WAS provides a framework for managing keys (secret keys or key pairs) that applications use to perform cryptographic operations on data. The key management framework provides an API for retrieving these keys. Keys are managed in keystores so the keystore type can be supported by WAS, provided that the keystores can store the referenced key type. We can configure keys and scope keystores so that they are visible only to particular processes, nodes, clusters, and so on
- Web server plug-in default configuration
- By creating a new Web server definition, WAS associates the Web server plug-in with a Certificate Management Services (CMS) keystore for a specific node. The keystore contains all of the signers for the current cell with the self-signed or chained certificate, which belongs to the node. The plug-in can communicate securely to WAS, even when the plug-in is configured with SSL client authentication enabled.
- Secure transports with JSSE and JCE programming interfaces
- This page provides detailed information about transport security using JSSE (JSSE) and JCE programming interfaces. Within this topic, there is a description of the IBM version of the Java Cryptography Extension FIPS (IBMJCEFIPS).
- Plug point for custom password encryption
- A plug point for custom password encryption can be created to encrypt and decrypt all passwords in WAS that are currently encoded or decoded using Base64-encoding.
- Secure Socket Layer communication with DataPower
- Based on the default installations of the appserver and the DataPower appliance manager, SSL communication is used to send commands and receive events. The default SSL configuration used by the DataPower appliance manager can be strengthened by customizing the SSL connection. Modifying the default SSL configuration is optional and only needs to be done if the default configuration is not sufficient for the requirements.
- DMZ Secure Proxy Server for IBM WAS start up user permissions
- The overall security level of the DMZ Secure Proxy Server for IBM WAS can be hardened by reverting the server process to run as an unprivileged user after startup. Although the DMZ Secure Proxy Server for IBM WAS must be started as a privileged user, changing the server process to run as an unprivileged user provides additional protection for local operating resources.
- DMZ Secure Proxy Server for IBM WAS routing considerations
- This page summarizes some of the security implications that must be considered when choosing how the DMZ Secure Proxy Server for IBM WAS will match incoming HTTP requests to an application or routing rule.
- DMZ Secure Proxy Server for IBM WAS administration options
- The DMZ Secure Proxy Server for IBM WAS is administered differently than the WebSphere proxy server. The DMZ Secure Proxy Server for IBM WAS is a separate binary installed in the DMZ. Installing the DMZ Secure Proxy Server for IBM WAS in the DMZ requires that administration be managed differently for security reasons. Several administrative options are available for administering the DMZ Secure Proxy Server for IBM WAS to provide different levels of balance between security and usability.
- Error handling security considerations for the DMZ Secure Proxy Server for IBM WAS
- The overall security level of the DMZ Secure Proxy Server for IBM WAS is partially determined by the choices made regarding the handling of custom errors.
- Web component security
- We can develop a Web module and enforce security at the method level of each Web resource.
- Security role references in Web apps
- Web app developers or EJB providers that use the available programmatic security J2EE APIs, isUserInRole(String roleName) or isCallerInRole(String roleName), use a role-name in the code.
- Portlet URL security
- WAS enables direct access to portlet URLs, just like servlets. This section describes security considerations when accessing portlets using URLs.
- UDDI registry security and UDDI registry settings
- In addition to the configuration of UDDI registry security, there a number of other UDDI registry settings which may affect the behavior of the UDDI registry. Some of these settings are security specific, others are points to bear in mind when configuring security.
- J2EE connector security
- The J2EE connector architecture defines a standard architecture for connecting the J2EE to heterogeneous enterprise information systems (EIS).
- Trusted connections with DB2
- Trusted connections allow for the appserver to use DB2 Trusted Context objects to establish connections with a user whose credentials are trusted by the DB2 server to open the connection. Through establishing a Trusted Context, this user is then trusted to assert other user identities on the DB2 server without the expense of reauthentication.
This also enhances the security of the DB2 database by eliminating the need to assign all privileges to a single user. Implementing trusted connections results in client identity propagation while leveraging connection pooling to eliminate the performance penalty of closing and reopening connections with a different identity.
Related information
New features for securing applications and their environment