[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Can I share an ACEE with other address spaces
From:       Peter Standfield <standfip () GMAIL ! COM>
Date:       2023-11-20 21:57:01
Message-ID: 72a22c03-2750-41e0-a3f7-6654d16723b4 () gmail ! com
[Download RAW message or body]

I've taken in all your suggestions and done some reading between the 
lines. Also reading the manuals. Here's what I now think I need to do.

When a user signs in:
- do a RACROUTE VERIFY to confirm userid and password and create the ACEE
- RACROUTE EXTRACT with TYPE=ENVRXTR and save the ENVR data structure 
somewhere that is accessible by all children
- when finished with this request, RACROUTE VERIFY with ENVIR=DELETE to 
discard the ACEE

When another request comes in from that user at a later time:
- do a RACROUTE VERIFY with ENVRIN=(the saved data structure) and create 
ACEE
- put the ACEE pointer into TCBSENV
- when finished with this request, RACROUTE VERIFY with ENVIR=DELETE to 
discard the ACEE

When the user signs out
- discard the saved ENVR data structure

I hope I'm on the right track here.

Peter Standfield

On 20/11/2023 7:28 pm, Guus Bonnes wrote:
> I would advise against physically sharing an ACEE. As Walt suggested 
> you can extract/rebuild an ACEE using an environment object. Or use 
> modern approaches like identity tokens (JWT) that even work across 
> LPARs. These allow you to basically make a copy of the ACEE. No need 
> to keep passwords/phrases etc.
>
> Guus
>
> On 19/11/2023 05:35, Peter Standfield wrote:
>> All requests are processed by child address spaces. The parent server 
>> address space is not involved. Users sign in, send in one or more 
>> requests and finally sign out.
>>
>> All the children are waiting for work in a SOCKET ACCEPT call. It is 
>> unpredictable which child will get the next request. The next request 
>> for a given user may be given to a child that did not do a RACROUTE 
>> VERIFY for that user. Therefore it does not have an ACEE for that user
>>
>> What to do?
>> - get the ACEE from shared storage? CSA?
>> - or, do another RACROUTE VERIFY? How would I arrange that without 
>> having a saved copy of the userid and password somewhere?
>>
>> I plan to pursue Tony's suggestion.
>>
>> Peter Standfield
>>
>> On 19 November 2023 2:05:51 am AEDT, Walt Farrell 
>> <walt.farrell@CHARTER.NET> wrote:
>>> On 11/15/2023 8:38 PM, Peter Standfield wrote:
>>>> I have a server on z/OS which processes web browser requests.  At 
>>>> startup this server forks many child processes which will process 
>>>> the requests.
>>>> Users signon with a userid and password which is verified with a 
>>>> RACROUTE macro. This RACROUTE returns a pointer to an ACEE which is 
>>>> saved.
>>>> Subsequent requests from a particular user need the ACEE in order 
>>>> check authorisation for resource accesses.
>>>>
>>>> The problem is that it is unpredictable which child will get to 
>>>> process subsequent requests.
>>>> For example, child A may process the signon and save the ACEE. The 
>>>> next request for that user may be processed by child B!
>>>> How can child B get access to the ACEE that child A created?  Or do 
>>>> I have to do another RACROUTE VERIFY in child B to get an ACEE?
>>> You cannot share ACEEs across address spaces. You would need to 
>>> create a new ACEE in the address space processing the request.
>>>
>>> Assuming the original server address space is initially processing 
>>> each request, then passing it to a child, you could have the child 
>>> perform the RACROUTE REQUEST=VERIFY,ENVIR=CREATE to generate the 
>>> ACEE, then it could use RACROUTE to delete the ACEE when it's done. 
>>> No need to save an ACEE address at all.
>>>
>>> Or, if the server performs the RACROUTE REQUEST=VERIFY,ENVIR=CREATE, 
>>> you might have the server also use RACROUTE 
>>> REQUEST=EXTRACT,TYPE=ENVRXTR to obtain a portable copy of an ACEE to 
>>> pass to the child, and then delete the server's copy of the ACEE 
>>> created by the REQUEST=VERIFY.
>>>
>>> -- 
>>> Walt
[prev in list] [next in list] [prev in thread] [next in thread]