Re: How To Handle RACROUTE logic
On Mon, 27 Jun 2022 10:20:43 -0500, Mike Cairns wrote: >One important difference you might need to be aware of is between a normal >RACROUTE call that executes under the authority of the current user associated >with the running address space (a First Party call - i.e. checking your own >current access rights), and the special case known as Third Party RACROUTE >call where you also give the userid on the call and it's not necessarily the >same userid as you are executing under at the time. For this, you need first >to create a new RACF ACEE and pass this to the RACROUTE call - IIRC this >*requires* you to have APF Authorisation (actually, Supervisor State, however >you get that, but most commonly this means you are APF'd), IOW you won't be >doing this from a normal user address space. More correctly, Mike, to create an ACEE or specify a userid on the AUTH call (which tells RACF to create an ACEE for that user) you need to be authorized: any of APF, supervisor state, or system key will work. Another caveat: If this is happening in CICS, the code should be using CICS services, not RACROUTE, to do any checking. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How To Handle RACROUTE logic
You don't need to concern yourself with *how* the user is (or is not) given access to the resource. You don't need to concern yourself with which RACF profile protects the resource either. You just pass the necessary information about the user, the access level being requested and the resource name to the RACROUTE call and RACF determines the answer for you. This answer might be because the user is permitted directly on the access list of the profile covering the resource, or one (or more) of the groups they are a member of is on the access list, or the resource might grant access via the Universal Access attribute, or the user might have some other ability such as Operations, or even a RACF exit might get into the equation and contribute to the answer your RACROUTE call gets back. It's all 'under the covers'. In general, it's a bad idea to try and second guess RACF by assuming that some named Group or other structure is used specifically to make access decisions - poor design choice (made all too often by folks who don't really understand RACF). One important difference you might need to be aware of is between a normal RACROUTE call that executes under the authority of the current user associated with the running address space (a First Party call - i.e. checking your own current access rights), and the special case known as Third Party RACROUTE call where you also give the userid on the call and it's not necessarily the same userid as you are executing under at the time. For this, you need first to create a new RACF ACEE and pass this to the RACROUTE call - IIRC this *requires* you to have APF Authorisation (actually, Supervisor State, however you get that, but most commonly this means you are APF'd), IOW you won't be doing this from a normal user address space. HTH - Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How To Handle RACROUTE logic
> One routine issues RACROUTE REQUEST=FASTAUTH, and the other issues RACROUTE > REQUEST=AUTH. It is relatively uncommon to need to use FASTAUTH. Be sure that you are using it when appropriate and are aware of its restrictions. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] How To Handle RACROUTE logic
Hi Paul, No extra checking is needed. You give RACF the userID and resource you want checked and it handles the rest. RACF has a well-documented flowchart it goes through, where it checks the userID first and if that doesn't grant specific access, it moves to the groups the user is a member of and if nothing there, it checks the UACC of the resource. No need to do separate checking. The only thing you may want to verify is that you have " LIST OF GROUPS ACCESS CHECKING" active. That is the option that tells RACF to check all the groups the user is in as opposed to just the current connect group. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of esst...@juno.com Sent: Thursday, June 23, 2022 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] How To Handle RACROUTE logic Hello, . I'm not a RACF person. . I'm developing two routines to check a userids authority to access a resource in a RACF Facility Class. . One routine issues RACROUTE REQUEST=FATSAUTH, and the other issues RACROUTE REQUEST=AUTH. Both requests work well when checking for an individual user. . The User Id may or may not be part of a Group that has access to a Facility Class Resource. .. How should both functions approach this, without knowing if the user belongs to a RACF group ? Should I examine the ACEE First, to see if the User Id is part of a Group ? Do I need to issue two RAROUTE calls in each routine one for a single userid and a second for the userids group ? Can I issue the RACROUTE for a single user regardless if the user id belongs to a group or not ? . I would prefer to issue a single RACROUTE call in each routine. . I need help understanding this. . What is the recommended approach ? . paul. .. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How To Handle RACROUTE logic
Hi, I don't think you should do extra checking. If the user is a member of a group and is not explicitly defined to access a specific profile, but the group he belongs is allowed to access it, then RACROUTE should succeed. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em quinta-feira, 23 de junho de 2022 12:55:44 BRT, esst...@juno.com escreveu: Hello, . I'm not a RACF person. . I'm developing two routines to check a userids authority to access a resource in a RACF Facility Class. . One routine issues RACROUTE REQUEST=FATSAUTH, and the other issues RACROUTE REQUEST=AUTH. Both requests work well when checking for an individual user. . The User Id may or may not be part of a Group that has access to a Facility Class Resource. .. How should both functions approach this, without knowing if the user belongs to a RACF group ? Should I examine the ACEE First, to see if the User Id is part of a Group ? Do I need to issue two RAROUTE calls in each routine one for a single userid and a second for the userids group ? Can I issue the RACROUTE for a single user regardless if the user id belongs to a group or not ? . I would prefer to issue a single RACROUTE call in each routine. . I need help understanding this. . What is the recommended approach ? . paul. .. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How To Handle RACROUTE logic
Hello, . I'm not a RACF person. . I'm developing two routines to check a userids authority to access a resource in a RACF Facility Class. . One routine issues RACROUTE REQUEST=FATSAUTH, and the other issues RACROUTE REQUEST=AUTH. Both requests work well when checking for an individual user. . The User Id may or may not be part of a Group that has access to a Facility Class Resource. .. How should both functions approach this, without knowing if the user belongs to a RACF group ? Should I examine the ACEE First, to see if the User Id is part of a Group ? Do I need to issue two RAROUTE calls in each routine one for a single userid and a second for the userids group ? Can I issue the RACROUTE for a single user regardless if the user id belongs to a group or not ? . I would prefer to issue a single RACROUTE call in each routine. . I need help understanding this. . What is the recommended approach ? . paul. .. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
