This version contains many new and changed features for those who are responsible for securing applications and the application serving environment.
The LTPA Token V2.0 token type is available only for bindings using the new namespace in IBM® WebSphere® Application Server, Version 7.0 or later. When you select LTPA Token V2.0 as the token type for the token consumer, both LTPA tokens and LTPA V2.0 tokens can be consumed. To restrict the token consumer to LTPA V2.0 tokens only, select the Enforce token version check box.
If you select LTPA Token as the token type for the token generator, single sign-on interoperability mode must be enabled. This is a setting in global security from Web and SIP security. If the interoperability flag is not set to enabled (true), an error occurs when the application that is attached to these bindings is started. If you want to use the LTPA token without checking the state of the interoperability flag, you can set the custom property, com.ibm.wsspi.wssecurity.tokenGenerator.ltpav1.pre.v7, on the token generator. Set the property using the administrative console, as described in the topic Enabling or disabling single sign-on interoperability mode for the LTPA token. The property can not be set using the Web Services Security API.
In WebSphere Application Server version 7.0, Java Authorization Contract for Containers (JACC) specification 1.4 is being applied. In JACC specification 1.4, we support Java EE5 that includes Servlet 2.5 and EJB 3. The biggest functional change with the introduction of JACC specification 1.4 is the inclusion of annotations for propagating security policy information.
The ability to configure a bootstrap member policy for a bus is new in this release. Use this policy to nominate cell members to service requests to bootstrap into the bus.
WebSphere Application Server Version 7.0 provides support for multiple callers. The caller token used for authentication is the one with highest priority, based on decreasing order of preference. You can modify the order of the callers, as described in the topic Changing the order of the callers for a token or message part.
The support for Kerberos with Web services security in WebSphere Application Server Version 7.0 is based on the OASIS Web Service Security Kerberos Token Profile 1.1 specification.
The configuration of the default cell level and default server level bindings has changed in WebSphere Application Server Version 7.0. Previously, you could configure only one set of default bindings for the cell, and optionally configure one set of default bindings for each server. In Version 7.0, you can configure one or more general provider bindings and one or more general client bindings. However, only one general provider binding and one general client binding can be designated as the default.
In this release of WebSphere Application Server, a new style of system management called flexible management has been introduced. It differs from the existing style of synchronous invocation and response calls through wsadmin or Java APIs by offering an asynchronous job queuing mechanism for administration purposes. At the core of flexible management is a new administrative process called the job manager. You can make both application servers registered to administrative agents and deployment manager servers known to the job manager through a registration process. After you register the servers, you can queue administrative jobs directed at the application servers or deployment managers through the job manager. You can submit these jobs to a large number of servers over a geographically dispersed area. There are a number of security considerations you must keep in mind both during and after the job manager registration process.
In this release, messaging engine security is enhanced because ports are only opened for transport chains that are required by the bus. In the previous release, the InboundBasicMessaging port was opened even for transport chains that were not required.
Multiple security domain support is new in this release of WebSphere Application Server. You can create different security configurations and assign them to different applications in WebSphere Application Server processes. By creating multiple security domains, you can configure different security attributes for both administrative and user applications within a cell environment. You can configure different applications to use different security configurations by assigning the servers or clusters or service integration buses that host these applications to the security domains. Only users assigned to the administrator role can configure multiple security domains.
The RSA token authentication mechanism is new to this release of WebSphere Application Server. It aids the flexible management objective to preserve the base profiles configurations and isolate them from a security perspective. This mechanism permits the base profiles managed by an administrative agent to have different Lightweight Third-Party Authentication (LTPA) keys, different user registries, and different administrative users.
In this release, you can configure a bus to use multiple security domains, in which case the bus also has a security domain and user realm to further enforce its authorization policy.
Also new in this release, you can start a wizard from the Bus Security administrative console panel, or specify individual security properties directly in the panel. The bus security properties are effective only when administrative security for the cell is enabled. If the wizard detects that administrative security is disabled, the wizard prompts you to enable security.
In this release, the procedure to administer role-based authorization for service integration security is simplified by the introduction of a number of new and updated administrative console panels.
Chained certificates are the default certificate type in WebSphere Application Server Version 7.0. The convertSelfSignedCertificatesToChained command takes information from the self-signed certificate—such as issued-to DN, size, and life span—and creates a chained certificate with the same information. The new chained certificate replaces the self-signed certificate. Signer certificates from the self-signed certificate that are distributed across the security configuration are replaced with the signer certificates from the root certificate used to sign the chained certificate.
Beginning with this fix pack, if you want changes in SAF to a user or group membership to become effective immediately, you can call the purgeUserFromAuthCache SecurityAdmin mbean method for the modified user. Otherwise, the changes become effective when the cache is refreshed on a periodic basis.
An authorization policy controls who can access protected SCA components and operations. A security identity policy declares the security identity under which an SCA component or operation is executed. You can limit access to an SCA component or to an operation to particular users or groups. You can also delegate access to another user when executing an SCA component or an operation.
SCA service developers can use the RequestContext.getSecuritySubject() API to obtain a JAAS Subject that represents the requester.