SMUto RACF
SMUto RACF
Overview
IMS Version 9 will be the last release of IMS to support SMU Version 9 introduces new RACF* facilities
4 All SMU usage can now be replaced with RACF security 4 This presentation: Considers the SMU facilities that previously had no directly corresponding RACF facilities Explains the corresponding RACF options in Version 9
Terminal Security
4 User v. physical terminal
Transaction Security
4 User v. Trancode
Command Security
4 User v. IMS Command in Control Region 4 User v. IMS Command in Operations Manager
Benefits
4 Overcomes limitations that previously prevented migration from SMU
Page 4
Since this is the last release that will support SMU security, the release is considered a migration release where customers can migrate off of SMU secur ity and to RACF (or equivalent product). With the additional enhancements provided in IMS V9 over those provided in previous releases, the use of SMU security should no longer be required.
Page 5
Predominantly used for BMPs, but actually applies for all dependent regions and connecting threads (DRA/CCTL/ODBA)
Page 6
Page 7
* If LTERMs are included in AGN for a message driven region, then use of the region will be limited to LTERMs in the group
Page 8
BMP Example
Relies on AGN= being coded in JCL
BMP1 Dependent Region
1B
2B
RACF
AGNX -MPP1 AGN2 -IFP1
1A
Start up JCL IMSID=IMSA, USER=BMP1, PASSWORD=PW, AGN=AGN1, RACF . IDENTIFY/CONNECT . . . SCHED PAYROLL
1C
USER1 MPP1 IFP1 IMSP1
AGN1 -BMP1
Check
BMP 1
2A
RACF
AIMS profiles and access lists
ACEEs
SMU Check
An alternative to the use of RACF is the use of the DFSISIS0 exit renamed to AGN Security Exit (one or the other is called, not both)
Page 9
This visual describes the use of SMU and AGN as a review to better understand the changes in IMS V9. Note that systems migrating to IMS V9 can continue to use this process until a migration to RACF or equivalent product can be completed. In a SMU and AGN environment, the checking process is a two-step process. The first check involves RACF. The second does not. 1. Each dependent region has a userid associated with it. Befo re a dependent region can connect to IMS, IMS performs a RACF authorization check to see whether the dependent region userid can use the application group name specified in it's AGN= startup parameter. IMS performs this check using the RACF class name (AIMS) and the name of the AGN passed to it in the EXEC statement parameter list. If the region's userid is not PERMITted to use the application group name, RACF returns a "not authorized" return code, and IMS does not allow the dependent region to connect. If RACF returns an "authorized" return code, the connection is made. 2. The second part of the two-step process is an IMS function only. IMS checks the name of the transaction or PSB or logical terminal that is being requested by the dependent region against the entries in the AGN Table and allows or disallows use depending on whether the name is in the entry for the application group name. For message processing regions and fast path regions, application resource security is somewhat like class scheduling in that transactions can be scheduled only in regions whose application group name allows them.
4 Uses existing RACF security classes for Transactions TIMS: Transaction (TRAN) GIMS: Grouping class for Transactions
Page 10
In IMS V9, the two-step process described on the previous visual is now a direct check of the userid authorization against the specific resource. To accomplish this and ensure that the new RAS capability in IMS V9 provides equiva lent protection, four new security classes for PSBs and LTERMs have been added. The four new RACF security classes will be added to the RACF product as default classes. If your environment does not have the level of RACF that includes the new classes as defaults then they must be added to the installation-defined class descriptor table. Macro ICHERCDE is used to define a new class. The procedure for adding classes to this table is described in "Adding Installation-Defined Classes" in the z/OS Security Server RACF System Programmer's Guide. This is the same procedure that is used to change the default class names, e.g., TIMS to Txxx where xxx is more meaningful to a specific environment. The existing TIMS and GIMS classes continue to be used to protect transactions and groupings of transactions. APSB security using the existing AIMS security class will also continue to be done as in prior releases. The AIMS class will only be used for APSB security when SMU with AGN security is not selected for use.
Page 11
The new support in IMS V9 is called Resource Access Security. It is no longer called AGN. RACF, a new user exit, or both are used to provide protection. Either AGN security, or the new RAS security can be used, but not both. If both are specified, then RAS is used. Resource Access Security is requested by using the system definition SECURITY macro with TYPE=RASRACF|RASEXIT|RAS|NORAS or by specifying the execution parameter ISIS=N|R|C|A. In both cases, the new values are provided in addition to the values that are already supported. ISIS continues to be used for AGN and RAS security specifications. The parameters for AGN and RAS are unique, and can therefore correctly define the type of security desired. If ISIS=N is specified, there will be no authorization checking for the use of transactions, PSBs, and LTERMs by dependent regions. SMU will not be used either, because ISIS=1 or 2 must be specified (if the SECURITY macro has no specification) for SMU to be used for AGN. If ISIS is not specified, the default is the specification on the TYPE parameter of the IMS system definition SECURITY macro. The new values for the ISIS parameter are documented in the visual. The values that already existed include: ISIS=0 deactivates AGN security . ISIS=1 activates AGN security using SMU and RACF. ISIS=2 activates AGN security using SMU and the Resource Access Security Exit Routine (DFSISIS0).
A new user exit interface called the Resource Access Security exit routine (DFSRAS00) provides authorization of IMS resources to IMS dependent regions. Although this exit replaces the use of the DFSISIS0 exit routine in a RAS environment, it is not quite a direct replacement. DFSISIS0 was called to authorize a user to an AGN name. The AGN table with that AGN name contained the IMS resources that were indirectly authorized for use. The new IMS V9 exit DFSRAS00 is called after calling the SAF interface (RACF or equivalent product) to directly authorize the user to the actual IMS resources (transaction, PSB, and/or output LTERM name). The SAF call and user exit call are made based upon the specification of the parameters on the system definition SECURITY macro and/or the startup parameter ISIS=. This new user exit is available for the DB/DC, DCCTL, and DBCTL environments. Neither this new exit nor DFSISIS0 supports Callable Services.
IMS will never use both checks for the same schedule! ODBA APSB call
4 Exec parameter ODBASE=Y means use APSB security 4 With ODBASE=N, RAS (or AGN) security will apply (if enabled)
Page 13
OLD
AGN definitions : )( AGN IMSDGRP AGPSB DEBS AGPSB APOL1 AGTRAN TRANA AGTRAN TRANB AGLTERM IMSUS02 AGLTERM T3270LD
RACF definitions (userid to AGN group): ADDUSER BMPUSER1 RDEFINE AIMS IMSDGRP OWNER(IMSADMIN) UACC(NONE) PERMIT IMSDGRP CLASS(AIMS) ID(BMPUSER1) ACCESS(READ) SETROPTS CLASSACT(AIMS)
NEW
RACF definitions: ADDUSER BMPUSER1 RDEFINE JIMS RASPGRP ADDMEM(DEBS,APOL1 UACC(NONE) ) PERMIT RASPGRP CLASS( JIMS) ID(BMPUSER1) ACCESS(READ) RDEFINE GIMS RASTGRP ADDMEM(TRANA,TRANB) UACC(NONE) PERMIT RASTGRP CLASS( GIMS) ID(BMPUSER1 ACCESS(READ) ) RDEFINE MIMS RASLGRP ADDMEM(IMSUS02,T3270LD) UACC(NONE) PERMIT RASLGRP CLASS( MIMS) ID(BMPUSER1) ACCESS(READ)
Page 14
The next three visuals provide examples of converting from the use of SMU to RACF security.
OLD
AGN definitions :
NEW
RACF definitions:
ADDUSER DRAINBMP RDEFINE JIMS ** UACC(NONE) PERMIT ** CLASS(JIMS) ID(DRAINBMP) ACCESS(READ) RDEFINE TIMS ** UACC(NONE) PERMIT ** CLASS(TIMS) ID(DRAINBMP) ACCESS(READ)
Page 15
Permit region ids to access appropriate resources Change SECURITY macro to specify RAS and/or Change ISIS= parameter in DFSPBxxx to specify RAS If needed, add ODBASE=Y to DFSPBxxx Restart IMS When safe, remove SMU definitions
IMS V9 SMU Security Replacement Page 16
AOI Security
Page 17
Page 18
Prior to IMS V9, commands issued by Type 1 AO programs were secured using SMU transaction command security profiles. AO programs were restricted to issuing only the commands defined in the SMU profiles. When the Type 1 AOI CMD call was issued, IMS performed the security checking using the tables/matrixes loaded during restart. On the other hand, commands issued by Type 2 AO programs were secured using command profiles stored in the RACF CIMS Class. Type 2 programs were also optionally secured using a user exit routine (DFSCCMD0) which could perform command authorization independently or in conjunction with RACF. When security checking was required for command keywords, the exit provided a way to implement more granular levels of command security. IMS V9 provides several enhancements in this area. Type1 AOI CMD calls are now secured using the RACF interface in a fashion similar to that which was already provided for the Type 2 ICMD calls. Additionally, a new parameter on the TRANSACT macro provides a greater level of granularity that can make the RACF security check closer to that which was provided for SMU.
If you make no changes when migrating to IMS V9, AOI security will be as before
IMS V9 SMU Security Replacement Page 19
IMS V9 provides several enhancements in this area. Type1 AOI CMD calls are now secured using the RACF interface in a fashion similar to that which was already provided for the Type 2 ICMD calls. Additionally, a new parameter on the TRANSACT macro provides a greater level of granularity that can make the RACF security check closer to that which was provided for SMU.
4AOI1= N | C | R | A | S
for Type 1 commands only
- AOIS is parameter for Type 2 commands
Defaults to system definition specification (= SMU) on SECURITY macro (as in previous releases)
Can be overriden by /NRE or /ERE ... TRANCMDS | NOTRANCMDS
Use SMU
IMS V9 SMU Security Replacement
Use none
Page 20
The ICMD call of type 2 AOI (DFSAOE00) already uses the SAF interface and the Command Authorization exit (DFSCCMD0) for security. The CMD call of type 1 AOI (DFSAOUE0), as mentioned on the previous visual, used SMU security in prior releases. In IMS V9, this has been enhanced to provide the option of using SAF (RACF or equivalent product) and the DFSCCMD0 user exit. A new startup parameter in IMS V9, AOI1=A|N|C|R|S can be specified to indicate which security product is to be used for authorization of commands for type 1 AOI, and the level of security. If no value is specified, then IMS uses the specification in the SECURITY macro as defined in the system definition process. Because the AOI1 specification is not included in a checkpoint record, the AOI1 value can be changed each time IMS is initialized. During an IMS restart, the /NRE or /ERE can specify a value of either TRANCMDS or NOTRANCMDS. This only applies to TYPE 1 AOI security. If ne ither value is specified on a restart then IMS uses the AOI1 startup specification or what has been defined in the SECURITY macro. A specification of TRANCMDS causes SMU to be used for Type 1 AOI security and overrides TRANCMD=N in system definition and AOI1 in startup. NOTRANCMDS results in no TYPE 1 AOI security, unless prevented by the specificaiton of TRANCMD=F during system definiton and a further override by AOI1=R|C|A|N.
4AOIS= N | C | R | A | S
Same values as with AOI1 but some values (N and S) have different meanings
N = ICMD Calls are Not allowed C = DFSCCMD0 is called for command authorization R = RACF is called for command authorization A = Includes options C and R. RACF is called first, then DFSCCMD0 S = Skip no authorisation checking
Defaults to N
Page 21
The ICMD call of type 2 AOI (DFSAOE00) already uses the SAF interface and the Command Authorization exit (DFSCCMD0) for security. The CMD call of type 1 AOI (DFSAOUE0), as mentioned on the previous visual, used SMU security in prior releases. In IMS V9, this has been enhanced to provide the option of using SAF (RACF or equivalent product) and the DFSCCMD0 user exit. A new startup parameter in IMS V9, AOI1=A|N|C|R|S can be specified to indicate which security product is to be used for authorization of commands for type 1 AOI, and the level of security. If no value is specified, then IMS uses the specification in the SECURITY macro as defined in the system definition process. Because the AOI1 specification is not included in a checkpoint record, the AOI1 value can be changed each time IMS is initialized. During an IMS restart, the /NRE or /ERE can specify a value of either TRANCMDS or NOTRANCMDS. This only applies to TYPE 1 AOI security. If ne ither value is specified on a restart then IMS uses the AOI1 startup specification or what has been defined in the SECURITY macro. A specification of TRANCMDS causes SMU to be used for Type 1 AOI security and overrides TRANCMD=N in system definition and AOI1 in startup. NOTRANCMDS results in no TYPE 1 AOI security, unless prevented by the specificaiton of TRANCMD=F during system definiton and a further override by AOI1=R|C|A|N.
TRAN = Requests that the TRANCODE be used as the userid for authorization against the Command (in CIMS class) transactions have to be defined to RACF as USERIDs CMD = Requests that the COMMAND CODE (first three characters of the command) be authorised against Trancode (in TIMS class) the first three characters of IMS commands have to be defined to RACF as USERIDs
NO
= AOI Type 1 CMD calls are not allowed Not relevant for AOI Type 2 ICMD calls - same as YES
For Type 1 commands, AOI1=N|S (None or SMU) will override TRANSACT AOI=YES|NO
IMS V9 SMU Security Replacement Page 22
The TRANSACT macro has a new parameter, AOI=YES|NO|TRAN|CMD which specifies whether or not a particular transaction is allowed to issue the AOI command (CMD) call. In prior releases, this information was derived during IMS restart from the SMU matrix tables. When AOI=YES is specified, the authorization of the commands for the CMD calls issued by the transaction is done using the userid of the user who entered the transaction. For some environments, if a Get Unique call has not yet happened, then the program name rather than the userid is used for the authorization. When AOI=NO is specified, no authorization is permitted. Type 1 AOI CMD calls can not be issued. The TRAN specification is similar to that of YES, but requests that the transaction code, be used instead of the userid of the user who entered the transaction. Use of the transaction code provides authorization checking more like that provided by the SMU transaction-command security. When a transaction is defined with AOI=TRAN, the first authorization check done for AOI for the transaction results in the security environment (ACEE) being built and being kept for use by future authorization checks. In this case, the Type 1 AOI transactions have to be defined to RACF (or equivalent product) as a user. The transactions must also be specified on RACF PERMIT statements for each command they are allowed to issue from a Type 1 AOI transaction. The CMD specification is also similar to that of YES, but requests that the command code (first three characters of the command), be used instead of the userid for the authorization check. Use of the command code provides authorization checking more like that provided by the SMU transactioncommand security. When a transaction is defined with AOI=CMD, the first authorization check done results in the security environment (ACEE) being built, and being kept for use by future authorization checks. In this case, the IMS command codes (first three characters of IMS commands) have to be defined to RACF (or equivalent product) as a user. The command codes must also be specified on RACF PERMIT statements for each Type 1 AOI transaction that is allowed to issue them. Note that for Type 1 CMD commands, the AOI1= value of None or SMU will take precedence over a TRANSACT AOI value of Yes or No
NEW
ADDGROUP AOCMDS ADDUSER STO DFLTGRP( AOCMDS) ADDUSER STA DFLTGRP( AOCMDS)
RDEFINE TIMS AUTOCTL UACC(NONE) PERMIT AUTOCTL CLASS(TIMS) ID( AOCMDS) ACCESS(READ) ADDUSER AUTOTRAN ADDUSER ADDINV
RDEFINE CIMS STO UACC(NONE) PERMIT STO CLASS( CIMS) ID(AUTOTRAN, ADDINV) ACCESS(READ)
Final override
4 /NRE or /ERE ... TRANCMDS | NOTRANCMDS
Use SMU Use none
Page 24
The support of the new parameter AOI on the TRANSACT macro is dependent on the specification of the new startup parameter AOI1: If AOI1=S, SMU is used and the AOI settings defined during system definition in the TRANSACT macro are ignored. If AOI1=R|C|A, SMU for AOI is ignored, RACF and/or DFSCCMD0 are used for authorization and the settings defined during system definition in the TRANSACT macro are honored. If AOI1=N, No authorization checking is done and the settings in the TRANSACT macro are ignored. The final override for Type 1 AOI security, as mentioned earlier, is specified through the /NRE or /ERE specification of TRANCMDS or NOTRANCMDS. Although this was documented previously, the explanations is repeated here for clarification. This only applies to TYPE 1 AOI security. If ne ither TRANCMDS or NOTRANCMDS is specified on a restart , IMS uses the AOI1 startup specification or what was defined in the SECURITY macro. A specification of TRANCMDS causes SMU to be used for Type 1 AOI security and overrides TRANCMD=N in system definition and AOI1 in startup. NOTRANCMDS results in no TYPE 1 AOI security, unless prevented by the specificaiton of TRANCMD=F dur ing system definiton and a further override by AOI1=R|C|A|N.
Change (or add) AOI1=R to DFSPBxxx Restart IMS When safe, remove SMU definitions
Page 25
Page 26
Security support
4 Authorization of loading of TCO script by an LTERM performed only by DFSTCNT0 exit 4 Resource authorization Commands and Transaction security using SMU Transaction security (only) using RACF
- Command security could be requested but is not performed
Page 27
Time Controlled Operations (TCO) is an IMS capability to execute time- initiated commands and transactions. TCO can generate any IMS input that an IMS operator can, except for the IMS restart commands, /NRESTART and /ERESTART. Additionally, it cannot initiate conversational transactions, full- function response mode or Fast Path input transactions. The scripts used by TCO to execute the time- initiated commands, transactions, and message switches are stored in IMS.TCFSLIB. This is the time controlled facility's script library. A new script can be loaded by a program, a user exit or by a Load command from an LTERM (isues message switch, DFSTCF LOAD script-name TCO support provides security at two different levels. One capability restricts which LTERMs can load TCO scripts. The other restricts which IMS commands or transactions can be accessed.
Resource Security
4 Command and Transaction security with SMU Last release of IMS to provide this 4 Command and Transaction security with RACF
Page 28
DFSCCMD0 will also be called if it exists (after SMU check) for command security
Page 29
In prior release, IMS commands and transactions issued by TCO had the choice of using either SMU or RACF for authorizaiton. The use of SMU security for TCO command and transaction authorization in prior releases was predicated on defining the TCO LTERM names DFSTCF and DFSTCFI in the SMU definitions. More specifically, the SMU definitions were used to define which resources could be issued by a TCO script running under this LTERM name. On the other hand, when the IMS startup parameter RCF was specified, SMU authorization was not used. If the script issued a /SIGN ON command, the associated userid was available to be used in RACF calls to authorize access to transactions.
Requires a USERID
4 TCO script specification of /SIGN ON tcousid tcopw
Should also issue /SIGN OFF at end of script
or for ! CF s! n RA and ma No mm o co
Page 30
In prior release, IMS commands and transactions issued by TCO had the choice of using either SMU or RACF for authorizaiton. The use of SMU security for TCO command and transaction authorization in prior releases was predicated on defining the TCO LTERM names DFSTCF and DFSTCFI in the SMU definitions. More specifically, the SMU definitions were used to define which resources could be issued by a TCO script running under this LTERM name. On the other hand, when the IMS startup parameter RCF was specified, SMU authorization was not used. If the script issued a /SIGN ON command, the associated userid was available to be used in RACF calls to authorize access to transactions.
In IMS V9, a new execution parameter, TCORACF=, is used to indicate whether (Y) or not (N) the RACF interface should be called to perform an authorization check of commands from a TCO script. The value can be changed each time IMS is initialized. Therefore, specification of RCF has additional criteria. Only if both the IMS startup parameter RCF=A|S|R|B and TCORACF=Y are specified, is the RACF interface invoked to call RACF or an equivalent product. The Command Authorization Exit Routine (DFSCCMD0), if it exists, will also be called. Coding a /SIGN ON command at the beginning of the TCO script can provide the userid which will be used for authorization. The userid defined in the /SIGN ON is signed on to IMS and not signed off until a /SIGN OFF at the end of the script. Any commands after the /SIGN ON are checked by RACF for being authorized for use by the signed on user. The commands are also passed to the DFSCCMD0 exit. DFSCCMD0 can check the input CNTNAME to see if the input is from TCO (DFSTCFI), and if it is, allow the /SIGN command without checking the userid. For other commands, the exit can authorize the signed on user to enter that particular command. A note on providing a userid/group in the /SIGN ON at the beginning of a script: The userid/group provided must have been previously been defined to RACF. If it has not, RACF returns a RC=4. As a result of the RC=4, IMS issues a FASTAUTH using the IMS CTL region's ACEE. If the CTL region's userid/group is authorized to the command then the TCO script can also access the command. If the CTL region's userid is not authorized to the command then an RC=8 is issued to deny access.
NEW
ADDUSER TCOUSID DFLTGRP(IMS) OWNER(IMS) PASSWORD(SCRIPTS) PERMIT STA CLASS(CIMS) ID(TCOUSID) ACCESS(READ) PERMIT STO CLASS(CIMS) ID(TCOUSID) ACCESS(READ) PERMIT STATTRN CLASS(TIMS) ID(TCOUSID) ACCESS(READ)
This example assumes: Command and transaction profiles already exist The TCO userid (TCOUSID) is connected to a RACF group The TCO script issues a /SIGN ON for TCOUSID RCF= and TCORACF=Y are specified
The above definitions could have been coded in prior releases. If so, authorization for the transaction was done. Command authorization, however, was never invoked. In IMS V9 (TCORACF=Y), using the same definitions, RACF will be invoked for command authorization.
Page 32
The example assumes that RACF security profiles already exist fo r the START and STOP commands and for the STATTRN transaction. The TCO userid, TCOUSID, is added to the access lists for each of the commands and for the transaction. Although this definitions could be provided in prior releases, it is not until IMS V9 that IMS will invoke the CIMS profile to authorize access for a TCO script.
Define TCO userid and permissions in RACF Add /SIGN ON (and /SIGN OFF) to all TCO scripts Add TCORACF=Y to DFSPBxxx Restart IMS When safe, remove SMU definitions
Page 33
Page 34
Note that Directed and Non Nondirected routing use different userids for security
Normal transaction security using MSName as the LTERMname 4 Note: security checking may also have already taken place in the inputting IMS (terminal security or CHNG call security)
*
Directed Routing is when application explicitly specifies target location Not necessarily defined in IMS GEN
Page 35
MSC directed routing is a function of IMS that allows for the routing of messages to other IMS systems without the target resources having to be defined as remote resources in the sending IMS. This capability relies on the application, in the sending IMS, to specify the logical link path (MSNAME) as the destination of the message. Additionaly, the sending application provides the actual target LTERM or transaction name in the first few bytes of the IOAREA. When the message is received at the destination, the LTERM or trancode is removed from the message by the link receive entry point of the DFSMSCE0 exit and the message enqueued for the proper destination. Non-directed routing, on the other hand, relied on all target destinations in the remote IMS to be defined as remote resources on the sending system. For releases prior to IMS V9 where MSC link input to transaction destinations used directed routing, SAF(RACF) and the DFSCTRN0 user exit were called before and after the DFSMSCE0 user exit call. Otherwise, for non-Directed Routing, SMU security was called after the DFSMSCE0 call.
IMSA
SMU Check
System Authorization Facility
TRANY
RACF
DATA SPACE
USER1
TRANY
USER2
MPP
SMU TABLES
ACEEs USER1 IMSA1
ISRT TRANZ
RACF DB
Directed Routing
MSC LINKS
USER2
SMU
APPLCTN PSB=APPLX TRANSACT CODE= TRANX
RACF
APPLCTN PSB=APPLY TRANSACT CODE= TRANZ
RACF DATA SPACE
IMSB
IMSC
SMU TABLES
USER1 IMSP1
RACF DB
SMU TABLES
RACF DB
USER2
Page 36
This visual shows MSC link receive security as it exists today. Note that this does not address the other points of security for MSC which are already adressed by RACF interfaces. On the left side of the page, the example shows non-directed routing. In this environment, remote destinations are defined in the front-end IMS. When the message is received in the back-end system, SMU definitions are used to determine whether a transaction can be accessed using the MSNAME associated with the MSC link. For directed routing, RACF calls along with an optional call to DFSCTRN0 are made before and after calls to DFSMSCE0. DFSMSCE0 is the exit routine that contains the entry point for the Link Receive code.
Page 37
For IMS V9, a new startup parameter defines the type of security required for MSC. In the DFSDCxxx proclib member, the new parameter is MSCSEC=(parm1,parm2).
RACF / DFSCTRN0 called once , after DFSMSCE0 The USERID to be used is defined by MSCSEC parm2 or DFSMSCE0 Exit
IMS V9 SMU Security Replacement Page 38
SMU security can still be invoked when non-directed routing is used and MSCSEC=LRNONDR is not specified. There will be no longer be calls to RACF and the DFSCTRN0 user exit prior to calling the DFSMSCE0 user exit during Link Receive processing. DFSMSCE0 can set the level of authorization checking. Calls to RACF and DFSCTRN0 are made after DFSMSCE0.
Note: with RACF, security environment for control region or MSNAME is built once when first used, and retained. But security environment for an end user is built and deleted for each message.
IMS V9 SMU Security Replacement Page 39
The security authorization options that can be returned by the DFSMSCE0 user exit in field MSLRFL3 are also provided as a startup option. These new options are specified as the second value in the MSCSEC= keyword in the DFSDCxxx proclib member.
Page 40
Additional data will be passed to the DFSMSCE0 user exit including: userid, group name, and userid indicator. The userid indicator clarifies the value in the userid field as being one of: Userid, LTERM name, PSB name, MSNAME, or Other. The DFSMSCE0 user exit call during Link Receive processing has the ability to control the level of authorization checking. The user exit response in field MSLRFL3 specifies the level of authorization as one of: Authorization by MSNAME where the ACEE is dynamically created for the first authorization, then reused. Authorization by CTL address space security. Authorization by userid of inputting terminal where the ACEE is dynamically created and deleted for each authorization. Authorization by user exit DFSCTRN0. No security authorization checking.
Decide what type of userid to use for directed and non-directed routing
4 Easier when both the same, but can be different
Update RACF to include new userids (MSNAMEs and Ctl Rgn) if necessary, and grant their access to transactions If using two types of userid, code DFSMSCE0 accordingly Change DFSDCxxx to include
4 MSCSEC=(LRALL,USER |MSN |CTL)
Page 42
4Note: these passwords can not be used with ETO terminals (ETO and SMU are incompatible)
or
Page 43
The /LOCK and /UNLOCK LTERM|DATABASE|PROGRAM|TRANSACTION| NODE|PTERM commands also support specification of password security for the defined resource. In prior releases, this was accomplished with the use of SMU. If the resource was not defined with password protection in SMU, the check was not made and the password ignored. Password protections was by the specification of the PASSWD= parameter on the SECURITY macro along with the appropriate SMU definitions. There were, however, certain restrictions: The /LOCK DATABASE, /LOCK PROGRAM, and /LOCK TRANSACTION commands are only valid when entered from: a master terminal or system console; TCO script; or AO program. The /LOCK TRANSACTION command cannot be used for CPI-C driven programs. The /LOCK LTERM, /LOCK NODE, and /LOCK PTERM commands apply only to the entering physical terminal.
Senior operators can LOCK and UNLOCK DBs, programs and transactions
4 Only they know the passwords to do this (when using SMU)
In IMS V9 with RACF, these special people are explicitly authorised to LOCK, UNLOCK and SET specific resources
Page 44
Page 45
In IMS V9, the security of the LTERM, DATABASE, PROGRAM, and TRANSACTION parameters include the use of SAF (RACF) and/or the Transaction Authorization Exit, DFSCTRN0. The resources are defined to RACF in the classes: LIMS, PIMS, IIMS, and TIMS respectively. Because this RACF and exit call were not made in prior releases, the call cannot be made unconditiona lly beginning in IMS V9. Therefore, a new startup option LOCKSEC=Y|N (where N is the default) has been added to the DFSDCxxx IMS.PROCLIB member. If LOCKSEC=Y is specified, the new RACF and user exit calls are made after the optional call to SMU security. If the resource is not defined to RACF, or is defined and is authorized to the user, the command is processed. If the resource is defined to RACF but is not authorized for use, the command is rejected with a new message DFS3689W. DFS3689W USE OF resourcename BY LOCK/UNLOCK REJECTED Explanation: The transaction, LTERM, database, or program resource entered as a parameter on the /LOCK or /UNLOCK command is not authorized for use by the user entering the command. No RACF call made for /LOCK and /UNLOCK NODE | PTERM. Protection of VTAM nodes and BTAM terminals relies on the use of RACF TERMINAL|GTERMINAL support
Grant authority for using these resources to the appropriate userids Add LOCKSEC=Y to DFSDCxxx Restart IMS When safe, remove SMU definitions Inform users that passwords are no longer needed
Page 46
Page 47
or
STERM ALL
4Requires SECURITY SECLVL=SIGNON or FORCSIGN 4 and typically requests RACF verification of userid/password with SECURITY TYPE=RACFTERM
IMS V9 SMU Security Replacement Page 48
In previous releases, statically defined terminals were only required to signon if the terminal was defined in SMU as being required to do so. This was done with the )(SIGN control statement. SMU, however, was limited to supporting: - a maximum of 65535 LTERM definitions - a maximum of 32767 different patterns for sets of commands and transactions (a pattern is unique set of commands and/or transactions that can be issued by terminals) - a maximum of 32767 terminals to require sign-on
If a TERMINAL has both a SMU specification (i.e. sign-on required) and a conflicting OPTIONS=NOSIGNON, then SMU takes precedence
Page 49
In IMS V9, a new initialization parameter, SIGNON, is provided in the DFSDCxxx proclib member to request that static terminals be required to signon. The format and the options for SIGNON are: SIGNON=ALL | SPECIFIC. Specification of ALL requests that all static terminals be required to signon. This is equivalent to the SMU definition of )(SIGN STERM ALL. Note that like the SMU support, SIGNON=ALL will not set sign on required in LU6.1, 3284/3286, SLU1 (when printer-only device), and master terminal devices. The use of SPECIFIC defines that individual static terminals may be required to signon. These terminals will be specified in either system definition with the OPTIONS=SIGNON parameter on the TYPE and/or TERMINAL macros, or via SMU definitions with the )(SIGN statements.
Page 50
Other Considerations
Page 51
LTERM Security
SMU
1. Controls static LTERM availability through password security: /LOCK and /UNLOCK LTERM (pswd) 2. Protects which static LTERMs can be used in NMD BMP and JBP specification of OUT= AGN definitions
SAF / RACF
1. Checks the userid authorization to the resource using: the new resource class LIMS when LOCKSEC=Y 2. Uses RAS security based on SECURITY macro TYPE= RASRACF|RASEXIT|RAS|NORAS or override value of ISIS=N|R|C|A Checks userid associated with NMD BMP or JBP for authorization to the LTERM using the new LIMS class 3. Uses the REVERIFY facilities in IMS and RACF by specifying RVFY=Y in IMS and 'REVERIFY' in the APPLDATA section of the RACF profile for the commands and transactions to be protected Requires a signed on user to reenter his/her signon password with the transaction or command input
3. Provides additional protection for signed on static terminals: requires the user to enter the SMU defined password that is associated with the transaction or command
Page 52
The next two visuals show the considerations when migrating LTERM-based security from the use of SMU to the use of SAF/RACF. The first three areas show specific SAF/RACF solutions to assist in LTERM migration considerations.
LTERM Security
SMU
4. Restricts entry of certain commands to specific static LTERMs SMU definitions e.g., )( COMMAND DIS TERMINAL LTERMA )( TERMINAL LTERM5 COMMAND DIS TRANSACT TRAN
SAF / RACF
4. Restricts entry based on a combination of RACF and DFSCCMD0. The first check is the RACF call to validate if the userid can enter the command. If DFSCCMD0 exists, it is always invoked and can make the second call. Possible alternatives: Create FACILITY class RACF profiles of command.lterm, e.g., DIS.LTERMA. These would equate to the combinations defined in SMU. In DFSCCMD0, call RACF to authorize userid/groupid to the resource class using the applicable resource combinations. Or, protect all the static LTERMs with the new LIMS resource class. Define the commands (there are about 50) as userids. In the exit, invoke RACF to VERIFY the IMS command (build the ACEE) as a userid, and authorize it against the LTERM name. 5. Similar techniques as described above for restricting commands. DFSCTRN0 is used instead of DFSCCMD0
5. Restricts entry of certain transactions to specific static LTERMs SMU definitions e.g., )(TRANSACT PAYROLL TERMINAL LTERMB
IMS V9 SMU Security Replacement
Page 53
These two areas are a little more complex since there is no direct RACF equivalent . To migrate LTERM-based command security, consider using RACF in conjunction with the Command Authorization Exit Routine (DFSCCMD0). Normal RACF command authorization checking based on userid/group may be used. If it exists, the Command Authorization Exit DFSCCMD0 is always invoked after RACF for commands entered from IMS terminals. The sample DFSCCMD0 exit is coded to determine if a terminal is ETO or STATIC. If DFSCCMD0 determines that the command is from a static terminal, rather than accept the command, the exit could be changed to reinvoke RACF to do one of the following: - check a special user-defined RACF profile. For example, the exit could obtain the name of the static LTERM used to enter the command and construct a RACF profile name from a combination of the command verb and inputting LTERM name. Finally, the exit could invoke RACF to determine if the userid/group is authorized to the command/LTERM profile. - invoke the command as a userid. This alternative approach would be to RACF protect all the static LTERMS that were defined in SMU using the new RACF LIMS resource class. Additionally, since there are only about 50 commands, they could be defined to RACF as userids. DFSCCMD0 could then verify (build the ACEE) for the IMS command as a userid and authorize it against the LTERM name. Similar techniques as those described above for restricting commands could be used for restricting transactions. The difference would be that the Transaction Authorization Exit (DFSCTRN0) would be used instead of DFSCCMD0. Note, however, that DFSCTRN0 is not called for any further security checking if the userid is not authorized to the transaction. As with the command examples, you could also do all of the following to accomplish the same thing: - Protect all of the static LTERMs in the new LIMS resource class provided by IMS V9 - Define the affected IMS transactions as RACF userids - Use RACF's VLF ACEE cache so the transaction ACEEs are always in storage (eliminates I/O to the RACF DB) - Invoke RACF to VERIFY (build the ACEE) for the IMS transaction name as userid if one did not already exist
Migration Considerations
AOI considerations
4 CMD has new status code and new return/reason (AIB) codes 4 ICMD has new return/reason codes
Log record (type X 10) has new error codes New and changed Exits
4 DFSRAS00, DFSCCMD0, DFSISIS0, DFSMSCE0
Summary
Prior to IMS V9, there are six security functions that are only possible with SMU
4 They can still be implemented with SMU in IMS V9 4 But this will not be so in the follow-on release of IMS IMS V9 is last release to support SMU
IMS V9 introduces new facilities that enable these six security functions to be implemented with RACF (or equivalent product)
4 Also adds some new security functions
Recommend: all users of SMU should install IMS Version 9 and then migrate all SMU functions to RACF while on this release
Page 55