api-layer
api-layer copied to clipboard
zowe
API ML mapping features do not work in ACF2 environment
Describe the bug Certain API ML features, specifically API ML mapping features require ZWESVUSR to have a password enabled.
https://docs.zowe.org/stable/extend/extend-apiml/authentication-for-apiml-services/#authentication-with-client-certificate
This is considered insecure on z/OS and it breaks basic security rules on the platform. The server user (STC user) must be always protected ACID.
- https://www.ibm.com/docs/en/zos/2.5.0?topic=procedures-protected-user-ids
- https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/administrating/manage-protected-acids.html
It is not possible to set passwords for STC users in certain security environments. It would also mean that the server user password would be expiring according to environmental policies which can easily lead to the service being unavailable.
Suggestion: API ML should be authenticated by some other method (such as a certificate) when communicating with ZSS.
ZSS accepts certificates since Zowe v2.10.0. This feature is currently undocumented.
More details about client certificates:
You need a client certificate that has the public key signed by the root certificate authority of ZSS server certificate. The mechanism for mapping certificate to user is R_USERMAP; so, you need the client certificate added to desired user as personal in your esm.
So what exactly would this change mean fo the Zowe users? For usage of OIDC they will need to create a Zowe user which will have the client certificate of the API Gateway mapped?
Ok, it seems that this issue is linked: https://github.com/zowe/zowe-install-packaging/issues/3570
Hello, Is there a solution for ZWESVUSR to not have a password enabled ? because security wouldn't accept a STC with a password. How can we authenticate using a certificate instead ? thanks
Hello, Is there a solution for ZWESVUSR to not have a password enabled ? because security wouldn't accept a STC with a password. How can we authenticate using a certificate instead ? thanks
No there is currently no workaround for API ML mapping features. API ML must be updated to use certificates instead of pass tickets.
The current situation seems to be complex. The problem is actually within the ZSS and specifically in a way how ACF2 handles authentication and impersonification. It seems that there may be less secure workarounds but the actual solutions depend on the ACF2 team. I will follow-up with the ACF2 teams on what are their plans with respect to fix.
What exactly needs to be fixed on the ACF2 side? It seems that ACF2 strictly follows the security rules and this is the correct approach.
I would ask Joe Devlin, this is what I got when asking during the PI Planning call.
The issue as understood within the ZSS seems to be documented here: https://github.com/zowe/zss/issues/615 where I am not certain whether and under what specific circumstances is it possible to run ZSS under user without password. @JoeNemo do you know whether it's already possible?
If it's possible and the only remaining issue is in the way API Mediation Layer connects to the ZSS, then we will fix it directly, but I believe that the last answer I got was that there is something in ACF2 that needs to be changed before the ZSS works fully and properly without password for the user running the ZSS.
To clarify we need to actually run the ZSS within the local environment. Test that the mapping functionality works when the user authenticates e.g. via basic authentication with username and password.
When this succeeds test whether client certificate is accepted and the ACF2 properly maps the user.
ZSS is probably using R_usermap for client cert auth https://github.com/zowe/zss/pull/584
We have implemented for 2.14 alternative route that doesn't require ZSS and as such works properly. The ZSS focused route is therefore being downgraded in importance and as such is of medium priority now.