I should have been more specific with the macro parameters. Below are the
full macros being used, which include the ACEE parameter. If there is a
non-authorized way to perform a check with supplied credentials, that would
be an excellent solution.
RACROUTE REQUEST=VERIFY,
ENVIR=CREATE,
ACEE=ADDRACEE,
USERID=USER_INFO,
PASSWRD=PASS_INFO,
MSGRTRN=YES,
MSGSUPP=YES,
LOG=ASIS,
STAT=ASIS,
RELEASE=7707,
WORKA=RACWORK,
MF=(E,ACEE_C_S)
One or more AUTH checks being made
RACROUTE REQUEST=AUTH,
ACEE=(R3),
ATTR=(R2),
CLASS=RESCLASS,
ENTITYX=EntName,
LOG=ASIS,
MSGRTRN=YES,
MSGSUPP=YES,
RELEASE=7707,
WORKA=RACWORK,
MF=(E,RACAUTH_S)
RACROUTE REQUEST=VERIFY,
ENVIR=DELETE,
ACEE=ADDRACEE,
RELEASE=7707,
WORKA=RACWORK,
MF=(E,ACEE_D_S)
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Rob Scott
Sent: Friday, April 22, 2011 4:23 AM
To: [email protected]
Subject: Re: Mixing Auth and Non-Auth Modules
RACROUTE REQUEST=AUTH only needs to be called from an authorized environment
when using certain (less common) keywords.
Which keyword is being used that makes authorization required?
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: [email protected]
Web: www.rocketsoftware.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Rob Schramm
Sent: 21 April 2011 22:01
To: [email protected]
Subject: Re: Mixing Auth and Non-Auth Modules
Maybe some others are willing to comment...
I thought that there was a short-cut to take for auth checking these days..
if you didn't really need to keep the ACEE around and you just want to do a
quick check to see if someone is auth'd for something. Perhaps it was a
dream or a wish. Anyone?
Rob Schramm
On Thu, Apr 21, 2011 at 4:40 PM, McKown, John <[email protected]
> wrote:
> > -----Original Message-----
> > From: IBM Mainframe Discussion List
> > [mailto:[email protected]] On Behalf Of Patrick Roehl
> > Sent: Thursday, April 21, 2011 2:57 PM
> > To: [email protected]
> > Subject: Mixing Auth and Non-Auth Modules
> >
> > I have a situation where APF-authorization is needed by a new
> > subprogram
> > that performs RACF functions. This was working fine until it
> > came time to call
> > the new subprogram from the main program, which does not need to be
> > authorized. Making the whole process authorized seems silly
> > (or worse), in
> > addition to being inconvenient as there are many STEPLIB
> > entries involved.
> >
> > I tried running the main program from an authorized LNKLST
> > library, but quickly
> > ran into S306-12 when trying to load a program from the STEPLIB.
> >
> > Is the best option to handle this setting up a separate
> > region to handle the
> > authorized calls and communicating via a PC? It looks like a
> > PC client would
> > have to be authorized, which defeats the purpose.
> >
> > How has this been solved in the past?
> >
> > Thanks for any suggestions and/or examples.
>
> APF is generally an "all or nothing" affair. z/OS, and MVS before it, was
> not designed to swap between APF and non-APF authorized states. You can do
> the APF to non-APF switch relatively easily. But it is generally a one way
> street. TSO does it by having two TCB trees. TSO starts up APF authorized,
> but resets the APF when the TMP does an ATTACH. But before that it creates
> an APF authorized subtree. When you run an APF authorized TSO program, it
is
> run on the APF subtree and not the normal subtree. The normal subtree is
> "frozen" via the STATUS STOP operation during APF authorized function to
> decrease the likelihood of "cracking" the APF code. CICS switched back and
> forth using its SVC somehow (I don't know the internals).
>
> Now, being the weirdo that I am, I'd likely do my APF authorized work by
> using the UNIX fork() and exec(), where I exec() a module which is in the
> UNIX filesystem marked as APF authorized. Depending on what I need to do,
I
> would either use shared memory (shmat) or set up a UNIX bidirectional
> unnamed PIPE if the APF task worked more like a "server" and would be
> invoked multiple times. It's just seems easier to me. Or use UNIX message
> queues for communications. I have a better understanding of using pipes.
>
> The plus of the UNIX solution is that the invoker does not need to be APF
> authorized at all. It just needs to be able to do the UNIX fork() and
exec()
> of the APF authorized "service" program. I'd likely secure the service
> program by having the appropriate UNIX security on the executable file in
> the UNIX filesystem (using ACLs if necessary). An alternative /
enhancement
> would be to have the UNIX program do a RACF security call of some sort to
> see if the invoker is authorized. This latter would be better if the
routine
> is multifunction where the sub functions need to be individually
authorized,
> perhaps with differing access lists. Like what ISMF does.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets(r)
>
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> [email protected] * www.HealthMarkets.com
>
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. HealthMarkets(r) is the brand name for products underwritten and
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The
Chesapeake
> Life Insurance Company(r), Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
--
Rob Schramm
Senior Systems Engineer
w: 513.305.6224
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
