This article lists definitions for the terms that you will see
in the WebSphere® Application
Server for z/OS® Customization
Dialog.
Note: If you are setting up a "practice" stand-alone application server, choose
the default values wherever possible.
Security domain identifier
If
you want to distinguish between APPL or EJBROLE profiles based on security
domain name, set "Use security domain identifier in RACF® definitions" to "Y" and provide an
alphanumeric security domain name of one to eight characters.
Internally,
this sets "SecurityDomainType" to the string "cellQualified". All servers
in the cell will prepend the security domain name you specify to the application-specific
J2EE role name to create the SAF EJBROLE profile for checking.
Note: The security
domain name is not used, however, if role checking is performed using WebSphere Application
Server for z/OS bindings.
The
security domain name is also used as the APPL profile name and inserted into
the profile name used for CBIND checks. The RACF jobs that the Customization Dialog
generates create and authorize the appropriate RACF profiles for the created nodes and
servers.
If you do not want to use a security domain identifier, set
"Use security domain identifier in RACF definitions" to "N".
Cell-wide user IDs and groups
The first part of
setting up a security domain is to choose the cell-wide user IDs and group
names. Each name should contain one to eight alphanumeric characters with
an alphabetic first character.
Note: You can also use national characters (#,
$, and @), but these are better avoided as they can lead to compatibility
problems later.
Each user ID will also require a UNIX
® System Services
UID number, and each group will require a UNIX System Services GID number:
- UID values must be unique numeric values between 1 and 2,147,483,647.
Do not use a UID value of 0.
- GID values must be unique numeric values between 1 and 2,147,483,647.
Although you can set up several cells using a single security domain
definition, you should not share user IDs and groups between separate security
domains.
Choose names and UID values for the following
SAF user IDs, and enter them on the worksheet:
- WebSphere Application
Server Administrator
- This user ID is the initial WebSphere Application Server administrator
and also owns most of the cell's files in the configuration HFS. It must have
the WebSphere Application
Server configuration group (below) as its default UNIX System Services group. Certain customization
batch jobs must be run under this user ID.
- WebSphere Application
Server Asynchronous Administration Task
- This user ID is used to run asynchronous administration operations procedure.
It must be a member of the WebSphere Application Server configuration group.
- WebSphere Application
Server Unauthenticated User
- This user ID is associated with unauthenticated client requests. It is
sometimes referred to as the "guest" user ID. It should be given the RESTRICTED
attribute in RACF,
to prevent it from inheriting UACC-based access privileges, and it must be
a member of the WebSphere Application
Server unauthenticated user group (below).
Choose names and GID values for the following SAF groups,
and enter them on the worksheet:
- WebSphere Application
Server Configuration Group
- This is the default group name for the WebSphere Application Server administrator
user ID and all server user IDs. This is the group owner for most files in
the configuration HFS, so access to this group should be limited.
- WebSphere Application
Server Unauthenticated User Group
- This is the default group name for the WebSphere Application Server unauthenticated
user ID. You can place additional unauthenticated users in this group.
- WebSphere Application
Server Servant Group
- Connect all servant user IDs to this group. You can use it to assign subsystem
permissions, such as DB2® authorizations, to all servants in the security domain.
User registry
WebSphere Application
Server for z/OS can
use a SAF-based (local OS), LDAP, or custom registry. Select "Y" if you want
the customization process to prepare the RACF definitions for the local OS security
registry. Select "N" if you plan to use an LDAP or custom user registry instead.
SSL customization
If you plan
to enable Global Security at some point, as is recommended, fill in the following
SSL values:
- Certificate Authority Keylabel
- The name of the key label that identifies the certificate authority (CA)
to be used in generating server certificates.
- Generate Certificate Authority (CA) certificate
- Select "Y" to generate a new CA certificate. Select "N" to have an existing
CA certificate generate server certificates.
- Expiration date for CA authority
- The expiration date used for any X509 Certificate Authority certificates,
as well as the expiration date for the personal certificates generated for WebSphere Application
Server for z/OS servers.
You must specify this even if you selected "N" for "Generate Certificate Authority
(CA) certificate."
- Default RACF keyring
name
- The default name given to the RACF keyring used by WebSphere Application
Server for z/OS.
The keyring names created for repertoires are all the same within a cell.
- Enable SSL on location service daemon
- Select "Y" if you want to support secure communications using Inter-ORB
Request Protocol (IIOP) to the location service daemon using SSL. If you specify
"Y", a RACF keyring
will be generated for the location service daemon to use.
Additional z/OS security customization options
- Default RACF realm
name
This is a SAF setting used to identify a particular RACF (or compliant)
database; all systems sharing a single RACF database have the same RACF realm name.
The CSIv2 local OS registry uses the default RACF realm name (if one is set) or the
location service daemon IP name as the WebSphere security realm name.
If
you want to set or change the default RACF realm name, set "Generate default RACF realm
name" to "Y" and enter the RACF realm name to be set. The Customization Dialog
jobs will set the RACF realm name on each z/OS system where they are run.
- Use SAF EJBROLE profiles to enforce J2EE roles
Select "Y" to indicate the use of SAF EJBROLE profiles, rather than WebSphere Application
Server for z/OS bindings
created during application deployment, for authorization of J2EE and WebSphere Application
Server for z/OS administrator
roles. The value specified here has no effect until WebSphere Application Server for z/OS global
security is enabled.
When this variable is set to "Y", the RACF jobs generated
by the Customization Dialog will set up EJBROLE profiles required for WebSphere Application
Server for z/OS run
time administration and naming. In addition, the local OS registry is set
to use SAF authorization by default when global security is enabled. (Using
SAF authorization with LDAP or custom user registries requires both a change
in the user registry SAF authorization setting, and the installation of JAAS
system login pluggable identity mapping modules to map WebSphere Application Server for z/OS principals
to SAF user IDs.)
When SAF EJBROLE profiles are used, it is the WebSphere Application
Server for z/OS administrator's
responsibility to ensure that SAF EJBROLE profiles are defined, and a system
administrator's responsibility to complete user-to-role mapping.
- Enable SAF authorization using LTPA or ICSF login tokens
Specify "Y" to enable the WebSphere Application Server for z/OS servant
to authenticate users to the SAF registry without providing a password or
SAF-specific authenticator. This is required when:
- WebSphere Application
Server for z/OS security
is enabled
- Local OS is the active registry
and either:
- ICSF or LTPA is the authentication mechanism OR
- A Trust Association Interceptor is in use.
Setting this value to "Y" permits the WebSphere Application Server for z/OS servant
runtime (an unauthorized application) to log on to z/OS with a z/OS user ID but no z/OS authenticator. This is required to
establish a z/OS user
ID by way of the verification of a WebSphere Application Server for z/OS login
token verification or Trust Association Intercepter.
Note: Easing some traditional z/OS system
restrictions places additional responsibility on the WebSphere Application Server for z/OS administrator
to ensure that installed applications do not contain malicious code. You can
use Java™ 2
security to minimize this exposure.
WebSphere Application
Server user ID home directory
Note: This field was added to the Customization
Dialog in WebSphere Application
Server for z/OS Version
6.0.2.1.
- WebSphere Application
Server user ID home directory
- Specify a new or existing z/OS HFS directory in which home directories
for WebSphere Application
Server for z/OS user
IDs will be created by the customization process. This directory does not
need to be shared among z/OS systems in a WebSphere Application Server cell.