View source for Security Server (formerly RACF) interface

==Overview==
This topic presents an overview of how Security Server works and describes the impact of the Security Server Interface on the Model 204 user, system manager, and Security Server security administrator.  

<p class="note"><b>Note:</b> The Security Server interface was formerly known as the RACF interface.</p>
 
===Security Server===

<p>Security Server is an extension of the IBM z/OS operating system that provides comprehensive data security. The Security Server Interface allows a Model 204 installation to use Security Server services within the Security Server environment. </p>
 
===Model 204 Security Server Interface===

<p>The Model 204 Security Server Interface allows an orderly migration from Model 204 security to Security Server security and allows an installation to use a combination of either or both security methods. The interface provides the tools and instructions necessary to: </p>

<ul>
<li>Define a Security Server control group so that Model 204 can distinguish between separately running copies (that is, test and production) 
</li>

<li>Define Security Server generic profiles for Security Server authorization of Model 204 user privileges within a control group 
</li>

<li>Define a generic profile within Security Server that is associated with a control group, and determines whether a user can log in to Model 204 
</li>

<li>Define a Security Server common control group for Model 204 resources that can be shared between running copies 
</li>

<li>Define a default user priority class, or define the Security Server generic profiles that permit certain users to have specified Model 204 priorities 
</li>

<li>Provide a mechanism to validate accounting information 
</li>

<li>Determine a generic profile within Security Server that can define whether a user is allowed to submit JCL through the USE command 
</li>

<li>Allow a system manager to add, change, or delete Security Server Interface options that control interface operations 
</li>

<li>Provide a mechanism that establishes a shadow login capability to restrict user authorization via a default user ID for users who do not log directly in to Security Server 
</li>

<li>Provide a method for a Security Server security administrator to define a default group, user ID, and password for the default user ID 
</li>

<li>Provide a method for a Security Server security administrator to force users to log in through Security Server and not through 
CCASTAT 
</li>
</ul>
===Model 204 Security Server Interface components===

<p>In summary, the Security Server Interface provides all the facilities an installation needs to implement Security Server security within the Model 204 environment. </p>

<p>
The following figure illustrates the components of the Security Server Interface. </p>

<center>
[[File:SECURITY_Security_Server_interface.jpg|border|450px]]
</center>
 
<p class="caption">Security Server Interface</p>

<p>The Security Server Interface consists of the following components: </p>

<table>
<tr><th>Component</th> <th>Notes</th></tr>
<tr>
<td>Model 204 </td>

<td>Links with the Security Server Interface module </td>
</tr>

<tr>
<td>Security Server Interface module, RACFOS</td>

<td>Communicates with Security Server by using the System Authorization Facility (SAF) z/OS router</td>
</tr>

<tr>
<td>RACFPARM module </td>

<td>Can be linked with Model 204 or loaded dynamically at initialization</td>
</tr>

<tr>
<td>Model 204 system file, CCASTAT</td>

<td>Contains file protection passwords, user IDs, and user ID passwords</td>
</tr>

</table>

==Brief introduction to Security Server==

<p>This section provides a brief summary of key Security Server features that are used in the discussion of the Model 204 Security Server Interface. </p>

