Question & Answer
Question
Why aren't the globalAdminGroup (and adminGroup) taking effect after applying PTF UI35770 for APAR PI56615 (and its related IMS mobile feature pack)? We are running z/OS Connect Enterprise Edition (EE) V2 to use IMS mobile feature pack. Before z/OS Connect PTF UI35770 which incorporated WAS Liberty 8.5.5.8 fix, we are able to specify globalAdminGroup under zosconnect_zosConnectManager. Now it seems like globalAdminGroup and other groupings like invokeGroup are not being checked.
There are no error messages in the server, but when a user invokes a uri with /zosConnect/services/ they now get back an http 403 Forbidden response status.
My server.xml has specified...
<zosconnect_auditInterceptor id="audit1" sequence="1"
/>
<zosconnect_authorizationInterceptor id="auth1" sequence="2"
/>
<zosconnect_zosConnectManager globalInterceptorsRef="globalInterceptors" id="zosConnectGlobals"
globalAdminGroup="ZABCD"
/>
<zosconnect_zosConnectInterceptors id="globalInterceptors"
interceptorRef="audit1,auth1"/>
<zosconnect_zosConnectService adminGroup="ZABCD" interceptorsRef="globalInterceptors"
serviceName="ZSERV1" serviceRef="ZSERV1"
/>
The request is for /zosConnect/services/ and the userid is ZUSER1 in group ZABCD.
The behavior of the zosconnect global interceptor for security does not appear to be getting called to check and that EJBROLE mapping appears to occur.
Answer
First we would need some additional diagnostic tracing in the logging tag in your server.xml to trace security in the z/OS Connect V2 EE server as shown below.
<logging traceSpecification="*=info:com.ibm.ws390.ola.*=all:
UserRegistry=all:Credentials=all:
Security.Authorization=all:Credentials=all:
zosConnect=all">
This should show the full authentication checking and roles so that the ffdc folder, trace.log and message.log as well as the introspection files in the dump folder for the ServiceIntrospection can be reviewed to confirm the user group associations and SAFRoleMapper.
If you enter command /MODIFY <your_server>,DUMP from SDSF to request the .zip files with the additional tracing, you will be able to see the failing case where the request is resulting in the 403 Forbidden http response status.
If you did not expect the EJBROLE mapping SAF check to be occurring after applying PTF UI35770, this PTF included Liberty APAR fix PI54091 which fixed the problem where no check for the EJBROLE access to the zosConnectAccess role was being performed. After UI35770 with PI54091, Liberty now performs the check against the zosConnectAccess role.
If you check the dump folder trace.log from your server for trace entries similar to those below for userid ZUSER1 in group ZABACD, it might indicate the ZUSER1 needs READ access to the zosConnectAccess role, but has NONE.
-----------------------------------------------------------------------
[4/29/16 14:50:04:148 GMT] 00000039 id=bba9be92
com.ibm.ws.security.saf.SAFServiceResult < getBytes Exit
[B@1cd007a1,len=20
|0000| 00000000 00000008 00000008 00000004 00000009
-----------------------------------------------------------------------
The SAF RC is 00000008
RACF RC is 00000008
RACF RSN is 00000004
The z/OS Connect V2 EE documentation topic Configuring security for z/OS Connect EE in the Procedure section under step 2 describes the server.xml changes for adding the authorization-role tag.
You will need to provide xml configuration tag in the server.xml for the ZABCD group:
<authorization-roles id="zos.connect.access.roles">
<security-role name="zosConnectAccess">
<user name="ZABCD"/>
</security-role>
</authorization-roles>
...and then permit the ZABCD group in your external security manager...for example in RACF...
PERMIT BBGZDFLT.zos.connect.access.roles.zosConnectAccess
CLASS(EJBROLE) ID(ZABCD) ACCESS(READ)
If the ZUSER1 and any other admin users are connected to the ZABCD group, the RACROUTE check for READ access to the zosConnectAccess resource should be okay.
Product Synonym
zCEE
Was this topic helpful?
Document Information
Modified date:
14 February 2023
UID
dwa1274347