The following table shows some of the details and topology differences in migrating from Version 4.0.1 security to Version 5.
Version 4.0.1 Topology | Version 5 Topology |
Security is server level based. | Security is cell based. A subset of cell security attributes such as Internet InterORB Protocol (IIOP) authentication protocols, SSL ports, and so on, can be overridden at a cell level. Refer to the security section in the documentation for information for cell and server level security attributes. |
Security is automatically enabled. | Security, by default, is not enabled. You must turn it on. |
Web Single Sign-on is only supported across WebSphere for z/OS version 4.0.1 servers using the ICSF Authentication mechanism. | Web Single Sign-on across WebSphere Application
Server for z/OS version 5 servers can still be performed using the Integrated
Cryptographic Services Facility (ICSF) Authentication Mechanism. Single Sign-on
with WebSphere Application Server for distributed platforms servers and Domino
can be achieved using the Lightweight Third Party Authentication (LTPA) authentication
mechanism. You must configure either ICSF or LTPA as an authentication mechanism if you wish to have a secure server that can use forms-based authentication. Simple WebSphere Authentication Mechanism (SWAM) is configurable for base, but not recommended, since the administration console requires forms based authentication when security is enabled. For WebSphere Application Server Network Deployment, you must specify ICSF or LTPA. To view this administrative console page, click: Security > Global Security |
Access to the data is controlled by DB2 authentication. | Access requires SSL encryption and forms
based authentication when security is enabled. Authorization is done using
administrative users and groups to define role based authorizations. System Administration > Console Users System Administration > Console GroupThe data is protected by Hierarchical File System (HFS) file permissions. Access from a remote workstation requires SSL and forms based authentication. Note: EJBROLE role access to administrative roles (administrator, configurator, monitor, and operator roles) is an alternative to console users and console groups. |
Access to naming services is controlled LDAP Access Control Lists (ACLs) | Access to naming services is no longer
controlled by LDAP Access Control Lists (ACLS); instead use: Environment > Naming Service > CORBA Naming Service Users Environment > Naming Service > CORBA Naming Service Groups The SAF EJBROLE profiles for the CosNamingRead, CosNamingWrite, CosNamingCreate and CosNamingDelete roles are an alternative to the CORBA Naming Service users and groups. Note: MVS IDs and groups must have UNIX system services uids and gids in order to be given access to naming or administrative services. |
Method authorization is done using SAF EJBROLE profiles. | The default form of method authorization
is WebSphere Application Server bindings. You can continue to do method authorizations using existing SAF EJBROLE profiles, by clicking Security > User Registries > Local OS > Custom Properties >com.ibm.security.SAF.authorization=true |
Resolving the identity when using the RUNAS role uses APPLDATA on a SAF EJBROLE profile. | Use "Delegation RUNas specified" If you wish to use SAF APPLDATA to resolve the user ID, as in Version 4, you must go to the Custom Properties panel in the administrative console by clicking Security > User Registries > Local OS > Custom Properties >com.ibm.security.SAF.delegation=true |
Basic server configuration is a SAF registry such as RACF. | If you wish SAF to be used as the registry for users of the system, specify LocalOS as the User Registry. In addition, version 5 supports additional registries such as LDAP. |
Version 4.0.1 IIOP Interoperability | In version 5, CSIv2 is the security default. If you use IIOP communications, and your server will interoperate with servers using WebSphere Application Server for OS/390 or z/OS version 4 (or 4.01), you must use protocols compatible with these servers. These are known as z/SAS and can be found on the administrative console page, by clicking Security > Global Security > Active Authentication Protocol They must be modified to show CSI and SAS. You must also select the appropriate authentication mechanism by clicking Security > zSAS TransportOtherwise, you should consider using CSIv2 Authentication Protocols as these provide more control over authenticating clients. If both are specified, z/OS version 5 clients will prefer CSIv2. If a client and server protocol match can be made using any configured CSIv2 protocol, it will be attempted prior to any z/SAS protocols. |
Secure Socket Layer (SSL)- You set up a
single keyring in RACF as a server. In version 4.0.1 all server supported ciphers were provided during the negotiation process (from no encryption to 128 bit). |
If security is turned on and the default SOAP/HTTP administrative connector is enabled, the JSSE implementation has to be configured. JSSE implementation supports different key stores locations (server key, keys to those that you trust, and others) located in a HFS. SSL is now configured through SSL repertoires. You now configure all the attributes you expect in an SSL configuration, key ring or file name, sets of cipher suites. You can also save the definition as a repertoire; either a System SSL repertoire or a JSSE repertoire. The repertoire becomes active when you select it for use in a specific context. (Remember to use System SSL for HTTP and IIOP connectors. As in version 4, the key ring names must be identical within a process.) Note:
In version 5 you only get the set of ciphers that you select. They are predefined as (High 128 bit), (Medium), (Low), or you can create a customized list of ciphers that you can export . To view this administrative console page, click Security > SSL > alias_name. This path is for both System SSL repertoire and JSSE SSL repertoire. |
Features no longer supported on version
5:
|