<p>For more information about the Security Server, see the [http://www-03.ibm.com/systems/z/os/zos/features/racf/resources.html IBM documentation] associated with that product. </p>

===Security Server processing===

<p>Security Server identifies and verifies users accessing a system in which Security Server is installed and determines whether or not the user: </p>

<ul>
<li>Is defined to Security Server 
</li>

<li>Has supplied a valid password (and/or operator identification card) and group name 
</li>

<li>Has the REVOKE attribute, which prevents a Security Server defined user from entering the system at all or from entering the system with certain groups 
</li>

<li>Can use the system only at certain times or on certain days as specified by the system manager or Security Server security officer 
</li>

<li>Is authorized to access the terminal (which also can include day and time restrictions for accessing that terminal) 
</li>

<li>Is authorized to access the application 
</li>
</ul>

The following types of checking are performed by Security Server: 
<ul>

<li>Authorization 
</li>

<li>Global access 
</li>
</ul>

===Authorization checking===

<p>When Security Server verifies a user’s identity, Security Server specifies the scope of that user’s authorization for the current terminal session or batch job in a control block called the accessor environment element (ACEE). Security Server controls the interaction between the user and protected resources and authorizes not only which resources the user can access, but the way in which the user can access them (for example, as read-only or update). </p>

<p>At the start of processing, Security Server performs the following checks that are related to the security classification of users 

and data: </p>

<ul>
<li>Compares the security level in the user and resource profiles. If the resource has a higher security level than the user, Security Server denies the request. 
</li>

<li>Checks a category list (that is, a list of site-defined names corresponding to departments or areas within an organization) in the user’s profile against the category list in the resource profile. If the resource profile contains a category that is not in the user’s 
profile, Security Server denies the request. 
</li>
</ul>

<p>If Security Server has not denied the request as a result of the security classification checks, processing continues. </p>

<p>Security Server permits access to a resource if the user satisfies any of a number of conditions, such as the following: </p>

<ul>
<li>The resource is a data set and the high-level qualifier is the user’s user ID 
</li>

<li>The user’s user ID is in the access list with sufficient authority 
</li>

<li>The user’s current connect group is in the access list with sufficient authority 
</li>

<li>When list-of-group checking is active, one of the other groups with which the user is connected is in the access list with sufficient authority 
</li>

<li>The universal access authority (UACC) is sufficiently high 
</li>

<li>The user satisfies both of these conditions: 
<ul>
<li>The user has the OPERATIONS attribute or the resource is within the scope of a group in which the user has the group-OPERATIONS attribute</li>
<li>The user’s user ID or any group name the user is connected to is in the access list with an authority not less than the user’s intended access</li>
</ul> 
</li>
</ul>

<p>Security Server provides two installation exits that a site can use during RACHECK processing, as well as a quicker form of 
authorization checking called FRACHECK, or fast path RACHECK processing. </p>

===Global access checking===

In addition to authorization checking, Security Server also provides global access checking. Global access checking allows a site to store a system-wide table of default authorization levels for selected resources. Security Server checks this table to determine if access to a resource is permitted. 

If access is permitted, Security Server bypasses further RACHECK processing. If the global access check fails, RACHECK processing continues. Frequently accessed resources with generalized access rules are good candidates for global access checking.

Global access checking handles resources in both the data set and the general resource classes, with the exception of group 
resource classes. 

Global access checking does the following: 

<ul>
<li>
Grants access, but does not, by itself, deny any request for access 
</li>

<li>
Does not allow logging of permitted access or gather statistics 
</li>

<li>
Does not offer a postprocessing installation exit 
</li>

<li>
Performs no I/O on the Security Server data set, thus offering a high-performance checking option 
</li>
</ul>

===Using profiles to protect resources===

<p>Security Server protects data sets (both DASD and tape) and general resources such as tape volumes and terminals. These 
resources are protected through profiles defined by the site. Authorized users can create, modify, list, and delete profiles using 
Security Server commands. </p>

<p>When the ADDSD statement is used to define and protect a data set, Security Server builds a data set profile and stores it in the Security Server data set. Profiles can be either generic or discrete depending on the nature of the resource. </p>
 
===Generic profile===

<p>A generic profile protects a single resource such as one data set, or a number of related resources; for example, those having similar naming structures, or the same access, authorization, and auditing requirements. </p>

<p>A generic profile contains a list of authorized users and the access authority of each user. A single generic profile can protect 
many data sets that have similar naming structures. Data sets protected by generic profiles need not be defined individually to 
Security Server, which saves the system manager from having to enter and maintain individual profiles. </p>
<p>Many users can protect all their data sets with a single generic profile consisting of their user ID and an asterisk: </p>
<p class="syntax"><span class="term">user_id</span>.* 
</p>

<p>This profile protects all the user’s data sets that begin with the user’s user ID, regardless of the number of qualifiers. </p>

===Discrete profile===

<p>A discrete profile protects resources that have specific or unique access authorization or logging requirements such as a single sensitive data set on a specified volume. </p>

<p>A discrete profile contains the same kind of information as a generic profile, but it protects only the one identified data set on the specified volume or volumes. </p>

<p>If the access authorization requirements are general, define a generic profile. If the data set has unique access authorization 
requirements, define a discrete profile. </p>

<p>Either type of profile can protect tape data sets as well as the following: </p>

<ul>
<li>
Cataloged and uncataloged non-VSAM data sets 
</li>

<li>
VSAM data sets 
</li>

<li>
Data sets with the same name residing on different volumes 
</li>

<li>
Generation data group (GDG) data sets 
</li>

<li>
Data sets and catalogs with single level names via a site-supplied prefix 
</li>
</ul>

<p>In Model 204, the Security Server Interface user privileges and other authorization items are defined as data set names and 
treated as system resources. Generic profiles control who can use those resources by permitting individual users to access them. 
These rules are written by the Model 204 system manager and the Security Server security administrator. </p>

==Running the Security Server Interface with Model 204==

<p>When running either as an Online or in batch mode, Model 204 checks Security Server for the system resources a user has 
permission to access. Model 204 manages the authorization process, because only Model 204 can identify the user requesting a 
resource. Model 204 asks Security Server to validate those requests and responds to users who have been denied requests for 
resources. </p>

<p>Model 204 interfaces with Security Server in the following distinct areas: </p>

<ul>
<li>
User logins 

<ul>
<li>LOGIN/LOGON command 
</li>

<li>IFSTRT function 
</li>

<li>IFLOG function 
</li>
</ul>

</li>

<li>User resource requests 

<ul>
<li>Dynamic allocation of new DASD space (ALLOCATE command) 
</li>

<li>Job submission (<var>USE $JOB</var> command) 
</li>

<li>Sequential data set handling (Record I/O) 
</li>

<li>VSAM data set handling (External I/O) 
</li>
</ul>
<p class="note"><b>Note:</b> Because Model 204 databases are not validated on behalf of the user by the security interface, Security Server must grant the owner of an address space permission to open Model 204 file data sets for update, regardless of whether the owner has write or read-only privileges.<br />
This permission allows Model 204 to write back updates to the FPL (File Parameter List) page, as required by the database management system, regardless of the Model 204 file open privileges.</p>
</li>

<li>User logouts

<ul>
<li>LOGOUT/LOGOFF command 
</li>

<li>IFFNSH/IFDTHRD function 
</li>
</ul>
</li>
</ul>

<p>The Security Server Interface uses the standard IBM-supplied calls to validate user requests for Model 204 resources. No source code modifications or exits to the Security Server software are needed. However, you can define an additional Security Server control group for nonshared resources as well as for resources shared between multiple copies of Model 204. </p>

==Using the Security Server Interface==
<p>
This section describes the changes that affect a Model 204 user. They include: </p>

<ul>
<li>LOGIN or LOGON </li>

<li>IFSTRT function </li>

<li>IFLOG function within IFAM1 </li>

<li>Dynamic allocation </li>

<li>Job submission </li>

<li>Sequential and VSAM data set handling </li>
</ul>

===LOGIN or LOGON command===
<p>
The [[LOGIN or LOGON command|LOGIN/LOGON]] command allows you to gain access to Model&nbsp;204. Once you are connected to Model&nbsp;204, and if the system manager has set Model&nbsp;204 to require logins, any commands you enter (other than <var>LOGIN</var> or <var>LOGON</var>) produce the following message: </p>

<p class="code">*** PLEASE LOGIN 
</p>

<p>To log in, enter: </p>

<p class="syntax">LOGIN <span class="term">userid</span> [<span class="term">account</span>] 
</p>

<p>or 
</p>

<p class="syntax">LOGON <span class="term">userid</span> [<span class="term">account</span>] 
</p>

<p>where: </p>
<table class="noBorder">
<tr>
<td><var class="term">userid</var></td> 
<td>Is a character string that identifies you.</td> </tr>

<tr><td><var class="term">account</var></td> 
<td>Is an optional character string that identifies the account under which you log in.</td> </tr>
</table>

===Using Pass Tickets===
<p>
Model 204 supports the use of Pass Tickets instead of passwords during the logon process under RACF. This support does not require new CCAIN parameters nor changes to existing parameters. However, RACF expects Pass Tickets to be generated using the user's ID concatenated with the APPLID (<var>[[VTAMNAME parameter|VTAMNAME]]</var>) of the target Online.</p>

===User ID information===
<p>
If Model 204 provides security authorization checks, as a Model 204 user you are assigned the following by the system manager: </p>

<ul>
<li>User ID that identifies you to Model&nbsp;204. </li>

<li>Password that provides access to the system. Note that Model&nbsp;204 versions 7.7 and later also support [[#Passphrases|passphrases]]. </li>

<li>User privileges associated with your user ID and password to define the particular type of access that you have. </li>

<li>Default priority class assigned to your user ID. </li>
</ul>

<p>When native Model&nbsp;204 security is in effect, this ID information is stored in a record in the system file CCASTAT. This record is deleted from CCASTAT when the system manager moves the user into Security Server security mode. 
The [[#Preparing a RACFPARM parameter module with RACFGEN|RACFPARM]] module supplies a default Logonid for CCASTAT Logonids to do validation requests on Security Server.</p>

===Security Server processing===
<p>
When Security Server performs login validation, the user ID must be eight characters or fewer (seven characters if jobs are 
submitted through the internal reader). Your user ID is verified by Security Server before you can log in to Model 204. </p>

<p>If your site chooses to perform Security Server account validation, any value entered in the account field is verified via Security Server services. When Security Server is performing account validation, the account is limited to a maximum length of eight characters. If you do not enter an account, the default account becomes your user ID. Refer to [[#Login processing|Login processing]] for more information on login processing. </p>
====Changing your password====
<p>If you have the appropriate authority, you can change your Security Server user ID password when you log in to Model 204. For more information, see the [[LOGIN or LOGON command]] page.</p>
====Passphrases====
If Security Server is configured to support passphrases, they can be used with Model 204 version 7.7 and later. Passphrases are 9-127 characters long and can contain any special characters (such as blanks, commas, and semicolons) supported by Security Server. See [[LOGIN or LOGON command#Setting a password|Setting a password]] for more information.

===IFSTRT function===
<p>
In the IFAM1 and IFAM4 environments, the IFSTRT function is used in a Host Language Interface program to allocate a Host 
Language Interface thread. IFSTRT also establishes the calling convention, performs a user login, and determines whether or not the thread has updating privileges. </p>

<p>When processing the login argument of the IFSTRT call, the user login process follows the rules for [[#User 0 login|User 0 login]].</p>

===IFLOG function within IFAM1===

<p>The IFLOG function is used only in the IFAM1 environment. It is called following IFSTRT to identify you when a login is required. 

This function is necessary in any IFAM1 program where user authorization is validated by Security Server. </p>

<p>As with the IFSTRT function, the user login process is the same as the process for [[#User 0 login|User 0 login]].</p>

===Dynamic allocation considerations===

<p>All dynamic allocation services in a Security Server environment are subject to Security Server system rules for data set 
validation. For example, data set allocation can be restricted to allow the creation of data sets with certain name patterns. The rules for data set access are determined by the Security Server security administrator. </p>

<p>To dynamically allocate a new data set, you must have Security Server ALTER authority. If you issue an ALLOCATE command 
and you do not have ALTER authority, you receive a Model 204 error message. </p>

<p>If you log in to Model 204 via CCASTAT, your allocation privileges are determined by the Security Server default user’s 
authorization. </p>

<p class="note"><b>Note:</b> When you open a new or existing sequential or a VSAM data set, it is validated for read/write access. Security Server does not perform open access authorization on Model 204 data sets, because these data sets are currently protected under Model 204 security. </p>

===Job submission considerations===

<p>When an Online user issues the <var>[[USE $PRINT / $PUNCH / $JOB command|USE $JOB]]</var> command to submit a batch job, Model 204 identifies the user so that Security 
Server can determine if the user has proper authorization. If the submitter is IFAM1, IFAM4, or User 0, no additional processing 
occurs; the submitted job inherits the privileges from the submitting job, because it has already been authorized to run by Security Server. </p>

<p>In a Model 204 system in which the Security Server Interface is running, the following JCL statement is appended automatically 
to the submitted job statement(s) to identify the Model 204 user: </p>

<p class="syntax">// USER=<span class="term">userid</span>,PASSWORD=<span class="term">password</span>,GROUP=<span class="term">groupname</span> 
</p>

<p>where: </p>
<table class="noBorder">
<tr>
<td><var class="term">userid</var></td> <td>Is the submitting user’s Security Server user ID, or the default user ID if the user is logged in through CCASTAT.</td> </tr>

<tr><td><var class="term">password</var></td> <td>Is the user password associated with the particular user ID, or the default password for the default user ID if the user is logged in through CCASTAT.</td> </tr>

<tr><td><var class="term">groupname</var></td> <td>Is the Security Server group to which the submitting user is assigned. This is the group identified in the user’s ACEE that is provided by Security Server during user login, or the default group if the user is logged in through CCASTAT.</td> </tr>
</table>

<p>The default user ID, password, and group information is defined in the Security Server Interface parameter module (RACFPARM) and cannot be modified by the user or controlled by the system manager. RACFPARM is described later in this section. </p>

<p>If Model 204 finds any of the Security Server control parameters listed previously while processing the submitted JOB, they are 
deleted from the JCL to prevent users from violating security. </p>

<p>An installation can request that Model 204 check for user authority to submit a job. Because Security Server does not have a 
facility to restrict job submission, Model 204 checks the generic profile for the comgroup.SUBMIT option. Comgroup.SUBMIT 
determines whether or not a user is permitted to submit JCL. For more information about comgroup.SUBMIT, refer to the [[#Preparing a RACFPARM parameter module with RACFGEN|RACFGEN macro]] discussion.
</p>

<p>If an unauthorized user attempts to submit a job, Model 204 issues an error message. </p>

<p>For users logged in via CCASTAT, the authority to submit jobs is determined by the default user’s authorization. </p>

====USE $JOB example====

With a <var>USE $JOB</var> procedure, jobs submitted by users known to CCASTAT are logged in as the default user (here, <code>M204USR</code>).

In this case, the user who submitted the Online job is <code>userX</code>, and the user executing the <var>$JOB</var>  is <code>userX2</code>:
<p class="code">14.21.44 J0763715 ---- FRIDAY,    19 FEB 2016 ----
14.21.44 J0763715  IRR010I  USERID M204USR  IS ASSIGNED TO THIS JOB.
14.21.44 J0763715  ICH70001I M204USR  LAST ACCESS AT 13:40:32 ON FRIDAY, FEBRUARY 19, 2016</p>
 
Jobs submitted by users known to RACF and unknown to CCASTAT are logged in under their own RACF profile.

In this case, the user who has submitted the Online job is <code>userY</code>, and the user executing the <var>$JOB</var>  is <code>userY2</code>:
<p class="code">14.35.10 J0763765 ---- FRIDAY,    19 FEB 2016 ----
14.35.10 J0763765  IRR010I  USERID userY2   IS ASSIGNED TO THIS JOB.
14.35.10 J0763765  ICH70001I userY2   LAST ACCESS AT 14:34:49 ON FRIDAY, FEBRUARY 19, 2016</p>

===Sequential and VSAM data set considerations===

<p>Security Server always performs an authorization check if you try to use a sequential or VSAM data set. To use a sequential or 
VSAM data set you must be a member of a control group (or optionally a common control group) that has: </p>

<ul>
<li>Security Server alter or update privileges to open a deferred update data set or to issue the DUMP or USE commands 
</li>

<li>Security Server alter authority to dynamically allocate a new sequential data set 
</li>

<li>Security Server read privileges to read sequential files from User Language or to read the file specified in a RESTORE command 
</li>

<li>Security Server read privileges to read external VSAM files from User Language. 
</li>
</ul>

<p>If you issue a sequential or VSAM data set OPEN command that fails for Security Server reasons, Model 204 issues an error 
message. </p>

<p>If you log in to Model 204 via CCASTAT, authorization is determined by the default user’s authorization limits. </p>

<p>Model 204 sequential file data sets (such as CCASTAT, CCAAUDIT, CCAJRNL, or CCAJLOG) are also checked to determine if the owner of the address space has the authority to write to them. </p>

<p>Security Server directly checks the following Model 204 commands: </p>
<ul>
<li>
[[DUMP command|DUMP]] and [[DUMPG command|DUMPG]]
</li>

<li>
[[RESTORE command|RESTORE]] and [[RESTOREG command|RESTOREG]]
</li>

<li>
[[USE_command:_Directing_output|USE OUT<i>XXXXX</i>]]
</li>

<li>
[[ALLOCATE command|ALLOCATE]] a new data set
</li>

<li>
OPEN DATASET 
</li>

<li>
[[OPEN FILE command|OPEN <i>filename</i>]] with deferred update
</li>
</ul>

==Login processing==

<p>The system manager is responsible for defining security processing in a Model 204 installation in which Security Server supplies authorization services. This section describes the login processing performed by the Security Server Interface. </p>

===Model 204 and Security Server login processing===

<p>When a user logs in to Model 204, Model 204 acquires the user ID and account and searches CCASTAT to determine whether or not the user ID exists.</p> 
<p>If the user ID is found, Model 204 queries the user for a password and proceeds with authorization processing. If the RACFPARM module indicates that CCASTAT defined users cannot log in, the login fails.</p> 
<p>If the user ID is not found in CCASTAT and Security Server security is in effect, Model 204 uses Security Server facilities to authorize the user login: </p>

<ul>
<li>Model 204 passes the login user ID and password to Security Server to verify that the user is a valid Security Server user and that the password is correct. 
</li>

<li>If the site has chosen to verify that the user is authorized to use Model 204, Security Server is asked if the user has PERMIT 
authority to access the generic profile for resource group.LOGIN. If this check is successful, account processing occurs. 
</li>

<li>If the installation has chosen to verify the account, the value entered is checked against the Security Server profile for 
comgroup.ACCOUNT.account. If the value entered has PERMIT authority, the user is allowed into Model 204. 
</li>
</ul>

<p>If Security Server denies system access because of an invalid password or account, or if the user is not authorized to use Model 204, no login occurs and Model 204 issues an error message. </p>

<p>Once users are successfully logged in, they are granted Model&nbsp;204 privileges of X'00'. Any additional privileges are determined whenever they enter a Model&nbsp;204 command that requires a specific privilege. </p>

<p>Users who do not log in directly to Security Server are automatically restricted in what they can do by the privileges associated with the default user ID. Refer to [[#Security Server default user ID|Security Server default user ID]] for more information.</p>

<p>All the system manager commands concerning CCASTAT maintenance functions work as usual. The ZBLDTAB and ZCTLTAB utilities also continue to work as usual. </p>

<p>File, group, and subsystem security functions are defined as described in the Model 204 documentation, particularly the [[Model 204 security features]] topic. </p>

===User 0 login===
<p>
When the Security Server Interface is active, User 0 is validated as the owner of the Model 204 run, regardless of whether the 
run is Online, BATCH204, IFAM1, or IFAM4. Model 204 always attempts to log in User 0 automatically, and verifies that any user ID supplied matches the user ID of the owner of the address space. It is not necessary to supply a user ID on the login command for User 0; Model 204 determines the owner user ID and supplies it automatically. </p>

<p>If a user ID is supplied on the login command and the user ID does not exist on CCASTAT, it must match the user ID of the owner of the address space or the login fails. If the user ID is found on CCASTAT and CCASTAT users are allowed to log in, all further authorization checking is based on a default user ID specified by the installation (if running as an APF-authorized program). </p>

<p>BATCH204 and IFAM4 can run without APF authorization if the user ID is equal to the ADDR SPACE ID and there is no default login ID (you cannot login from CCASTAT). If you try to log in without meeting these conditions, your login fails or a B78 System ABEND occurs. </p>

<p>Technical Support recommends that you do not specify a user ID in the login for User 0, so jobs can be easily migrated from test to production without having to change the login command. </p>

<p>Whether or not you supply a user ID, no password is needed and Model 204 does not prompt for one. If a password statement is coded in the input stream, it is treated as an invalid Model 204 command. If the user ID is on CCASTAT, Model 204 prompts for a password. If the password is correct, the login succeeds but all future data set authorization checking is based on the default user ID. </p>
 
===AUTHCTL VIEW command===
<p>
The <var>[[AUTHCTL command|AUTHCTL VIEW]]</var> command displays the interface control options currently in effect for the active interface. As of version 7.7 of Model&nbsp;204, the command also displays a list of all the <em>sets</em> of control options that are available to the interface (and potential values of the <var>[[#SECPLIST parameter|SECPLIST]]</var> parameter).
</p>
<p>
For example, if you enter either of these: </p>

<p class="code">AUTHCTL VIEW 
 
AUTHCTL VIEW RACF</p>
<p>
You see a list of interface options something like the following, which might be preceded by a list of available option sets, as described above. The Security Server ID and group name of the job owner might also be included: </p>

<p class="code">GROUP            M204TEST             <var class="term">Security Server control group name</var> 
COMGROUP         M204COM              <var class="term">Security Server common control group name</var> 
VALIDATE         LOGIN                <var class="term">Validation option in effect</var> 
VALIDATE         ACCOUNT              <var class="term">Validation option in effect</var> 
PRIORITY         LOW                  <var class="term">Priority default</var> 
DEFUSR           M204USR              <var class="term">Default user ID</var>
DEFGRP           M204GRP              <var class="term">Default user group</var>   
DLMCHECK                              <var class="term">Use $JOB DLM checking option</var> </p>
<p>
For more information about user defaults, refer to [[#Security Server default user ID|Security Server default user ID]]. For information about setting control information, see [[#Preparing a RACFPARM parameter module with RACFGEN|Preparing a RACFPARM parameter module with RACFGEN]]. </p>

===Using trusted login for CRAM users===
<p>
If your site uses [[Defining the user environment (CCAIN)#CRAM (IODEV=11, 23, 29)|CRAM]], you can use the trusted login feature, which allows users to issue login commands or calls that do not include a user ID and password.</p> 
<p>For a user to log in as trusted, the user ID must be defined to Security Server. User IDs defined to CCASTAT are not allowed to log in as trusted users. CICS users must be using the Security Server interface for CICS. Only CICS user IDs that log in through Security Server can log in as trusted users. </p>

<p>Trusted login can be used with the following CRAM thread IODEV types: </p>

<ul>
<li>IODEV11 (CRFSCHNL) 
</li>

<li>IODEV29 (CRIOCHNL) 
</li>

<li>IODEV23 (IFAMCHNL) 
</li>
</ul>

<p>To set up trusted login for a user, set the SECTRLOG user parameter, as discussed in [[#Setting up the SECTRLOG parameter for trusted login|Setting up the SECTRLOG parameter for trusted login]]. </p>

====Login processing for trusted login====

<p>For users connecting with a CRAM thread that allows trusted login, the user login processing routines are changed to handle a LOGIN command or IFSTRT call without a user ID and password: </p>
<ul>
<li><p>CRFS and CRIO channel threads handle User Language statements. These users ordinarily issue a LOGIN or LOGON request with the following format: </p>

<ul>
<li>version 7.6 and earlier:
<p class="syntax">LOGIN <span class="term">userid</span> [<span class="term">account</span>];<span class="term">password</span> [:<span class="term">new password</span>];<span class="term">apsyname</span> 
</p></li>
<li>version 7.7 and later:
<p class="syntax">LOGIN <span class="term">userid</span> [<span class="term">account</span>];<span class="term">password</span>;<span class="term">apsyname</span> 
</p></li>
</ul>
<p>For trusted logins, the format is: </p>

<p class="syntax">LOGIN;;<span class="term">apsyname</span></p>
</li>

<li><p>The IFAM channel threads handle IFAM2 statements. These users ordinarily issue an IFSTRT or IFSTRTN call with the following format: </p>

<p class="code">IFSTRT (RETCODE,LANG_IND,LOGIN,THRD_TYP,THRD_ID) </p>

<p class="code">IFSTRTN (RETCODE,LANG_IND,LOGIN,THRD_TYP,THRD_ID,CHAN) </p>

<p>The LOGIN parameter is required and supplies the user ID and password as a character string using the following format: </p>
<ul>
<li>version 7.6 and earlier:
<p class="syntax">‘<span class="term">userid</span> [<span class="term">account</span>];<span class="term">password</span> [:<span class="term">new password</span>];’ 
</p></li>
<li>version 7.7 and later:
<p class="syntax">‘<span class="term">userid</span> [<span class="term">account</span>];<span class="term">password</span>;’ 
</p></li>
</ul>

<p>For trusted logins, the statement format is the same but the login character string is a semicolon surrounded by single quotes (';'). </p>
</li>
</ul>

====Trusted login errors====

<p>When using trusted login, you might receive one of the errors described in this section. </p>
<ul>
<li>The following message: 
<p class="code">M204.2378: Security trusted login feature disabled </p>
<p>
is generated in either of the following situations: </p>
<ul>
<li>The Model 204 job requesting the trusted login feature is running without a Model&nbsp;204 Security Interface (CA-ACF2, Security Server, or CA-Top Secret). </li>

<li>Model 204 address space does not have enough storage to allocate an internal work area for the trusted login feature. 
<p>
In this 
situation, the Model&nbsp;204 job does not initialize because it still has to allocate storage for the Model&nbsp;204 file buffers. </p></li>
</ul>
</li>

<li>The following message is issued when the trusted user ID passed by [[Cross-memory facilities CRAM and M204XSVC|CRAM]] is not between 1-8 bytes long:
<p class="code">M204.2379: Invalid trusted user-id length=<span class="term">length</span> </p>
</li>
</ul>

==Maintaining the Security Server Interface==

<p>At each Security Server site, the security administrator performs system-wide maintenance functions within Security Server. The security administrator is responsible for defining and maintaining the Security Server generic profiles and permits for authorization that are eventually used by Model 204. The following discussions describe the Model 204 data maintained by the security administrator. </p>

<p>The privilege names that Model 204 uses are based on generic data set profiles. Although the Security Server ADDSD command describes a resource profile for Model 204, use it as if you are defining a data set. </p>

<p>This method provides the simplest way to describe resources. You do not need to reassemble any Security Server modules because all definition is external. In addition, it is portable across Security Server releases, because no internal modifications are made to Security Server tables and no Security Server exits are used. </p>

<p>In the following examples, the simplest set of conditions is described. You can fully utilize all Security Server options (for example, auditing when a resource is used, changing the universal access authority, or naming a specific owner of the group). Use security access levels for both the profiles and the permits for authorized users of those profiles. </p>

<p>The interface requires that users of these resources are permitted READ authority. </p>

===Defining user privileges===
<p>
You must identify user privilege names as Security Server generic data set profiles. The standard Model&nbsp;204 user privileges 
described earlier have been assigned fixed names. The following set of user privilege names defines the possible privilege types for a user. These names are further qualified by the control group name entered in the RACFPARM module. </p>
<p>
These user privilege profile names are described in the following table. See the [[LOGCTL command: Modifying user ID entries in the password table|LOGCTL]] command page for more information about <var>LOGCTL</var> settings. </p>

<table>
<caption>User privilege names</caption>

<tr class="head">
<th>User privilege name... </th>
<th>Defines a user who can... </th>
<th>LOGCTL setting </th>
</tr>

<tr>
<td><i>group</i>.PRIV.SUPER.USER </td>
<td>Exercise superuser privileges: a user with READ access to this profile can execute a <var>CREATE</var> command. </td>
<td>X'80' </td>
</tr>

<tr>
<td><i>group</i>.PRIV.SYSTEM.ADMIN</td>
<td>Exercise system administrator privileges: a user with read access to this profile can issue system administrator commands such as <var>LOGWHO</var>, <var>MONITOR</var>, <var>PRIORITY</var>, and <var>WARN</var>. </td>
<td>X’40’ </td>
</tr>

<tr>
<td><i>group</i>.PRIV.CHANGE.FILE.PASSWORD</td>
<td>Change the file password that is used to open a file: valid only if the file entry is stored in CCASTAT. </td>
<td>X'20' </td>
</tr>

<tr>
<td><i>group</i>.PRIV.SYSTEM.MANAGER </td>
<td>With system manager privileges: a user with read access to this profile can issue all system administrator commands along with certain other privileged commands such as <var>LOGCTL</var>, <var>AUTHCTL VIEW</var>, and <var>DUMPG</var>. </td>
<td>X'08' </td>
</tr>

<tr>
<td nowrap><i>group</i>.PRIV.OVERRIDE.RECORD.SECURITY </td>
<td>Override record security. </td>
<td>X'04' </td>
</tr>
</table>

===Defining corresponding generic profiles===
<p>
Security Server generic data set profiles must be developed and defined to Security Server to correspond to the defined 
privileges. The Security Server generic data set profiles used to define the standard Model 204 privileges and other resources to 
Security Server in a batch TSO execution are as follows: </p>

<p class="code"><nowiki>//JOBNAME      JOB (other information)..... 
//DOIT         EXEC PGM=IKJEFT01,DYNAMNBR=20 
//SYSTSPRT     DD SYSOUT=A 
//SYSTSIN      DD * </nowiki>
ADDGROUP       group DATA('MODEL204 Security Server CONTROL GROUP NAME') 
ADDSD          'group.PRIV.SUPER.USER*'                UACC(NONE) GENERIC 
ADDSD          'group.PRIV.SYSTEM.ADMIN*'              UACC(NONE) GENERIC 
ADDSD          'group.PRIV.CHANGE.FILE.PASSWORD.*'     UACC(NONE) GENERIC 
ADDSD          'group.PRIV.SYSTEM.MANAGER*'            UACC(NONE) GENERIC 
ADDSD          'group.PRIV.OVERRIDE.RECORD.SECURITY.*' UACC(NONE) GENERIC 
ADDSD          'group.LOGIN*'                          UACC(NONE) GENERIC 

ADDGROUP       comgroup DATA('MODEL204 Security Server COMMON GROUP NAME') 
ADDSD          'comgroup.SUBMIT*'                      UACC(NONE) GENERIC 
ADDSD          'comgroup.PRIORITY.HIGH*'               UACC(NONE) GENERIC 
ADDSD          'comgroup.PRIORITY.STANDARD.*'          UACC(NONE) GENERIC 
ADDSD          'comgroup.PRIORITY.LOW*'                UACC(NONE) GENERIC 
ADDSD          'comgroup.ACCOUNT.<var class="term">nnnnnnnn</var>.*'           UACC(NONE) GENERIC 
</p>

<p class="note"><b>Note:</b>  <var class="term">nnnnnnnn</var> represents an account number; there are as many as required. Also, high-level qualifiers cannot exceed eight (8) characters. </p>

<p>In the following two sample PERMIT statements, the first is for a system manager and the second is for login authorization to a 
copy of Model 204: </p>

<p class="code">PERMIT      '<I>group</I>.PRIV.SYSTEM.MANAGER*'    ACCESS(READ) ID(user ID1,user ID2.....)

PERMIT      '<I>group</I>.LOGIN*'    ACCESS(READ) ID(<I>user ID1,user ID2</I>.....) 
</p>
<p>
Where: </p>
<table class="noBorder">
<tr><td><var class="term">group</var>.PRIV.<var class="term">privilege</var></td> <td>Specifies one of the fixed types that Model&nbsp;204 uses to build Security Server retrieval search keys for the rules </tr>

<tr><td><var class="term">group</var></td> <td>Is the Security Server control group defined to Model&nbsp;204</td></tr>
</table>

<p>
The previous Security Server PERMIT statement sample permits the specified users to access the named resource. Rules for determining the authorized user are described in the [http://www-03.ibm.com/systems/z/os/zos/features/racf/library/library.html IBM Security Server documentation].</p>
<p>
The privilege rules are tested whenever a user issues a command that requires a specific privilege. If the user is authorized to have that privilege, the command succeeds. If not, the user typically receives a Model&nbsp;204 error message and the attempt might be logged as an Security Server violation. </p>

==Installing the Security Server Interface==
<p>
The Model 204 interface to Security Server consists of the following components: </p>

<ul>
<li>Code in Model 204 that utilizes Security Server facilities </li>

<li>Security Server group and generic data set profile definitions defined at your site </li>

<li>SECPLIST User 0 parameter in CCAIN </li>
</ul>

<p>The user site requirements that must be met in order to activate the Security Server Interface are identified in this section. </p>

===Terminal security considerations===
<p>
Security Server can enforce terminal security when a user logs in. At that time, the source of the login is passed to Security 
Server. For systems running Model 204 with the SNA Communications Server (formerly VTAM) interface, this poses no problem 
because Model&nbsp;204 recognizes the terminal name and stores it for use. </p>

<p>Configurations using CRAM (TSFS, CICS, IFDIAL) must use the CRAM channel name instead of the terminal ID as the user 
source, because there is no secured mechanism in CRAM for identifying the source of the user. Because CRAM channel names 
can be identified as valid sources, the user IDs allowed to use those sources can be validated. Using the CRAM channel name 
temporarily ensures that entry to Model 204 is from an approved source. </p>
 
===SECPLIST parameter===
<p>
The <var>[[SECPLIST parameter|SECPLIST]]</var> User&nbsp;0 parameter in CCAIN lets you specify the name of the RACFGEN argument set with which to initialize the interface. The name is defined by the assembler label name of the RACFGEN macro. </p>
<ul>
<li>If the <var>SECPLIST</var> parameter is not in CCAIN, <code>RACFPARM</code> is used as the default name of the argument set. </li>

<li>If no match is found for the <var>SECPLIST</var> name or the <code>RACFPARM</code> default name in the RACFPARM module, the interface is initialized using the precoded default parameters defined in the Security Server Interface. In this case, Login, Account, and Priority validation are not performed. </li>
</ul>

<p>
The following RACFPARM module contains two sets of Security Server arguments: </p>
<ul>
<li>In the first set, the name is <code>LOG1</code>, and account security is in effect. If the user is logged on through CCASTAT, the default Logonid is <code>M204USR</code>.</li>

<li>In the second set, the name is <code>LOG2</code>, and both account and login security are in effect. In addition, if the user is logged on through CCASTAT, the Logonid of the executing job is considered the default Logonid. </li>
</ul>

<p class="code">       TITLE 'RACFPARM MODULE'            X 
LOG1   RACFGEN GROUP=M204PROD,            X
              COMGRUP=M204RACF,           X
              PRTY=H,                     X
              VALIDAT=ACCOUNT,            X
              DEFUSER=M204USR,            X
              DEFUGRP=,                   X
              DEFPASS=,                   X
              DMLCHECK 
LOG2  RACFGEN GROUP=M204TEST,             X
              COMGRUP=M204RACF,           X
              PRTY=S,                     X
              VALIDAT=(ACCOUNT,LOGIN),    X
              DEFUSER=JOBNAME,            X
              DEFUGRP=M204GRP,            X
              DEFPASS=DEFPASS,            X
              DMLCHECK
          RACFGEN TYPE=END
          END 
</p>

===Preparing a RACFPARM parameter module with RACFGEN===
<p>
The RACFGEN macro generates a set of arguments that govern login and other security processes. There can be multiple 
argument sets in a RACFPARM module. The RACFPARM parameter module can be linked with Model&nbsp;204 or dynamically loaded 
when the Security Server Interface is initialized.</p>

<p>The arguments for the RACFGEN macro are described in detail in this section. </p>

<p>The following is a sample RACFGEN macro with one set of arguments. The name of the argument set is RACFPARM, which is 
the required name if you are linking statically into your Model&nbsp;204 modules. </p>

<p class="code">TITLE 'GENERATE A Security Server PARAMETER MODULE' 

RACFPARM RACFGEN GROUP=M204RACF,    Control group          X  
   COMGRUP=M204RACF,                Common control group   X              
   PRTY=S,                          Priority               X 
   VALIDAT=,                        Validation items       X  
   DEFUSER=M204USR,                 Default user ID        X  
   DEFUGRP=M204GRP,                 Default user group     X  
   DEFPASS=M204PASS,                Default user password  X 
   DLMCHECK/NODLMCHECK              Check DLM= 
RACFGEN TYPE=END  
END 
</p>

<p>
Where: </p>
<table>
<tr><td>RACFPARM</td>
<td>Defines the name of this set of Security Server arguments. Because there can be any number of argument sets in the RACFPARM module, each set must be given a unique name. There is no default name.

<p class="note"><b>Note:</b> If you want to statically link the RACFPARM module, you must include (as the first argument) a Security Server argument set named RACFPARM. Otherwise, the <var>SECPLST</var> value for the user is not found in the RACFPARM module, and the interface is initialized using the precoded default parameters defined in the Security Server Interface. In this case, Login, Account, and Priority validation are not performed. This may result in the user being unable to login. </p>
</td></tr>

<tr><td>GROUP</td>
<td>Specifies the 1- to 8-character Security Server control group name selected by your site. The rules for Model 204 privileges are defined and grouped by this code and stored in Security Server profiles. The group name must match the generic profile high-level qualifier defined to Security Server in the ADDSD statements for the profiles, all of which take the form of <var class="term">group.keyword.variable.data</var>. 
<p>
The default is <code>M204RACF</code>. </p>
<p>
You can use the <code>GROUP</code> name to create a separate set of privilege definitions for an individual copy of Model&nbsp;204. This allows 
your site to have different privileges for different versions of Model&nbsp;204, for instance for test and production. </p></td></tr>

<tr><td>COMGRUP</td>
<td>Specifies the 1- to 8-character Security Server common group name selected by your site. The rules for the VALIDAT ACCOUNT, PRIORITY, and SUBMIT options are defined and grouped by this code and stored in Security Server profiles.
<p>
The common group name must match the generic profile high-level qualifier defined to Security Server in the ADDSD statements for the profiles, all of which take the form of <var class="term">comgroup.keyword.variable.data</var>. </p>
<p>
The default is <var>M204RACF</var>, if a group name is not specified. </p>

<p class="note"><b>Note:</b> COMGRUP is used to create a common set of privilege definitions shared between copies of Model&nbsp;204. </p>
</td></tr>

<tr><td>PRTY</td>
<td>Specifies the default priority for any user who successfully logs in through Security Server. Options are H (high), S (standard), L (low), or N (none). The default priority is STANDARD if the PRTY keyword is omitted. For more information about priorities, refer to [[Controlling system operations (CCAIN)#Priority scheduling|Priority scheduling]]. </td></tr>

<tr><td>VALIDAT</td>
<td>Specifies the type of validation to be performed. Multiple validation types can be specified for the interface; 
e.g. VALIDAT=(ACCOUNT,LOGIN,PRIORITY,SUBMIT) 
<p>
Options are: </p>
<ul>
<li>ACCOUNT specifies that Security Server validates any account entered by the user during the login process. VALIDAT ACCOUNT verifies that Security Server permits the account value entered by the user. If so, the user is allowed in to Model&nbsp;204. If not, the login fails. 
<p>
This validation uses the comgroup.ACCOUNT.account# profile. </p></li>

<li>LOGIN specifies that Security Server rules are tested to determine if a user is allowed to log in to Model&nbsp;204. If VALIDAT LOGIN is specified, the Security Server Interface determines if the user is permitted to use Model&nbsp;204 before allowing access. If LOGIN is not specified, all users who pass the user ID/password and optional account validation are allowed access to Model&nbsp;204. 

<p>This validation is performed using the profile <code>group.LOGIN</code>, so it can be used to limit the ability to log in when several copies of Model 204 are running.</p> </li>

<li>PRIORITY verifies which priority the user is permitted to have. This option can be specified in addition to a standard priority. If priority validation fails, the standard priority is the default. 
<p>
This validation uses the profiles:</p> 
<p class="code">comgroup.PRIORITY.HIGH 
comgroup.PRIORITY.STANDARD 
comgroup.PRIORITY.LOW 
comgroup.PRIORITY.NONE</p> 
<p>
Validation is checked from highest to lowest priority. If a user has PERMIT access to one of these priorities, the value is assigned. If no PERMIT is found and a standard priority is not specified, the priority for the user is set to STANDARD. </p></li>

<li>SUBMIT uses Security Server rules to determine whether or not a user is allowed to issue the USE command to submit a job through the internal reader. If this option is specified, Security Server checks the user’s authorization privileges before allowing the user to submit the job. If this option is not specified, all users who pass the user ID/password and optional account validation are allowed to submit jobs.
<p>
This validation uses the <code>comgroup.SUBMIT</code> profile. </p></li>
</ul></td></tr>

<tr><td>DEFUSER</td>
<td>Defines the default submitting user’s Security Server user ID if the user is not directly logged in through Security Server. Refer to [[#Job submission considerations|Job submission considerations]] for a description of how the Security Server user ID is used when submitting jobs.
<ul>
<li>If DEFUSER=, that is, this field is left blank, then CCASTAT-defined users are not allowed to log into Model 204. Only valid Security Server users can utilize the running system. </li>

<li>If DEFUSER=<var class="term">JOBNAME</var>, then the following occurs. The ASID ACEE is moved to DEFUSER, the GROUP ACEE is moved to DEFGROUP, and the default user’s ACEE pointer is set to AUCKDPTR. In other words, the user ID associated with the submitted job is used as DEFUSER and users defined in CCASTAT are allowed to log on.</li>
</ul></td></tr>

<tr><td>DEFUGRP</td>
<td>Defines the default Security Server group to which a submitting user is assigned if the user is not directly logged in 
through Security Server. Refer to [[#Job submission considerations|Job submission considerations]] for a description of how the Security Server group is used when submitting jobs. </td></tr>

<tr><td>DEFPASS</td>
<td>Defines the default PASSWORD for the default user ID if the user is not directly logged in through Security Server. Refer to [[#Job submission considerations|Job submission considerations]] for a description of how the Security Server password is used when submitting jobs. </td></tr>

<tr><td>DLMCHECK/NODLMCHECK</td>
<td>Specifies DLM processing options for jobs submitted through the internal reader using the USE command. The DLM parameter on a DD * or DD DATA statement allows a job to be submitted that can itself submit other jobs. This is a potential security compromise. The DLMCHECK/NODLMCHECK argument provides the ability to enforce certain rules when coding the DLM= parameter. 
<p>
DLM processing options are as follows: </p>
<ul>
<li>DLMCHECK enforces the rule that if a DLM= parameter is used in a JCL stream, it must be the only parameter supplied. In this case, only the following forms of these statements are correct:

<p class="code">//DDNAME DD *,DLM=';;' </p>

<p>
Or: </p>

<p class="code">//DDNAME DD DATA,DLM='&amp;&amp;&amp;&amp;' </p>

<p>In these statements, the DLM value follows the rules described in [http://www.ibm.com IBM] JCL documentation; any other parameters supplied result in an error. If there is a job statement following the offending statement, Model 204 appends the following to the job statement set as if it is an independent job: </p>

<p class="code">USER=...,PASSWORD=...GROUP=... </p></li>

<li>NODLMCHECK checks only the validity of the DLM= parameter and not the other optional parameters that can be specified on the JCL statement. All JCL statements after the DLM= parameter are sent to the internal reader without being checked. This argument does not guarantee that an error on the statement with the DLM= parameter is caught before it is submitted. 
<p>
DLMCHECK is the default. </p></li>
</ul>
</td></tr>
</table>

<p>The result from assembling the RACFGEN macro is link-edited to a library that is included in a Model&nbsp;204 link-edit, or it can be optionally linked into a separate library and loaded at execution time. </p>

<p>If you link RACFPARM as a separate load module, use the SECRLINK job in the JCL library. Modify the job according to the comments. </p>

<p>If you link RACFPARM with the Model&nbsp;204 configuration, add the following line in SYSLIN for the link-edit steps of ONLINE, BATCH204, IFAM1, and IFAM4. </p>

<p class="code">INCLUDE OBJLIB(RACFPARM) </p>

===Model 204 link-editing requirements===
<p>
To support multiple Model&nbsp;204 logins for different user IDs, Model 204 must be linked to an authorized library using the 
appropriate Security Server services. This means that any Online configuration must be linked to an authorized library. </p>

<p>BATCH204 or IFAM can be linked to a nonauthorized library, provided that the user logging in is the same user who starts the job and there is not a default login ID that prevents CCASTAT logins. Otherwise, the login fails or a System B7A ABEND occurs. </p>
 
===Defining Model 204 to Security Server===
<p>
Model 204 allows multiple users per address space and provides services to many users through its own processing, but Security Server is aware only of the maintask in the address space (in this instance, Model 204). Model 204 must be defined as having the appropriate Security Server privileges to perform services on behalf of a Model 204 control group. </p>

<p>You can define an additional Security Server control group for nonshared resources as well as for resources shared between 
multiple copies of Model&nbsp;204.The first step in the definition process is to choose a name and define a profile for the Model&nbsp;204 
control group and optionally the common group. For example: </p>

<p class="code">ADDGROUP M204RACF OWNER(SECURITY) DATA('MODEL 204 CONTROL GROUP') 
ADDGROUP M204COM OWNER(SECURITY) DATA('MODEL 204 COMMON CONTROL GROUP') 
</p>
 
===Defining Model 204 users in Security Server===
<p>
In Security Server, the user profile record contains all information for a defined user of a computer system. There are no special entries or any differences in the way a Security Server user is defined to the system. All authorization services are performed using the generic profiles for privileges. See [[#Defining corresponding generic profiles|Defining corresponding generic profiles]] for more information.
</p>
 
===Security Server default user ID===
<p>
The default user ID limits the authorization of users that have not logged in directly to Security Server (that is, users still defined in CCASTAT). </p>

<p>Each user not logged directly into Security Server is assigned the authorization provided by Security Server for the default user ID. The authorization includes all user resource requests, as described in [[#Running the Security Server Interface with Model 204|Running the Security Server Interface with Model 204]].</p>

<p>The default user ID automatically is assigned the user ID <code>M204USR</code> with the password <code>M204PASS</code> and belongs to group 
<code>M204GRP</code>. A user ID of this name must be defined to Security Server for CCASTAT-defined users to be able to log in. </p>

<p>For security reasons, the system manager cannot modify this group, user ID, and password. If different data is required or if the installation would like to change defaults, the parameter module RACFPARM must be modified by the Security Server security 
administrator or systems programmer. </p>

<p>RACFPARM provides the mechanism to supply overrides to the default group, user ID, and password. This module can be made available during the Model 204 link-edit. Otherwise, Model&nbsp;204 attempts to load it at the time the interface is initialized. If the module is loaded dynamically, it must be made available in the STEPLIB containing Model&nbsp;204 or in a system load library. The RACFPARM module is generated with the RACFGEN macro. </p>

<p class="note"><b>Note:</b> All LOADLIBs concatenated in one STEPLIB must be APF-authorized or you lose your APF authorization for that job step. </p>
 
===Setting up the SECTRLOG parameter for trusted login===
<p>
The <var>[[SECTRLOG parameter|SECTRLOG]]</var> user parameter defines which CRAM thread applications are allowed to log in to Model&nbsp;204 with a trusted user ID. The CRAM threads for which trusted login applications are allowed are: </p>
<ul>
<li>IODEV11 (CRFSCHNL) </li>

<li>IODEV29 (CRIOCHNL) </li>

<li>IODEV23 (IFAMCHNL) </li>
</ul>
<p>
<var>SECTRLOG</var> must be set on the first <var>IODEV</var> line for each trusted CRAM thread, because it is picked up during the initialization of each CRAM channel.</p> 
<p>
The following settings are valid: </p>

<table>
<tr class="head"> 
<th>Setting</th> <th>Meaning</th></tr>

<tr><td>X'00'</td> 
<td>Trusted Login not allowed (default)</td> </tr>

<tr><td>X'01'</td> 
<td>CICS applications (CRFS, CRIO, IFAM)</td> </tr>

<tr><td>X'02'</td> 
<td>TSO applications (CRIO, CRFS)</td> </tr>

<tr><td>X'04'</td> 
<td>Batch applications (CRIO, IFAM)</td> </tr>
</table>

===Conversion tasks and considerations===
<p>
The following table identifies the general tasks that must be completed to install and activate the Security Server Interface. Before conversion, you also might want to review the RACFPARM module definitions and link a separate copy of Model 204 for testing and production. </p>

<table>
<caption>Conversion checklist for Security Server </caption>
<tr class="head"><th>Step</th> <th>Task</th></tr>

<tr><td>1.</td> 
<td>Define a Security Server GROUP control profile for Model 204.</td> 
</tr>

<tr><td>2.</td> 
<td>Define a Security Server GROUP common profile for Model 204. </td>
</tr>

<tr><td>3.</td> 
<td>Define Security Server generic profiles for user privileges, and specify the users who have PERMIT access to have those privileges. </td>
</tr>

<tr><td>4.</td> 
<td>Define Security Server generic profiles for: 
<ul>
<li>Model 204 login authority related to the control group if the VALIDAT LOGIN option is specified in the RACFPARM</li>

<li>Authorized account code profiles related to the common group if the VALIDAT ACCOUNT option is specified in the RACFPARM</li>

<li>Authorized PRIORITY profiles if the VALIDAT PRIORITY option is specified to assign individual priorities to users and specify which users have PERMIT access for those privileges</li>
</ul></td>
</tr>

<tr><td>5.</td> 
<td>Run RACFGEN to assemble the RACFPARM module.</td> 
</tr>

<tr><td>6.</td> 
<td>Link RACFOS into Model&nbsp;204.</td>
</tr>

<tr><td>7.</td> 
<td>Link RACFPARM$ into Model&nbsp;204 directly, or use SECRLINK to create a separate LOAD module to be used for dynamic linking at initialization.</td>
</tr>

<tr><td>8.</td> 
<td>Add a new parameter in the User&nbsp;0 input stream called <code>SECPLIST=<i>parametername</i></code>. </td>
</tr>

<tr><td>9.</td> 
<td>Delete Model&nbsp;204 users from CCASTAT to turn on Security Server authorization checking.</td>
</tr>
</table>

==See also==
<ul>
<li>[[Security interfaces overview]]</li>
</ul>

[[Category:Security interfaces]]