(*) – available in Brightside Enterprise
In discussions with existing and future clients, we hear over and over again the need for easy access to new technologies and at the same time, enterprise-grade features such as high-availability (*) and security.
Zowe Open Mainframe Project enables a large community of developers to interact with z/OS in the same way that we are used to when working with cloud environments – setting up a sandbox, checking out code, using modern development tools and frameworks and creating robust automation that runs build and test tasks on z/OS.
Zowe is an infrastructure facilitating access to the mainframe for developers, system operators, system programmers, security administrators, and all other people that manage mainframe environments. The Zowe components are created using current web UI frameworks and tools such as Angular and React. The web applications are integrated into Zowe Desktop and their APIs can be accessed via Zowe API gateway, which provides a single point of access and unified method for authentication.
Zowe is built on top of the proven technologies that allow the development of resilient API service such as Netflix Zuul and Eureka. The applications can be developed in Java or Node.js platforms that are available and supported on z/OS.
When it comes to security, Zowe is based on the facilities that are provided by z/OS and technologies available on the System z platform.
Authentication and Authorization
A Zowe user needs to provide valid z/OS credentials in order to use Zowe Desktop, Zowe CLI, or any Zowe API service. These credentials are validated using System Authorization Facility (SAF) interface on z/OS that routes the validation to a security product such as CA Top Secret® for z/OS, CA ACF2™ for z/OS, or IBM RACF®.
The Zowe Desktop does not store the credentials in the browser. The Zowe CLI can store the credentials in the secure credentials store (*).
The authorization to any mainframe resource, such as a data set, file system, or database, is done by the SAF interface for the authenticated user. The Zowe API services do not have additional access rights and the access is checked by z/OS for the user that seeks those rights. If the user does not have access to a resource without Zowe, the user will not have access to it with Zowe.
Transport security – TLS/SSL
Zowe provides access to users from other platforms. It can be users of Zowe Desktop from their web browser on their workstation, developers using the CLI on their workstation, or automated CI/CD pipelines running on Linux or Windows systems.
The data between API services and their clients are transferred using HTTPS protocol. The certificates and private keys are stored in z/OS key rings (*) or file-based key stores and managed using tools on z/OS that can use the cryptographic capabilities of System Z hardware.
The default configuration has HTTPS turned on and allows TLS 1.2 and higher with ciphers that are considered as secure by the security experts.
The Zowe certificate management can import existing certificates and keys or generate certificates for new services.
Zowe ecosystem provides multiple applications and API services. The Zowe Desktop provides a single sign-on experience. The login process generates a login token that resides on z/OS and is used within the Zowe Desktop session to access applications and API services that support Zowe authentication. The validity of the token is limited by time.
REST API security
The services that want to register to the Zowe API ecosystem need to provide a valid digital certificate. Unauthorized services cannot be part of the Zowe ecosystem.
Services that access other services are performing full certificate validation.
All open ports in Zowe are scanned automatically during the development process by tools that provide dynamic scanning and automated penetration testing such as IBM AppScan and Veracode in combination with static analysis tools such as SonarQube and open-source tools such as TestSSL. The results of these scans are addressed with the highest priority.
These tools check that the configuration is secure and scan for known vulnerabilities.
Services that are running on z/OS UNIX do not require UID(0).
APF-authorization is required only for the service that needs it. This service is Zowe cross memory server which is a started task angel that runs an authorized server application providing privileged cross-memory services to Zowe. Other services do not require APF-authorization.
Zowe maintains the integrity of the existing security stack on z/OS and only extends it through access via HTTPS that follow the highest security standards.
The security in Zowe is a critical aspect since Zowe enables easy access to a critical platform. Zowe security is based on industry standards and z/OS security facilities. Automated security testing and continuous attention to security during code reviews help the community to achieve high-security standards.
Read more about Broadcom’s support of Zowe here.