diff --git a/docs/extend/extend-apiml/api-mediation-oidc-authentication.md b/docs/extend/extend-apiml/api-mediation-oidc-authentication.md index dec5a517fb..465157b7b9 100644 --- a/docs/extend/extend-apiml/api-mediation-oidc-authentication.md +++ b/docs/extend/extend-apiml/api-mediation-oidc-authentication.md @@ -259,7 +259,7 @@ Use the following curl command to make a REST request with the OIDC token to the curl --location 'https://"$HOSTNAME:$PORT"/gateway/api/v1/auth/oidc-token/validate --data '{"token": "$OIDC_TOKEN","serviceId": "$SERVICE_ID"}' ``` -An HTTP `200` code is returned if the validation passes. Failure to validate returns an HTTP `40x` error. +An HTTP `204` code is returned if the validation passes. Failure to validate returns an HTTP `40x` error. ::: :::note Azure Entra ID OIDC notes: diff --git a/docs/extend/extend-apiml/zaas-client.md b/docs/extend/extend-apiml/zaas-client.md index 29c3f3c216..2b5448e670 100644 --- a/docs/extend/extend-apiml/zaas-client.md +++ b/docs/extend/extend-apiml/zaas-client.md @@ -33,6 +33,7 @@ public interface ZaasClient { String login(String authorizationHeader) throws ZaasClientException; ZaasToken query(String token) throws ZaasClientException; ZaasToken query(HttpServletRequest request) throws ZaasClientException; + ZaasOidcValidationResult validateOidc(String token) throws ZaasClientException; String passTicket(String jwtToken, String applicationId) throws ZaasClientException, ZaasConfigurationException; void logout(String token) throws ZaasClientException, ZaasConfigurationException; } @@ -88,6 +89,21 @@ cookie or in an Authorization header. You then receive the `ZaasToken` Object in ZaasToken query(HttpServletRequest request) throws ZaasClientException; ``` +### Validate the OIDC token (`validateOidc`) + +Use the `validateOidc` method to get the validity information about the OIDC token. + +Call the `validateOidc` method from your API in the following format: + +```java +ZaasOidcValidationResult validateOidc(String token) throws ZaasClientException; +``` + +In return, you receive the `ZaasOidcValidationResult` Object in JSON format. + +This method automatically uses the truststore file to add a security layer, which you configured in the `ConfigProperties` class. + + ### Invalidate a JWT token (`logout`) The `logout` method is used to invalidate the JWT token. The token must be provided in the Cookie header and must follow the format accepted by the API ML. @@ -124,65 +140,75 @@ To use this library, use the procedure described in this section. 1. Add `zaas-client` as a dependency in your project. You will need to specify the version of the `zaas-client` you want. `zaas-client` versioning following the semantic versioning format of `major.minor.patch`. For example, `1.22.0`. +
+ Click here for procedural details using Gradle. + **Gradle:** - 1. Create a `gradle.properties` file in the root of your project if one does not already exist. + 1. Create a `gradle.properties` file in the root of your project if one does not already exist. - 2. In the `gradle.properties` file, set the URL of the specific Artifactory containing the _SpringEnabler_ artifact. + 2. In the `gradle.properties` file, set the URL of the specific Artifactory containing the _SpringEnabler_ artifact. - ``` - # Repository URL for getting the enabler-java artifact - artifactoryMavenRepo=https://zowe.jfrog.io/zowe/libs-release/ - ``` + ``` + # Repository URL for getting the enabler-java artifact + artifactoryMavenRepo=https://zowe.jfrog.io/zowe/libs-release/ + ``` - 3. Add the following _Gradle_ code block to the `repositories` section of your `build.gradle` file: + 3. Add the following _Gradle_ code block to the `repositories` section of your `build.gradle` file: - ```gradle - repositories { - ... + ```gradle + repositories { + ... - maven { + maven { url artifactoryMavenRepo - } } - ``` + } + ``` - 4. Add the following _Gradle_ dependency: + 4. Add the following _Gradle_ dependency: - ```groovy - dependencies { - compile 'org.zowe.apiml.sdk:zaas-client:{{version}}' - } - ``` + ```groovy + dependencies { + compile 'org.zowe.apiml.sdk:zaas-client:{{version}}' + } + ``` + +
+ +
+ Click here for procedural details using Maven. **Maven:** - 1. Add the following _XML_ tags within the newly created `pom.xml` file: - - ```xml - - - libs-release - libs-release - https://zowe.jfrog.io/zowe/libs-release/ - - false - - - - ``` + 1. Add the following _XML_ tags within the newly created `pom.xml` file: + + ```xml + + + libs-release + libs-release + https://zowe.jfrog.io/zowe/libs-release/ + + false + + + + ``` **Tip:** If you want to use snapshot version, replace libs-release with libs-snapshot in the repository url and change snapshots->enabled to true. - 2. Then add the following _Maven_ dependency: + 2. Then add the following _Maven_ dependency: - ```xml - - org.zowe.apiml.sdk - zaas-client - {{version}} - - ``` + ```xml + + org.zowe.apiml.sdk + zaas-client + {{version}} + + ``` + +
2. In your application, create your Java class which will be used to create an instance of `ZaasClient`, which enables you to use its method to login, query, and to issue a PassTicket. diff --git a/docs/images/troubleshoot/cli/PowerShell_developer_setting.png b/docs/images/troubleshoot/cli/PowerShell_developer_setting.png new file mode 100644 index 0000000000..e25f909823 Binary files /dev/null and b/docs/images/troubleshoot/cli/PowerShell_developer_setting.png differ diff --git a/docs/troubleshoot/cli/known-cli.md b/docs/troubleshoot/cli/known-cli.md index 705dfc7a37..aaa651b249 100644 --- a/docs/troubleshoot/cli/known-cli.md +++ b/docs/troubleshoot/cli/known-cli.md @@ -211,3 +211,32 @@ When the `zowe zos-files search data-sets` command is issued with the `--mainfra **Solution:** Issue the `zowe files search ds` command without the `--mainframe-search` option. This returns results that include data sets in binary format. + +## Error message with PowerShell scripts + +**Valid on Windows** + +**Symptom:** + +PowerShell users on Windows can encounter an error when they try to run Zowe CLI with certain execution policies in place. + +Example of an error message: + +``` +PS C:\> zowe +zowe : File C:\Users\user\AppData\Roaming\npm\zowe.ps1 cannot be loaded because running scripts is disabled on this +system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170. +At line:1 char:1 ++ zowe ++ ~~~~ + + CategoryInfo : SecurityError: (:) [], PSSecurityException + + FullyQualifiedErrorId : UnauthorizedAccess +``` + +**Solutions:** + +- Update developer settings in Windows to enable running local scripts without signing: + +![PowerShell setting](../../images/troubleshoot/cli/PowerShell_developer_setting.png) + +- Run PowerShell as an administrator and use the `Set-ExecutionPolicy` command to change the execution policy to a less-restrictive setting, for example: `Set-ExecutionPolicy RemoteSigned -scope CurrentUser`. diff --git a/docs/user-guide/api-mediation/configuration-extender-passtickets.md b/docs/user-guide/api-mediation/configuration-extender-passtickets.md index b9783ab2ec..05646518bf 100644 --- a/docs/user-guide/api-mediation/configuration-extender-passtickets.md +++ b/docs/user-guide/api-mediation/configuration-extender-passtickets.md @@ -4,7 +4,7 @@ One option to enable single sign-on (SSO) to your extending REST API services is :::info Required Role: security administrator ::: - + ## Overview of PassTickets API clients can use various supported methods to access an API service such as a Zowe JWT token or a client certificate even if the API service itself does not support the JWT token or a client certificate. An intermediary for support of JWT or a client certificate can be through the use of PassTickets. @@ -14,10 +14,10 @@ The API Gateway uses the PassTicket to access that API service. The API Gateway ## Configuring Zowe to use PassTickets -Configuring Zowe to use PassTickets involves two processes: +Configuring Zowe to use PassTickets involves two processes: -- Enabling the use of PassTickets in your External Security Manager (ESM) -- Configuring security to allow the Zowe API Gateway to generate PassTickets for an API service +1. Enabling the use of PassTickets in your External Security Manager (ESM) +2. Configuring security to allow the Zowe API Gateway to generate PassTickets for an API service ### Enabling the use of PassTickets in your External Security Manager (ESM) @@ -29,87 +29,95 @@ Since the Zowe 2.17 release, it is no longer necessary to disable replay protect This section applies to users who do not already have PassTickets enabled in the system, or users who need to define a PassTicket for a new APPLID. If you already have an APPLID that you intend to use to define your API service, skip to the section [Configuring security to allow the Zowe API Gateway to generate PassTickets for an API service](#configuring-security-to-allow-zowe-api-gateway-to-generate-passtickets-for-an-api-service). :::tip -To validate if a PassTicket is already defined, list the APPL and PKTDATA with a command corresponding to your ESM. Output indicates if a PassTicket is already defined. No results after issuing an ESM command indicates that a PassTicket is not defined. If a PassTicket is defined, the access of the zoweuser can be determined. - -- **Validating an existing PassTicket for ACF2** +To validate if a PassTicket is already defined, list the APPL and PTKTDATA with a command corresponding to your ESM. Output indicates if a PassTicket is already defined. No results after issuing an ESM command indicates that a PassTicket is not defined. If a PassTicket is defined, the access of the ZWESVUSR can be determined. -
+**Validating an existing PassTicket for ACF2** - Click here for command details about validating an existing PassTicket for ACF2. +
- In your ESM command line interface or other security environment, execute the following commands: +Click here for procedure details about validating an existing PassTicket for ACF2. - ```acf2 - SET RESOURCE(SAF) - LIST LIKE(-) +In your ESM command line interface or other security environment, perform the following steps: - SET RESOURCE(SAF) - LIST LIKE(-) +1. Issue a `SHOW CLASMAP` command in TSO ACF to verify if the APPL resource is defined in the GSO. Note the 3 character type code associated with APPL. If APPL does not appear in the `SHOW CLASMAP` listing, run the following commands: - SET PROFILE(PTKTDATA) DIVISION(SSIGNON) - LIST LIKE(-) + ```acf2 + SET CONTROL(GSO) + INSERT CLASMAP.appl RESOURCE(APPL) RSRCTYPE(APL) + F ACF2,REFRESH(CLASMAP) + ``` - SET RESOURCE(PTK) - LIST LIKE(IRRPTAUTH-) +2. Replace 'APL' with the type code listed in the `SHOW CLASMAP` output: + ``` + SET RESOURCE(APL) + LIST LIKE(-) + ``` +3. Verify if PTKTDATA is defined, by executing the following commands: + ``` + SET PROFILE(PTKTDATA) DIVISION(SSIGNON) + LIST LIKE(-) + SET RESOURCE(PTK) + LIST LIKE(IRRPTAUTH-) ``` - - **`-`** - A wildcard symbol that lists all resources +- **`-`** + A wildcard symbol that lists all resources - - **`-`** - Lists everything related to specified applid in a resource (in this case, SAF), or specified in a profile (in this case, PTKTDATA) +- **`-`** + Lists everything related to specified applid in a resource (in this case, SAF), or specified in a profile (in this case, PTKTDATA) -
+
-- **Validating an existing PassTicket for Top Secret** +**Validating an existing PassTicket for Top Secret** -
+
- Click here for command details about validating an existing PassTicket for Top Secret. +Click here for command details about validating an existing PassTicket for Top Secret. - In your ESM command line interface or other security environment, execute the following commands: +1. In your ESM command line interface or other security environment, execute the following commands: ```tss - TSS WHOHAS APPL() - TSS WHOHAS PTKTDATA() - TSS WHOHAS PTKTDATA(IRRPTAUTH..) + TSS WHOHAS APPL() + TSS WHOHAS PTKTDATA() + TSS WHOHAS PTKTDATA(IRRPTAUTH..) ``` +2. If APPL and PTKTDATA are not yet defined, follow the steps to create them as described in the [Enabling PassTickets with Top Secret](#enabling-passtickets-with-top-secret) section. - - **`.`** - A wildcard symbol that lists all resources +- **`.`** + A wildcard symbol that lists all resources - - **`IRRPTAUTH..`** - Returns everything about the specified applid for IRRPTAUTH +- **`IRRPTAUTH..`** + Returns everything about the specified applid for IRRPTAUTH -
+
-- **Validating an existing PassTicket for RACF** +**Validating an existing PassTicket for RACF** -
+
- Click here for command details about validating an existing PassTicket for RACF. +Click here for command details about validating an existing PassTicket for RACF. - In your ESM command line interface or other security environment, execute the following commands: +In your ESM command line interface or other security environment, execute the following commands: ```racf - RLIST APPL * ALL - RLIST APPL ALL - RLIST PTKTDATA SSIGNON ALL - RLIST PTKTDATA IRRPTAUTH..* ALL + RLIST APPL * ALL + RLIST APPL ALL + RLIST PTKTDATA SSIGNON ALL + RLIST PTKTDATA IRRPTAUTH..* ALL ``` - Ensure that you validate PKTDATA access for APPL. +Ensure that you validate PTKTDATA access for APPL. - - **`*`** - A wildcard symbol that resturns all resources +- **`*`** + A wildcard symbol that resturns all resources - - **`RLIST PTKTDATA SSIGNON ALL`** - Validates all applid for PTKDATA class +- **`RLIST PTKTDATA SSIGNON ALL`** + Validates all applid for PTKDATA class - - **`RLIST PTKTDATA IRRPTAUTH..* ALL`** - Validates all applid permissions for PTKDATA class +- **`RLIST PTKTDATA IRRPTAUTH..* ALL`** + Validates all applid permissions for PTKDATA class -
+
::: @@ -121,12 +129,19 @@ Follow these steps to enable PassTicket Support specific to your ESM. Click here for command details about configuring Zowe to use PassTickets using ACF2. -1. In your ESM command line interface or other security environment, define the application session key by entering the following commands, if the session key is not already defined. +1. Issue the `SHOW CLASMAP` command in TSO ACF to identity the 3 character type code associated with APPL. Replace 'APL' with the type code listed in the `SHOW CLASMAP` output: + + ```acf2 + SET RESOURCE(APL) + RECKEY ADD(UID() ALLOW) + F ACF2,REBUILD(APL) + ``` +2. In your ESM command line interface or other security environment, define the application session key by entering the following commands if the session key is not already defined. ```acf2 - SET PROFILE(PTKTDATA) DIV(SSIGNON) - INSERT SSKEY() - F ACF2,REBUILD(PTK),CLASS(P) + SET PROFILE(PTKTDATA) DIV(SSIGNON) + INSERT SSKEY() + F ACF2,REBUILD(PTK),CLASS(P) ``` * **`applid`** @@ -135,7 +150,7 @@ Specifies the application ID used for PassTicket validation to authenticate conn * **`key-description`** Specifies the secured sign-on hexadecimal application key of 16 hexadecimal digits (8-byte or 64-bit key). Each application key must be the same on all systems in the configuration and the values must be kept secret and secured. -2. Complete the PassTicket setup by entering the following commands: +3. Complete the PassTicket setup by entering the following commands: ```acf2 F ACF2,REBUILD(PTK),CLASS(P) @@ -143,7 +158,7 @@ Specifies the application ID used for PassTicket validation to authenticate conn The PassTicket record is now active in the system. -3. Enable the started task user ID to generate PassTickets for the application by entering commands similar to the following: +4. Enable the started task user ID to generate PassTickets for the application by entering commands similar to the following: ``` SET RESOURCE(PTK) @@ -164,7 +179,7 @@ You configured Zowe to use PassTickets for single sign on using ACF2. Click here for command details about configuring Zowe to use PassTickets using Top Secret. -Before you begin this procedure, verify that the `PTKTDATA` class and ownership for the PassTicket resource (`IRRPTAUT`) have not already been defined as described in the previous tip. +Before you begin this procedure, verify that the `PTKTDATA` class and ownership for the PassTicket resource (`IRRPTAUTH`) have not already been defined as described in the previous tip. 1. Update the resource descriptor table (RDT) to define the `PTKTDATA` class by entering the following commands: @@ -181,11 +196,13 @@ Before you begin this procedure, verify that the `PTKTDATA` class and ownership Include `RESCODE(n)` in the range of 101 to 13F to make `PTKTDATA` a prefixed resource class. ::: -2. Assign ownership for the PassTicket resource (`IRRPTAUT`). Execute the following commands: +2. Assign ownership for the PassTicket resource (`IRRPTAUTH`). Execute the following commands: ``` - TSS ADDTO(department) PTKTDATA(IRRPTAUT) + TSS ADDTO() PTKTDATA(IRRPTAUTH) ``` - +- **`department`** + Specifies the department for `PTKTDATA(IRRPTAUTH)`. The default department is `TSODEPT1`. + 3. Define PassTicket for application ID _applid_: ```tss @@ -350,11 +367,21 @@ Grant the Zowe started task user ID permission to generate PassTickets for users ### Verifying your PassTicket Application -In your ESM command line interface or other security environment, execute the following commands: +In your ESM command line interface or other security environment, execute the commands that correspond to your ESM: -```racf - RLIST APPL ALL - RLIST PTKTDATA IRRPTAUTH..* ALL +#### Verifying PassTickets using ACF2 + +
+Click here for command details for ACF2. + +**ACF2:** + +Replace 'APL' with the type code listed in the `SHOW CLASMAP` output: +```acf2 +SET RESOURCE(APL) +LIST LIKE(-) +SET RESOURCE(PTK) +LIST LIKE(IRRPTAUTH-) ``` * **`applid`** @@ -362,6 +389,34 @@ Specifies the application ID used for PassTicket validation to authenticate conn Successful execution of this validation command shows your application and the specific access of the application. +
+ +#### Verifying PassTickets using Top Secret + +
+Click here for command details for Top Secret. + +**TSS:** +```tss +TSS WHOHAS APPL() +TSS WHOHAS PTKTDATA(IRRPTAUTH.) +``` + +
+ +#### Verifying PassTickets using RACF + +
+Click here for command details for RACF + +**RACF:** +```racf + RLIST APPL ALL + RLIST PTKTDATA IRRPTAUTH..* ALL +``` + +
+ **Output example:** ``` CLASS NAME diff --git a/docs/user-guide/configure-zos-system.md b/docs/user-guide/configure-zos-system.md index 64ca26a40e..3bcd4a2e92 100644 --- a/docs/user-guide/configure-zos-system.md +++ b/docs/user-guide/configure-zos-system.md @@ -66,62 +66,78 @@ Define or check the following configurations depending on whether ICSF is alread - Create CKDS, PKDS, TKDS VSAM data sets. - Define and activate the CSFSERV class: - - If you use RACF, issue the following commands: - ``` - RDEFINE CSFSERV profile-name UACC(NONE) - ``` - ``` - PERMIT profile-name CLASS(CSFSERV) ID(tcpip-stackname) ACCESS(READ) - ``` - ``` - PERMIT profile-name CLASS(CSFSERV) ID(userid-list) ... [for - userids IKED, NSSD, and Policy Agent] - ``` - ``` - SETROPTS CLASSACT(CSFSERV) - ``` - ``` - SETROPTS RACLIST(CSFSERV) REFRESH - ``` - - If you use ACF2, issue the following commands (note that `profile-prefix` and `profile-suffix` are user-defined): - ``` - SET CONTROL(GSO) - ``` - ``` - INSERT CLASMAP.CSFSERV RESOURCE(CSFSERV) RSRCTYPE(CSF) - ``` - ``` - F ACF2,REFRESH(CLASMAP) - ``` - ``` - SET RESOURCE(CSF) - ``` - ``` - RECKEY profile-prefix ADD(profile-suffix uid(UID string for tcpip-stackname) SERVICE(READ) ALLOW) - ``` - ``` - RECKEY profile-prefix ADD(profile-suffix uid(UID string for IZUSVR) SERVICE(READ) ALLOW) - ``` - (repeat for userids IKED, NSSD, and Policy Agent) +
+Click here for command details for RACF. - ``` - F ACF2,REBUILD(CSF) - ``` - - If you use Top Secret, issue the following command (note that `profile-prefix` and `profile-suffix` are user defined): - ``` - TSS ADDTO(owner-acid) RESCLASS(CSFSERV) - ``` - ``` - TSS ADD(owner-acid) CSFSERV(profile-prefix.) - ``` - ``` - TSS PERMIT(tcpip-stackname) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) - ``` - ``` - TSS PERMIT(user-acid) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) - ``` - (repeat for user-acids IKED, NSSD, and Policy Agent) +If you use RACF, issue the following commands: +``` +RDEFINE CSFSERV profile-name UACC(NONE) +``` +``` +PERMIT profile-name CLASS(CSFSERV) ID(tcpip-stackname) ACCESS(READ) +``` +``` +PERMIT profile-name CLASS(CSFSERV) ID(userid-list) ... [for +userids IKED, NSSD, and Policy Agent] +``` +``` +SETROPTS CLASSACT(CSFSERV) +``` +``` +SETROPTS RACLIST(CSFSERV) REFRESH +``` + +
+ +
+Click here for command details for ACF2. + +If you use ACF2, issue the following commands (note that `profile-prefix` and `profile-suffix` are user-defined): +``` +SET CONTROL(GSO) +``` +``` +INSERT CLASMAP.CSFSERV RESOURCE(CSFSERV) RSRCTYPE(CSF) +``` +``` +F ACF2,REFRESH(CLASMAP) +``` +``` +SET RESOURCE(CSF) +``` +``` +RECKEY profile-prefix ADD(profile-suffix uid(UID string for tcpip-stackname) SERVICE(READ) ALLOW) +``` +``` +RECKEY profile-prefix ADD(profile-suffix uid(UID string for IZUSVR) SERVICE(READ) ALLOW) +``` +(repeat for userids IKED, NSSD, and Policy Agent) + +``` +F ACF2,REBUILD(CSF) +``` + +
+
+Click here for command details for Top Secret + +If you use Top Secret, issue the following command (note that `profile-prefix` and `profile-suffix` are user defined): +``` +TSS ADDTO(owner-acid) RESCLASS(CSFSERV) +``` +``` +TSS ADD(owner-acid) CSFSERV(profile-prefix.) +``` +``` +TSS PERMIT(tcpip-stackname) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) +``` +``` +TSS PERMIT(user-acid) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) +``` +(repeat for user-acids IKED, NSSD, and Policy Agent) + +
:::note Notes - Determine whether you want SAF authorization checks against `CSFSERV` and set `CSF.CSFSERV.AUTH.CSFRNG.DISABLE` accordingly. @@ -138,149 +154,206 @@ To enable impersonation, you must grant the user ID `ZWESVUSR` associated with t You can issue the following commands first to check whether you already have the impersonation profiles defined as part of another server configuration, such as the FTPD daemon. Review the output to confirm that the two impersonation profiles exist and the user `ZWESVUSR` who runs the Zowe server started task has UPDATE access to both profiles. -- If you use RACF, issue the following commands: - ``` - RLIST FACILITY BPX.SERVER AUTHUSER - ``` - ``` - RLIST FACILITY BPX.DAEMON AUTHUSER - ``` -- If you use Top Secret, issue the following commands: - ``` - TSS WHOHAS IBMFAC(BPX.SERVER) - ``` - ``` - TSS WHOHAS IBMFAC(BPX.DAEMON) - ``` -- If you use ACF2, issue the following commands: - ``` - SET RESOURCE(FAC) - ``` - ``` - LIST BPX - ``` +
+Click here for command details for RACF. + +If you use RACF, issue the following commands: +``` +RLIST FACILITY BPX.SERVER AUTHUSER +``` +``` +RLIST FACILITY BPX.DAEMON AUTHUSER +``` + +
+ +
+Click here for command details for Top Secret. + +If you use Top Secret, issue the following commands: +``` +TSS WHOHAS IBMFAC(BPX.SERVER) +``` +``` +TSS WHOHAS IBMFAC(BPX.DAEMON) +``` + +
+ +
+Click here for command details for ACF2. + +If you use ACF2, issue the following commands: +``` +SET RESOURCE(FAC) +``` +``` +LIST BPX +``` + +
If the user `ZWESVUSR` who runs the Zowe server started task does not have UPDATE access to both profiles follow the instructions below. -- If you use RACF, complete the following steps: +
+Click here for procedure details for RACF. + +If you use RACF, complete the following steps: - 1. Activate and RACLIST the FACILITY class. This may have already been done on the z/OS environment if another z/OS server has been previously configured to take advantage of the ability to change its security environment, such as the FTPD daemon that is included with z/OS Communications Server TCP/IP services. - ``` - SETROPTS GENERIC(FACILITY) - SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) - ``` - 2. Define the impersonation profiles. This may have already been done on behalf of another server such as the FTPD daemon. - ``` - RDEFINE FACILITY BPX.SERVER UACC(NONE) - ``` - ``` - RDEFINE FACILITY BPX.DAEMON UACC(NONE) - ``` - 3. Having activated and RACLIST the FACILITY class, the user ID `ZWESVUSR` who runs the Zowe server started task must be given update access to the BPX.SERVER and BPX.DAEMON profiles in the FACILITY class. - ``` - PERMIT BPX.SERVER CLASS(FACILITY) ID() ACCESS(UPDATE) - ``` - ``` - PERMIT BPX.DAEMON CLASS(FACILITY) ID() ACCESS(UPDATE) - ``` - where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. - - /* Activate these changes */ - - ``` - SETROPTS RACLIST(FACILITY) REFRESH - ``` - 4. Issue the following commands to check whether permission has been successfully granted: - ``` - RLIST FACILITY BPX.SERVER AUTHUSER - ``` - ``` - RLIST FACILITY BPX.DAEMON AUTHUSER - ``` -- If you use Top Secret, complete the following steps: +1. Activate and RACLIST the FACILITY class. This may have already been done on the z/OS environment if another z/OS server has been previously configured to take advantage of the ability to change its security environment, such as the FTPD daemon that is included with z/OS Communications Server TCP/IP services. + +``` +SETROPTS GENERIC(FACILITY) +SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) +``` +2. Define the impersonation profiles. This may have already been done on behalf of another server such as the FTPD daemon. +``` +RDEFINE FACILITY BPX.SERVER UACC(NONE) +``` +``` +RDEFINE FACILITY BPX.DAEMON UACC(NONE) +``` +3. Having activated and RACLIST the FACILITY class, the user ID `ZWESVUSR` who runs the Zowe server started task must be given update access to the BPX.SERVER and BPX.DAEMON profiles in the FACILITY class. +``` +PERMIT BPX.SERVER CLASS(FACILITY) ID() ACCESS(UPDATE) +``` +``` +PERMIT BPX.DAEMON CLASS(FACILITY) ID() ACCESS(UPDATE) +``` +where: + +* `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. + +/* Activate these changes */ + +``` +SETROPTS RACLIST(FACILITY) REFRESH +``` +4. Issue the following commands to check whether permission has been successfully granted: + +``` +RLIST FACILITY BPX.SERVER AUTHUSER +``` +``` +RLIST FACILITY BPX.DAEMON AUTHUSER +``` + +
+ +
+Click here for procedure details for Top Secret. + +If you use Top Secret, complete the following steps: - 1. Define the BPX Resource and access for ``. - ``` - TSS ADD(`owner-acid`) IBMFAC(BPX.) - ``` - ``` - TSS PERMIT() IBMFAC(BPX.SERVER) ACCESS(UPDATE) - ``` - ``` - TSS PERMIT() IBMFAC(BPX.DAEMON) ACCESS(UPDATE) - ``` - where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. - 2. Issue the following commands and review the output to check whether permission has been successfully granted: - ``` - TSS WHOHAS IBMFAC(BPX.SERVER) - ``` - ``` - TSS WHOHAS IBMFAC(BPX.DAEMON) - ``` -- If you use ACF2, complete the following steps: - 1. Define the BPX Resource and access for ``. - ``` - SET RESOURCE(FAC) - ``` - ``` - RECKEY BPX ADD(SERVER ROLE() SERVICE(UPDATE) ALLOW) - ``` - ``` - RECKEY BPX ADD(DAEMON ROLE() SERVICE(UPDATE) ALLOW) - ``` - where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. - ``` - F ACF2,REBUILD(FAC) - ``` - 2. Issue the following commands and review the output to check whether permission has been successfully granted: - ``` - SET RESOURCE(FAC) - ``` - ``` - LIST BPX - ``` +1. Define the BPX Resource and access for ``. +``` +TSS ADD(`owner-acid`) IBMFAC(BPX.) +``` +``` +TSS PERMIT() IBMFAC(BPX.SERVER) ACCESS(UPDATE) +``` +``` +TSS PERMIT() IBMFAC(BPX.DAEMON) ACCESS(UPDATE) +``` +where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. + +2. Issue the following commands and review the output to check whether permission has been successfully granted: +``` +TSS WHOHAS IBMFAC(BPX.SERVER) +``` +``` +TSS WHOHAS IBMFAC(BPX.DAEMON) +``` + +
+ +
+Click here for procedure details for ACF2. + +If you use ACF2, complete the following steps: + +1. Define the BPX Resource and access for ``. +``` +SET RESOURCE(FAC) +``` +``` +RECKEY BPX ADD(SERVER ROLE() SERVICE(UPDATE) ALLOW) +``` +``` +RECKEY BPX ADD(DAEMON ROLE() SERVICE(UPDATE) ALLOW) +``` +where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. +``` +F ACF2,REBUILD(FAC) +``` + +2. Issue the following commands and review the output to check whether permission has been successfully granted: +``` +SET RESOURCE(FAC) +``` +``` +LIST BPX +``` + +
+ You must also grant READ access to the OMVSAPPL profile in the APPL class to the Zowe STC user as well as **all other Zowe users** using various Zowe features. Skip the following steps when the OMVSAPPL profile is not defined in your environment. -- If you use RACF, complete the following steps: +
+Click here for procedure details for RACF. - 1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. - ``` - RLIST APPL OMVSAPPL AUTHUSER - ``` +If you use RACF, complete the following steps: - 2. Issue the following commands and review the output to check if permission has been successfully granted: - ``` - PERMIT OMVSAPPL CLASS(APPL) ID() ACCESS(READ) - SETROPTS RACLIST(APPL) REFRESH - ``` +1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. +``` +RLIST APPL OMVSAPPL AUTHUSER +``` -- If you use Top Secret, complete the following steps: +2. Issue the following commands and review the output to check if permission has been successfully granted: +``` +PERMIT OMVSAPPL CLASS(APPL) ID() ACCESS(READ) +SETROPTS RACLIST(APPL) REFRESH +``` - 1. Check if you already have the required access as part of the environment configuration. Skip the following steps if access is already granted. - ``` - TSS WHOHAS APPL(OMVSAPPL) - ``` +
- 2. Issue the following commands and review the output to check if permission has been successfully granted: - ``` - TSS PERMIT() APPL(OMVSAPPL) - ``` +
+Click here for procedure details for Top Secret. -- If you use ACF2, complete the following steps: +If you use Top Secret, complete the following steps: - 1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. - ``` - SET RESOURCE(APL) - LIST OMVSAAPL - ``` +1. Check if you already have the required access as part of the environment configuration. Skip the following steps if access is already granted. +``` +TSS WHOHAS APPL(OMVSAPPL) +``` - 2. Issue the following commands and review the output to check if permission has been successfully granted: - ``` - SET RESOURCE(APL) - RECKEY OMVSAPPL ADD(SERVICE(READ) ROLE() ALLOW) - F ACF2,REBUILD(APL) - ``` +2. Issue the following commands and review the output to check if permission has been successfully granted: +``` +TSS PERMIT() APPL(OMVSAPPL) +``` + +
+ +
+Click here for procedure details for ACF2. + +If you use ACF2, complete the following steps: + +1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. +``` +SET RESOURCE(APL) +LIST OMVSAAPL +``` + +2. Issue the following commands and review the output to check if permission has been successfully granted: +``` +SET RESOURCE(APL) +RECKEY OMVSAPPL ADD(SERVICE(READ) ROLE() ALLOW) +F ACF2,REBUILD(APL) +``` + +
### Configure address space job naming @@ -352,32 +425,132 @@ If you have run `ZWESECUR`, you do not need to perform the steps described in th If you have not run `ZWESECUR` and are manually creating the user ID and groups in your z/OS environment, the commands are described below for reference. -- To create the `ZWEADMIN` group, issue the following command: - ``` - ADDGROUP ZWEADMIN OMVS(AUTOGID) - - DATA('STARTED TASK GROUP WITH OMVS SEGEMENT') - ``` +- To create the `ZWEADMIN` group, issue the following command according to your ESM: + +
+ Click here for command details for RACF. + + **RACF:** + ``` + ADDGROUP ZWEADMIN OMVS(AUTOGID) - + DATA('STARTED TASK GROUP WITH OMVS SEGEMENT') + ``` +
+ +
+ Click here for command details for Top Secret. + + **TSS:** + ``` + TSS CREATE() TYPE(GROUP) + + NAME('ZOWE ADMINISTRATORS') + + DEPT() + TSS ADD() GID() + ``` + +
+ +
+ Click here for command details for ACF2. + + **ACF2:** + ``` + SET PROFILE(GROUP) DIV(OMVS) + INSERT AUTOGID + F ACF2,REBUILD(GRP),CLASS(P) + ``` + +
-- To create the `ZWESVUSR` user ID for the main Zowe started task, issue the following command: - ``` - ADDUSER ZWESVUSR - + * To create the `ZWESVUSR` user ID for the main Zowe started task, issue the following command: + +
+ + Click here for command details for RACF. + + **RACF:** + ``` + ADDUSER - NOPASSWORD - - DFLTGRP(ZWEADMIN) - + DFLTGRP() - OMVS(HOME(/tmp) PROGRAM(/bin/sh) AUTOUID) - NAME('ZOWE SERVER') - DATA('ZOWE MAIN SERVER') - ``` + ``` +
+ +
+ Click here for command details for Top Secret. + + **TSS:** + ``` + TSS CREATE() TYPE(USER) PROTECTED + + NAME('ZOWE MAIN SERVER') + + DEPT() + TSS ADD() GROUP() + + DFLTGRP() + + HOME(/tmp) OMVSPGM(/bin/sh) UID() + ``` + +
+ +
+ Click here for command details for ACF2. + + **ACF2:** + ``` + SET LID + INSERT STC GROUP() + SET PROFILE(USER) DIV(OMVS) + INSERT AUTOUID HOME(/tmp) OMVSPGM(/bin/sh) + F ACF2,REBUILD(USR),CLASS(P),DIVISION(OMVS) + ``` +
- To create the `ZWESIUSR` group for the Zowe cross memory server started task, issue the following command: - ``` - ADDUSER ZWESIUSR - + +
+ Click here for command details for RACF. + + **RACF:** + ``` + ADDUSER - NOPASSWORD - - DFLTGRP(ZWEADMIN) - + DFLTGRP() - OMVS(HOME(/tmp) PROGRAM(/bin/sh) AUTOUID) - NAME('ZOWE XMEM SERVER') - DATA('ZOWE XMEM CROSS MEMORY SERVER') - ``` + ``` + +
+ +
+ Click here for command details for Top Secret. + + **TSS:** + ``` + TSS CREATE() TYPE(USER) PROTECTED + + NAME('ZOWE ZIS CROSS MEMORY SERVER') + + DEPT() + TSS ADD() GROUP() + + DFLTGRP() + + HOME(/tmp) OMVSPGM(/bin/sh) UID(&ZISUID.) + ``` +
+ +
+ Click here for command details for ACF2. + + **ACF2:** + ``` + SET LID + INSERT STC GROUP() + SET PROFILE(USER) DIV(OMVS) + INSERT AUTOUID HOME(/tmp) OMVSPGM(/bin/sh) + F ACF2,REBUILD(USR),CLASS(P),DIVISION(OMVS) + ``` +
### Configure ZWESLSTC to run Zowe high availability instances under ZWESVUSR user ID @@ -389,27 +562,41 @@ If you have run `ZWESECUR`, you do not need to perform the steps described in th ... ``` -If you have not run `ZWESECUR` and are configuring your z/OS environment manually, the following steps describe how to configure the started task `ZWESLSTC` to run under the correct user ID and group. +If you have not run `ZWESECUR` and are configuring your z/OS environment manually, the following steps describe how to configure the started task `ZWESLSTC` to run under the correct user ID and group. + +
+Click here for command details for RACF. + +If you use RACF, issue the following commands: +``` +RDEFINE STARTED ZWESLSTC.* UACC(NONE) STDATA(USER(ZWESVUSR) GROUP(ZWEADMIN) PRIVILEGED(NO) TRUSTED(NO) TRACE(YES)) +SETROPTS REFRESH RACLIST(STARTED) +``` +
+ +
+Click here for command details for ACF2. + +If you use ACF2, issue the following commands: + +``` +SET CONTROL(GSO) +INSERT STC.ZWESLSTC LOGONID(ZWESVUSR) GROUP(ZWEADMIN) STCID(ZWESLSTC) +F ACF2,REFRESH(STC) +``` -- If you use RACF, issue the following commands: - ``` - RDEFINE STARTED ZWESLSTC.* UACC(NONE) STDATA(USER(ZWESVUSR) GROUP(ZWEADMIN) PRIVILEGED(NO) TRUSTED(NO) TRACE(YES)) - SETROPTS REFRESH RACLIST(STARTED) - ``` +
-- If you use ACF2, issue the following commands: +
+Click here for command details for Top Secret. - ``` - SET CONTROL(GSO) - INSERT STC.ZWESLSTC LOGONID(ZWESVUSR) GROUP(ZWEADMIN) STCID(ZWESLSTC) - F ACF2,REFRESH(STC) - ``` +If you use Top Secret, issue the following commands: -- If you use Top Secret, issue the following commands: +``` +TSS ADDTO(STC) PROCNAME(ZWESLSTC) ACID(ZWESVUSR) +``` - ``` - TSS ADDTO(STC) PROCNAME(ZWESLSTC) ACID(ZWESVUSR) - ``` +
### Configure the cross memory server for SAF @@ -428,7 +615,10 @@ Activate the FACILITY class, define a `ZWES.IS` profile, and grant READ access t To do this, issue the following commands that are also included in the `ZWESECUR` JCL member. The commands assume that you run the Zowe server under the `ZWESVUSR` user. -- If you use RACF, issue the following commands: +
+Click here for command details for RACF. + +If you use RACF, issue the following commands: - To see the current class settings, use: ``` @@ -460,7 +650,12 @@ To do this, issue the following commands that are also included in the `ZWESECUR ``` This shows the user IDs who have access to the `ZWES.IS` class, which should include Zowe's started task user ID with READ access. -- If you use ACF2, issue the following commands: +
+ +
+Click here for command details for ACF2. + +If you use ACF2, issue the following commands: ``` SET RESOURCE(FAC) @@ -472,7 +667,12 @@ To do this, issue the following commands that are also included in the `ZWESECUR F ACF2,REBUILD(FAC) ``` -- If you use Top Secret, issue the following commands, where `owner-acid` can be IZUSVR or a different ACID: +
+ +
+Click here for command details for Top Secret. + +If you use Top Secret, issue the following commands, where `owner-acid` can be IZUSVR or a different ACID: ``` TSS ADD(`owner-acid`) IBMFAC(ZWES.) @@ -480,6 +680,7 @@ To do this, issue the following commands that are also included in the `ZWESECUR ``` TSS PERMIT(ZWESVUSR) IBMFAC(ZWES.IS) ACCESS(READ) ``` +
:::note Notes - The cross memory server treats "no decision" style SAF return codes as failures. If there is no covering profile for the `ZWES.IS` resource in the FACILITY class, the request will be denied. @@ -491,7 +692,8 @@ To do this, issue the following commands that are also included in the `ZWESECUR This security configuration is necessary for API ML to be able to map client certificate to a z/OS identity. A user running API Gateway must have read access to the SAF resource `IRR.RUSERMAP` in the `FACILITY` class. To set up this security configuration, submit the `ZWESECUR` JCL member. For users upgrading from version 1.18 and lower use the following configuration steps. -#### Using RACF +
+Click here for procedure details for RACF. If you use RACF, verify and update permission in the `FACILITY` class. @@ -512,7 +714,10 @@ If you use RACF, verify and update permission in the `FACILITY` class. SETROPTS RACLIST(FACILITY) REFRESH ``` -#### Using ACF2 +
+ +
+Click here for procedure details for ACF2. If you use ACF2, verify and update permission in the `FACILITY` class. @@ -534,7 +739,10 @@ If you use ACF2, verify and update permission in the `FACILITY` class. F ACF2,REBUILD(FAC) ``` -#### Using TSS +
+ +
+Click here for procedure details for Top Secret. If you use TSS, verify and update permission in `FACILITY` class. @@ -549,12 +757,15 @@ If you use TSS, verify and update permission in `FACILITY` class. TSS PER(ZWESVUSR) IBMFAC(IRR.RUSERMAP) ACCESS(READ) ``` +
+ ### Configure main Zowe server to use distributed identity mapping This security configuration is necessary for API ML to be able to map the association between a z/OS user ID and a distributed user identity. A user running the API Gateway must have read access to the SAF resource `IRR.IDIDMAP.QUERY` in the `FACILITY` class. To set up this security configuration, submit the `ZWESECUR` JCL member. For users upgrading from version 1.28 and lower, use the following configuration steps. -#### Using RACF +
+Click here for procedure details for RACF. If you use RACF, verify and update permission in the `FACILITY` class. @@ -582,7 +793,10 @@ If you use RACF, verify and update permission in the `FACILITY` class. SETROPTS RACLIST(FACILITY) REFRESH ``` -#### Using ACF2 +
+ +
+Click here for procedure details for ACF2. If you use ACF2, verify and update permission in the `FACILITY` class. @@ -603,8 +817,10 @@ If you use ACF2, verify and update permission in the `FACILITY` class. ``` F ACF2,REBUILD(FAC) ``` +
-#### Using TSS +
+Click here for procedure details for Top Secret. If you use TSS, verify and update permission in `FACILITY` class. @@ -620,20 +836,22 @@ If you use TSS, verify and update permission in `FACILITY` class. TSS PER(ZWESVUSR) IBMFAC(IRR.IDIDMAP.QUERY) ACCESS(READ) ``` +
+ ### Configure signed SAF Identity tokens (IDT) This section provides a brief description of how to configure SAF Identity tokens on z/OS so that they can be used by Zowe components like zss or API Mediation layer ([Implement a new SAF IDT provider](../extend/extend-apiml/implement-new-saf-provider.md)) -Follow these general steps: +**Follow these steps:** 1. Create PKCS#11 token 2. Generate a secret key for the PKCS#11 token (you can use the sample program ZWESECKG in the SZWESAMP dataset) 3. Define a SAF resource profile under the IDTDATA SAF resource class Details with examples can be found in documentation of external security products: -* **RACF** - **_Signed and Unsigned Identity Tokens_** and **_IDT Configuration_** subsections in _z/OS Security Server RACROUTE Macro Reference_ book, [link](https://www.ibm.com/docs/en/zos/2.4.0?topic=reference-activating-using-idta-parameter-in-racroute-requestverify). -* **Top Secret** - _**Maintain Identity Token (IDT) Records**_ subsection in _Administrating_ chapter, [link](https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/administrating/maintaining-special-security-records/maintain-identity-token-(idt)-records.html). -* **ACF2** - _**IDTDATA Profile Records**_ subsection in _Administrating_ chapter, [link](https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-acf2-for-z-os/16-0/administrating/administer-records/profile-records/idtdata-profile-records.html). +* **RACF** - **_Signed and Unsigned Identity Tokens_** and **_IDT Configuration_** subsections in _z/OS Security Server RACROUTE Macro Reference_ in the article [Activating and using the IDTA parameter in RACROUTE REQUEST=VERIFY](https://www.ibm.com/docs/en/zos/2.4.0?topic=reference-activating-using-idta-parameter-in-racroute-requestverify). +* **Top Secret** - _**Maintain Identity Token (IDT) Records**_ subsection in _Administrating_ chapter, in the article [Maintain Identity Token (IDT) Records](https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-top-secret-for-z-os/16-0/administrating/maintaining-special-security-records/maintain-identity-token-(idt)-records.html). +* **ACF2** - _**IDTDATA Profile Records**_ subsection in _Administrating_ chapter, in the article [IDTDATA Profile Records](https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-acf2-for-z-os/16-0/administrating/administer-records/profile-records/idtdata-profile-records.html). A part of the Signed SAF Identity token configuration is a nontrivial step that has to generate a secret key for the PKCS#11 token. The secret key is generated in ICSF by calling the PKCS#11 Generate Secret Key (CSFPGSK) or Token Record Create (CSFPTRC) callable services. An example of the CSFPGSK callable service can be found in the SZWESAMP dataset as the ZWESECKG job. @@ -642,17 +860,31 @@ A part of the Signed SAF Identity token configuration is a nontrivial step that This security configuration is necessary for API ML to be able to issue SMF records. A user running the API Gateway must have READ access to the RACF general resource `IRR.RAUDITX` in the `FACILITY` class. To set up this security configuration, submit the `ZWESECUR` JCL member. For users upgrading from version 1.18 and lower, use the configuration steps that correspond to the ESM. -To check whether you already have the auditing profile defined, issue the following command and review the output to confirm that the profile exists and that the user `ZWESVUSR` who runs the `ZWESLSTC` started task has READ access to this profile. +* To check whether you already have the auditing profile defined, issue the following command and review the output to confirm that the profile exists and that the user `ZWESVUSR` who runs the `ZWESLSTC` started task has READ access to this profile. + +
+ Click here for command details for RACF. -- If you use RACF, issue the following command: + If you use RACF, issue the following command: ``` RLIST FACILITY IRR.RAUDITX AUTHUSER ``` -- If you use Top Secret, issue the following command: +
+ +
+ Click here for command details for Top Secret. + + If you use Top Secret, issue the following command: ``` TSS WHOHAS IBMFAC(IRR.RAUDITX) ``` -- If you use ACF2, issue the following commands: + +
+ +
+ Click here for command details for ACF2. + + If you use ACF2, issue the following commands: ``` SET RESOURCE(FAC) ``` @@ -660,38 +892,56 @@ To check whether you already have the auditing profile defined, issue the follow LIST LIKE(IRR-) ``` -If the user `ZWESVUSR` who runs the `ZWESLSTC` started task does not have READ access to this profile, follow the procedure that corresponds to your ESM: - -- If you use RACF, update permission in the `FACILITY` class. - - **Follow these steps:** - - 1. Add user `ZWESVUSR` permission to `READ`. - ``` - PERMIT IRR.RAUDITX CLASS(FACILITY) ACCESS(READ) ID(ZWESVUSR) - ``` - 2. Activate changes. - ``` - SETROPTS RACLIST(FACILITY) REFRESH - ``` - -- If you use Top Secret, add user `ZWESVUSR` permission to READ. Issue the following command: - ``` - TSS PER(ZWESVUSR) IBMFAC(IRR.RAUDITX) ACCESS(READ) - ``` - -- If you use ACF2, add user `ZWESVUSR` permission to `READ`. Issue the following commands: - ``` - SET RESOURCE(FAC) - ``` - ``` - RECKEY IRR ADD(RAUDITX ROLE(&STCGRP.) SERVICE(READ) ALLOW) - ``` - ``` - F ACF2,REBUILD(FAC) - ``` - +
+ +* If the user `ZWESVUSR` who runs the `ZWESLSTC` started task does not have READ access to this profile, follow the procedure that corresponds to your ESM: + +
+ Click here for procedure details for RACF. + + If you use RACF, update permission in the `FACILITY` class. + + **Follow these steps:** + + 1. Add user `ZWESVUSR` permission to `READ`. + ``` + PERMIT IRR.RAUDITX CLASS(FACILITY) ACCESS(READ) ID(ZWESVUSR) + ``` + 2. Activate changes. + ``` + SETROPTS RACLIST(FACILITY) REFRESH + ``` + +
+ +
+ Click here for command details for Top Secret. + + If you use Top Secret, add user `ZWESVUSR` permission to READ. Issue the following command: + ``` + TSS PER(ZWESVUSR) IBMFAC(IRR.RAUDITX) ACCESS(READ) + ``` + +
+ +
+ Click here for command details for ACF2. + + If you use ACF2, add user `ZWESVUSR` permission to `READ`. Issue the following commands: + ``` + SET RESOURCE(FAC) + ``` + ``` + RECKEY IRR ADD(RAUDITX ROLE(&STCGRP.) SERVICE(READ) ALLOW) + ``` + ``` + F ACF2,REBUILD(FAC) + ``` + +
+ For more information about SMF records, see [SMF records](../user-guide/api-mediation/api-mediation-smf.md) in the Using Zowe API Mediation Layer documentation. + ### Multi-Factor Authentication (MFA) Multi-factor authentication is supported for several components, such as the Desktop and API Mediation Layer. diff --git a/docs/whats-new/release-notes/v3_0_0.md b/docs/whats-new/release-notes/v3_0_0.md index a081b1d56b..028ca3bafe 100644 --- a/docs/whats-new/release-notes/v3_0_0.md +++ b/docs/whats-new/release-notes/v3_0_0.md @@ -5,7 +5,7 @@ Welcome to the Version 3.0.0 release of Zowe! Version 3.0 introduced breaking changes and a number of new features. - See [Important updates](#important-updates) for a full list of changes to the functionality. -- See [Conformance and release compatibility](#conformance-and-release-compatibility) for V3 Conformance Criteria updates and compatibility with V2. +- See [Conformance and release compatibility](../zowe-compatibility-statement-v3.md) for V3 Conformance Criteria updates and compatibility with V2. **Download v3.0.0 build:** Want to try new features as soon as possible? You can download the v3.0.0 build from [Zowe.org](https://www.zowe.org/download.html). @@ -232,27 +232,3 @@ For a complete list of enhancements and bug fixes, see the following changelogs: - [IBM Db2 Databse Plug-in Zowe CLI](https://github.com/zowe/zowe-cli-db2-plugin/blob/master/CHANGELOG.md) - [IBM z/OS FTP Plug-in Zowe CLI](https://github.com/zowe/zowe-cli-ftp-plugin/blob/master/CHANGELOG.md) - [IBM MQ Plug-in Zowe CLI](https://github.com/zowe/zowe-cli-mq-plugin/blob/master/CHANGELOG.md) - - - -## Conformance and release compatibility - -### Backward compatibility - -Zowe V2 conformant extensions/plug-ins are not guaranteed to be compatible with Zowe V3 and therefore may not be operable. In general, plug-ins/extensions which leverage V3 APIs that have known breaking changes are at high risk of incompatibility and unpredictable results. - -**Recommendation:** All V2 extenders test with Zowe V3, identify any issues, and disclose results to consumers to clearly indicate backward compatibility status in the extension documentation. If unable to test, clearly document as such. - -### Forward compatibility - -Zowe V3 conformant (planning to earn conformance) extensions/plug-ins are not guaranteed to be compatible with Zowe V2 LTS. In general, plug-ins/extensions with no known dependency on any newly introduced Zowe V2 functions are at minimum risk. - -**Recommendation:** All V3 extenders test with Zowe V2 LTS, identify any issues, and disclose results to consumers to clearly indicate forward compatibility status in the extension documentation. If unable to test, clearly document as such. - -### Conformance compatibility - -Zowe V2 conformant extensions/plug-ins are likely to require changes to meet Zowe V3 conformance criteria. All extensions (regardless of V2 conformance status) must apply for V3 conformance and satisfy all required V3 testing criteria. You can find the V3 Conformance Criteria [here](https://github.com/openmainframeproject/foundation/files/8489757/Zowe.Conformance.Program.-.Test.Evaluation.Guide.Table.pdf). - -**Recommendation:** All extenders interested in earning V3 conformance review the V3 conformance criteria, determine if technical changes are necessary, make appropriate modifications and prepare to apply for V3 conformance. - -**Need help?** For assistance with reviewing or completing the Zowe Conformance Zowe V3 application, reach out to members of the Zowe Onboarding Squad on Slack at https://slack.openmainframeproject.org in the `#zowe-onboarding` channel. diff --git a/docs/whats-new/zowe-compatibility-statement-v3.md b/docs/whats-new/zowe-compatibility-statement-v3.md new file mode 100644 index 0000000000..50aa730b1c --- /dev/null +++ b/docs/whats-new/zowe-compatibility-statement-v3.md @@ -0,0 +1,29 @@ +# Zowe conformance and release compatibility + +## Backward compatibility + +Zowe V2 conformant extensions/plug-ins are not guaranteed to be compatible with Zowe V3 and therefore may not be operable. In general, plug-ins/extensions which leverage V3 APIs that have known breaking changes are at high risk of incompatibility and unpredictable results. + +:::tip Recommendation +All V2 extenders test with Zowe V3, identify any issues, and disclose results to consumers to clearly indicate backward compatibility status in the extension documentation. Testing limitations should be clearly documented. +::: + +## Forward compatibility + +Zowe V3 conformant (planning to earn conformance) extensions/plug-ins are not guaranteed to be compatible with Zowe V2 LTS. In general, plug-ins/extensions with no known dependency on any newly introduced Zowe V2 functions are at minimum risk. + +:::tip Recommendation +All V3 extenders test with Zowe V2 LTS, identify any issues, and disclose results to consumers to clearly indicate forward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Conformance compatibility + +Zowe V2 conformant extensions/plug-ins are likely to require changes to meet Zowe V3 conformance criteria. All extensions (regardless of V2 conformance status) must apply for V3 conformance and satisfy all required V3 testing criteria. For more information about V3 Conformance Criteria, see the [Zowe Support Provider Conformance Guide](https://github.com/openmainframeproject/foundation/releases/download/zowe_conformant_zowe_v3_20240910/Zowe.Support.Provider.-.Test.Evaluation.Guide.Table.pdf). + +:::tip Recommendation +Extenders interested in earning V3 conformance should review the V3 conformance criteria, determine if technical changes are necessary, make appropriate modifications, and then prepare to apply for V3 conformance. +::: + +## Need help? + +For assistance with reviewing or completing the Zowe Conformance Zowe V3 application, reach out to members of the Zowe Onboarding Squad on Slack at https://slack.openmainframeproject.org in the **#zowe-onboarding** channel. diff --git a/docs/whats-new/zowe-v3-office-hours.md b/docs/whats-new/zowe-v3-office-hours.md index 221719ee40..146e698bd2 100644 --- a/docs/whats-new/zowe-v3-office-hours.md +++ b/docs/whats-new/zowe-v3-office-hours.md @@ -6,7 +6,6 @@ Zowe squads go over their upcoming projects and answer your questions about Zowe Missed a session? Catch up here. Office hours are recorded and made available with videos posted to the [Open Mainframe Project](https://www.youtube.com/@OpenMainframeProject) YouTube channel. -## Consumer focused Office Hours | Date | Topic | Link to the meeting | Link to the recording | Links to the materials | | ------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |--------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| diff --git a/sidebars.js b/sidebars.js index a59ee2b523..aaad3e4a69 100644 --- a/sidebars.js +++ b/sidebars.js @@ -105,6 +105,7 @@ module.exports = { }, ], }, + "whats-new/zowe-compatibility-statement-v3", "getting-started/cli-getting-started", ], "setup": [ diff --git a/versioned_docs/version-v2.15.x/whats-new/zowe-compatibility-statement-v2.md b/versioned_docs/version-v2.15.x/whats-new/zowe-compatibility-statement-v2.md new file mode 100644 index 0000000000..ccbe400aac --- /dev/null +++ b/versioned_docs/version-v2.15.x/whats-new/zowe-compatibility-statement-v2.md @@ -0,0 +1,29 @@ +# Zowe conformance and release compatibility + +## Backward compatibility + +Zowe V1 conformant extensions/plug-ins are not guaranteed to be compatible with Zowe V2 and therefore may not be operable. In general, plug-ins/extensions which leverage V2 APIs that have known breaking changes are at high risk of incompatibility and unpredictable results. + +:::tip Recommendation +All V1 extenders test with Zowe V2, identify any issues, and disclose results to consumers to clearly indicate backward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Forward compatibility + +Zowe V2 conformant (planning to earn conformance) extensions/plug-ins are not guaranteed to be compatible with Zowe V1 LTS. In general, plug-ins/extensions with no known dependency on any newly introduced Zowe V1 functions are at minimum risk. + +:::tip Recommendation +All V2 extenders test with Zowe V1 LTS, identify any issues, and disclose results to consumers to clearly indicate forward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Conformance compatibility + +Zowe V1 conformant extensions/plug-ins are likely to require changes to meet Zowe V2 conformance criteria. All extensions (regardless of V1 conformance status) must apply for V2 conformance and satisfy all required V2 testing criteria. For more information about V3 Conformance Criteria, see the [Zowe Support Provider Conformance Guide](https://github.com/openmainframeproject/foundation/files/8489757/Zowe.Conformance.Program.-.Test.Evaluation.Guide.Table.pdf). + +:::tip Recommendation +All extenders interested in earning V2 conformance should review the V2 conformance criteria, determine if technical changes are necessary, make appropriate modifications, and then prepare to apply for V2 conformance. +::: + +## Need help? + +For assistance with reviewing or completing the Zowe Conformance Zowe V2 application, reach out to members of the Zowe Onboarding Squad on Slack at https://slack.openmainframeproject.org in the **#zowe-onboarding** channel. diff --git a/versioned_docs/version-v2.16.x/whats-new/zowe-compatibility-statement-v2.md b/versioned_docs/version-v2.16.x/whats-new/zowe-compatibility-statement-v2.md new file mode 100644 index 0000000000..ccbe400aac --- /dev/null +++ b/versioned_docs/version-v2.16.x/whats-new/zowe-compatibility-statement-v2.md @@ -0,0 +1,29 @@ +# Zowe conformance and release compatibility + +## Backward compatibility + +Zowe V1 conformant extensions/plug-ins are not guaranteed to be compatible with Zowe V2 and therefore may not be operable. In general, plug-ins/extensions which leverage V2 APIs that have known breaking changes are at high risk of incompatibility and unpredictable results. + +:::tip Recommendation +All V1 extenders test with Zowe V2, identify any issues, and disclose results to consumers to clearly indicate backward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Forward compatibility + +Zowe V2 conformant (planning to earn conformance) extensions/plug-ins are not guaranteed to be compatible with Zowe V1 LTS. In general, plug-ins/extensions with no known dependency on any newly introduced Zowe V1 functions are at minimum risk. + +:::tip Recommendation +All V2 extenders test with Zowe V1 LTS, identify any issues, and disclose results to consumers to clearly indicate forward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Conformance compatibility + +Zowe V1 conformant extensions/plug-ins are likely to require changes to meet Zowe V2 conformance criteria. All extensions (regardless of V1 conformance status) must apply for V2 conformance and satisfy all required V2 testing criteria. For more information about V3 Conformance Criteria, see the [Zowe Support Provider Conformance Guide](https://github.com/openmainframeproject/foundation/files/8489757/Zowe.Conformance.Program.-.Test.Evaluation.Guide.Table.pdf). + +:::tip Recommendation +All extenders interested in earning V2 conformance should review the V2 conformance criteria, determine if technical changes are necessary, make appropriate modifications, and then prepare to apply for V2 conformance. +::: + +## Need help? + +For assistance with reviewing or completing the Zowe Conformance Zowe V2 application, reach out to members of the Zowe Onboarding Squad on Slack at https://slack.openmainframeproject.org in the **#zowe-onboarding** channel. diff --git a/versioned_docs/version-v2.17.x/whats-new/zowe-compatibility-statement-v2.md b/versioned_docs/version-v2.17.x/whats-new/zowe-compatibility-statement-v2.md new file mode 100644 index 0000000000..ccbe400aac --- /dev/null +++ b/versioned_docs/version-v2.17.x/whats-new/zowe-compatibility-statement-v2.md @@ -0,0 +1,29 @@ +# Zowe conformance and release compatibility + +## Backward compatibility + +Zowe V1 conformant extensions/plug-ins are not guaranteed to be compatible with Zowe V2 and therefore may not be operable. In general, plug-ins/extensions which leverage V2 APIs that have known breaking changes are at high risk of incompatibility and unpredictable results. + +:::tip Recommendation +All V1 extenders test with Zowe V2, identify any issues, and disclose results to consumers to clearly indicate backward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Forward compatibility + +Zowe V2 conformant (planning to earn conformance) extensions/plug-ins are not guaranteed to be compatible with Zowe V1 LTS. In general, plug-ins/extensions with no known dependency on any newly introduced Zowe V1 functions are at minimum risk. + +:::tip Recommendation +All V2 extenders test with Zowe V1 LTS, identify any issues, and disclose results to consumers to clearly indicate forward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Conformance compatibility + +Zowe V1 conformant extensions/plug-ins are likely to require changes to meet Zowe V2 conformance criteria. All extensions (regardless of V1 conformance status) must apply for V2 conformance and satisfy all required V2 testing criteria. For more information about V3 Conformance Criteria, see the [Zowe Support Provider Conformance Guide](https://github.com/openmainframeproject/foundation/files/8489757/Zowe.Conformance.Program.-.Test.Evaluation.Guide.Table.pdf). + +:::tip Recommendation +All extenders interested in earning V2 conformance should review the V2 conformance criteria, determine if technical changes are necessary, make appropriate modifications, and then prepare to apply for V2 conformance. +::: + +## Need help? + +For assistance with reviewing or completing the Zowe Conformance Zowe V2 application, reach out to members of the Zowe Onboarding Squad on Slack at https://slack.openmainframeproject.org in the **#zowe-onboarding** channel. diff --git a/versioned_docs/version-v2.18.x/extend/extend-apiml/api-mediation-oidc-authentication.md b/versioned_docs/version-v2.18.x/extend/extend-apiml/api-mediation-oidc-authentication.md index 22e4f5ab71..bb6bd63d1b 100644 --- a/versioned_docs/version-v2.18.x/extend/extend-apiml/api-mediation-oidc-authentication.md +++ b/versioned_docs/version-v2.18.x/extend/extend-apiml/api-mediation-oidc-authentication.md @@ -242,7 +242,7 @@ Use the following curl command to make a REST request with the OIDC token to the curl --location 'https://"$HOSTNAME:$PORT"/gateway/api/v1/auth/oidc-token/validate --data '{"token": "$OIDC_TOKEN","serviceId": "$SERVICE_ID"}' ``` -An HTTP `200` code is returned if the validation passes. Failure to validate returns an HTTP `40x` error. +An HTTP `204` code is returned if the validation passes. Failure to validate returns an HTTP `40x` error. ::: :::note Azure Entra ID OIDC notes: diff --git a/versioned_docs/version-v2.18.x/user-guide/api-mediation/configuration-extender-passtickets.md b/versioned_docs/version-v2.18.x/user-guide/api-mediation/configuration-extender-passtickets.md index 1fec5ba946..20952c5e44 100644 --- a/versioned_docs/version-v2.18.x/user-guide/api-mediation/configuration-extender-passtickets.md +++ b/versioned_docs/version-v2.18.x/user-guide/api-mediation/configuration-extender-passtickets.md @@ -16,8 +16,8 @@ The API Gateway uses the PassTicket to access that API service. The API Gateway Configuring Zowe to use PassTickets involves two processes: -- Enabling the use of PassTickets in your External Security Manager (ESM) -- Configuring security to allow the Zowe API Gateway to generate PassTickets for an API service +1. Enabling the use of PassTickets in your External Security Manager (ESM) +2. Configuring security to allow the Zowe API Gateway to generate PassTickets for an API service ### Enabling the use of PassTickets in your External Security Manager (ESM) @@ -29,87 +29,94 @@ Since the Zowe 2.17 release, it is no longer necessary to disable replay protect This section applies to users who do not already have PassTickets enabled in the system, or users who need to define a PassTicket for a new APPLID. If you already have an APPLID that you intend to use to define your API service, skip to the section [Configuring security to allow the Zowe API Gateway to generate PassTickets for an API service](#configuring-security-to-allow-zowe-api-gateway-to-generate-passtickets-for-an-api-service). :::tip -To validate if a PassTicket is already defined, list the APPL and PKTDATA with a command corresponding to your ESM. Output indicates if a PassTicket is already defined. No results after issuing an ESM command indicates that a PassTicket is not defined. If a PassTicket is defined, the access of the zoweuser can be determined. +To validate if a PassTicket is already defined, list the APPL and PTKTDATA with a command corresponding to your ESM. Output indicates if a PassTicket is already defined. No results after issuing an ESM command indicates that a PassTicket is not defined. If a PassTicket is defined, the access of the ZWESVUSR can be determined. -- **Validating an existing PassTicket for ACF2** +**Validating an existing PassTicket for ACF2** -
- - Click here for command details about validating an existing PassTicket for ACF2. +
- In your ESM command line interface or other security environment, execute the following commands: +Click here for command details about validating an existing PassTicket for ACF2. +In your ESM command line interface or other security environment, execute the following commands: +1. Issue a `SHOW CLASMAP` command in TSO ACF to verify whether the APPL resource is defined in the GSO. Take note of the 3 character type code associated with APPL. If APPL does not appear in the `SHOW CLASMAP` listing, run the following commands: + ```acf2 - SET RESOURCE(SAF) - LIST LIKE(-) - - SET RESOURCE(SAF) - LIST LIKE(-) - - SET PROFILE(PTKTDATA) DIVISION(SSIGNON) - LIST LIKE(-) - - SET RESOURCE(PTK) - LIST LIKE(IRRPTAUTH-) + SET CONTROL(GSO) + INSERT CLASMAP.appl RESOURCE(APPL) RSRCTYPE(APL) + F ACF2,REFRESH(CLASMAP) + ``` + +2. Replace 'APL' with the type code listed in the `SHOW CLASMAP` output: + ```acf2 + SET RESOURCE(APL) + LIST LIKE(-) + ``` +3. Verify whether PTKTDATA is defined, by executing the following commands: + ```acf2 + SET PROFILE(PTKTDATA) DIVISION(SSIGNON) + LIST LIKE(-) + SET RESOURCE(PTK) + LIST LIKE(IRRPTAUTH-) ``` - - **`-`** - A wildcard symbol that lists all resources +- **`-`** + A wildcard symbol that lists all resources - - **`-`** - Lists everything related to specified applid in a resource (in this case, SAF), or specified in a profile (in this case, PTKTDATA) +- **`-`** + Lists everything related to specified applid in a resource (in this case, SAF), or specified in a profile (in this case, PTKTDATA) -
+
-- **Validating an existing PassTicket for Top Secret** +**Validating an existing PassTicket for Top Secret** -
+
- Click here for command details about validating an existing PassTicket for Top Secret. +Click here for command details about validating an existing PassTicket for Top Secret. - In your ESM command line interface or other security environment, execute the following commands: +In your ESM command line interface or other security environment, execute the following commands: ```tss - TSS WHOHAS APPL() - TSS WHOHAS PTKTDATA() - TSS WHOHAS PTKTDATA(IRRPTAUTH..) + TSS WHOHAS APPL() + TSS WHOHAS PTKTDATA() + TSS WHOHAS PTKTDATA(IRRPTAUTH..) ``` + If APPL and PTKTDATA are not defined yet, follow the instruction to create them as described in the [Enabling PassTickets with Top Secret](#enabling-passtickets-with-top-secret) section. - - **`.`** - A wildcard symbol that lists all resources +- **`.`** + A wildcard symbol that lists all resources - - **`IRRPTAUTH..`** - Returns everything about the specified applid for IRRPTAUTH +- **`IRRPTAUTH..`** + Returns everything about the specified applid for IRRPTAUTH -
+
-- **Validating an existing PassTicket for RACF** +**Validating an existing PassTicket for RACF** -
+
- Click here for command details about validating an existing PassTicket for RACF. +Click here for command details about validating an existing PassTicket for RACF. - In your ESM command line interface or other security environment, execute the following commands: +In your ESM command line interface or other security environment, execute the following commands: ```racf - RLIST APPL * ALL - RLIST APPL ALL - RLIST PTKTDATA SSIGNON ALL - RLIST PTKTDATA IRRPTAUTH..* ALL + RLIST APPL * ALL + RLIST APPL ALL + RLIST PTKTDATA SSIGNON ALL + RLIST PTKTDATA IRRPTAUTH..* ALL ``` - Ensure that you validate PKTDATA access for APPL. +Ensure that you validate PTKTDATA access for APPL. - - **`*`** - A wildcard symbol that resturns all resources +- **`*`** + A wildcard symbol that resturns all resources - - **`RLIST PTKTDATA SSIGNON ALL`** - Validates all applid for PTKDATA class +- **`RLIST PTKTDATA SSIGNON ALL`** + Validates all applid for PTKDATA class - - **`RLIST PTKTDATA IRRPTAUTH..* ALL`** - Validates all applid permissions for PTKDATA class +- **`RLIST PTKTDATA IRRPTAUTH..* ALL`** + Validates all applid permissions for PTKDATA class -
+
::: @@ -121,12 +128,18 @@ Follow these steps to enable PassTicket Support specific to your ESM. Click here for command details about configuring Zowe to use PassTickets using ACF2. -1. In your ESM command line interface or other security environment, define the application session key by entering the following commands, if the session key is not already defined. - +1. Issue a `SHOW CLASMAP` command in TSO ACF to to identity the 3 character type code associated with APPL. Replace 'APL' with the type code listed in the `SHOW CLASMAP` output: ```acf2 - SET PROFILE(PTKTDATA) DIV(SSIGNON) - INSERT SSKEY() - F ACF2,REBUILD(PTK),CLASS(P) + SET RESOURCE(APL) + RECKEY ADD(UID() ALLOW) + F ACF2,REBUILD(APL) + ``` +2. In your ESM command line interface or other security environment, define the application session key by entering the following commands, if the session key is not already defined. + + ```acf2 + SET PROFILE(PTKTDATA) DIV(SSIGNON) + INSERT SSKEY() + F ACF2,REBUILD(PTK),CLASS(P) ``` * **`applid`** @@ -164,7 +177,7 @@ You configured Zowe to use PassTickets for single sign on using ACF2. Click here for command details about configuring Zowe to use PassTickets using Top Secret. -Before you begin this procedure, verify that the `PTKTDATA` class and ownership for the PassTicket resource (`IRRPTAUT`) have not already been defined as described in the previous tip. +Before you begin this procedure, verify that the `PTKTDATA` class and ownership for the PassTicket resource (`IRRPTAUTH`) have not already been defined as described in the previous tip. 1. Update the resource descriptor table (RDT) to define the `PTKTDATA` class by entering the following commands: @@ -181,11 +194,13 @@ Before you begin this procedure, verify that the `PTKTDATA` class and ownership Include `RESCODE(n)` in the range of 101 to 13F to make `PTKTDATA` a prefixed resource class. ::: -2. Assign ownership for the PassTicket resource (`IRRPTAUT`). Execute the following commands: +2. Assign ownership for the PassTicket resource (`IRRPTAUTH`). Execute the following commands: ``` - TSS ADDTO(department) PTKTDATA(IRRPTAUT) + TSS ADDTO() PTKTDATA(IRRPTAUTH) ``` - +- **`department`** + Specifies the department for `PTKTDATA(IRRPTAUTH)`. The default department is `TSODEPT1`. + 3. Define PassTicket for application ID _applid_: ```tss @@ -350,16 +365,54 @@ Grant the Zowe started task user ID permission to generate PassTickets for users ### Verifying your PassTicket Application -In your ESM command line interface or other security environment, execute the following commands: +In your ESM command line interface or other security environment, execute the commands that correspond to your ESM: -```racf - RLIST APPL ALL - RLIST PTKTDATA IRRPTAUTH..* ALL +#### Verifyinging PassTickets using ACF2 + +
+Click here for command details for ACF2. + +**ACF2:** + +Replace 'APL' with the type code listed in the `SHOW CLASMAP` output: +```acf2 +SET RESOURCE(APL) +LIST LIKE(-) +SET RESOURCE(PTK) +LIST LIKE(IRRPTAUTH-) ``` * **`applid`** Specifies the application ID used for PassTicket validation to authenticate connections to the server +
+ +#### Verifyinging PassTickets using Top Secret + +
+Click here for command details for Top Secret. + +**TSS:** +```tss +TSS WHOHAS APPL() +TSS WHOHAS PTKTDATA(IRRPTAUTH.) +``` + +
+ +#### Verifyinging PassTickets using RACF + +
+Click here for command details for RACF. + +**RACF:** +```racf + RLIST APPL ALL + RLIST PTKTDATA IRRPTAUTH..* ALL +``` + +
+ Successful execution of this validation command shows your application and the specific access of the application. **Output example:** diff --git a/versioned_docs/version-v2.18.x/user-guide/configure-zos-system.md b/versioned_docs/version-v2.18.x/user-guide/configure-zos-system.md index 420692b9e6..9709b347b7 100644 --- a/versioned_docs/version-v2.18.x/user-guide/configure-zos-system.md +++ b/versioned_docs/version-v2.18.x/user-guide/configure-zos-system.md @@ -353,31 +353,81 @@ If you have run `ZWESECUR`, you do not need to perform the steps described in th If you have not run `ZWESECUR` and are manually creating the user ID and groups in your z/OS environment, the commands are described below for reference. - To create the `ZWEADMIN` group, issue the following command: - ``` - ADDGROUP ZWEADMIN OMVS(AUTOGID) - - DATA('STARTED TASK GROUP WITH OMVS SEGEMENT') - ``` + + **RACF:** + ``` + ADDGROUP ZWEADMIN OMVS(AUTOGID) - + DATA('STARTED TASK GROUP WITH OMVS SEGEMENT') + ``` + **TSS:** + ``` + TSS CREATE() TYPE(GROUP) + + NAME('ZOWE ADMINISTRATORS') + + DEPT() + TSS ADD() GID() + ``` + **ACF2:** + ``` + SET PROFILE(GROUP) DIV(OMVS) + INSERT AUTOGID + F ACF2,REBUILD(GRP),CLASS(P) - To create the `ZWESVUSR` user ID for the main Zowe started task, issue the following command: - ``` - ADDUSER ZWESVUSR - - NOPASSWORD - - DFLTGRP(ZWEADMIN) - - OMVS(HOME(/tmp) PROGRAM(/bin/sh) AUTOUID) - - NAME('ZOWE SERVER') - - DATA('ZOWE MAIN SERVER') - ``` -- To create the `ZWESIUSR` group for the Zowe cross memory server started task, issue the following command: - ``` - ADDUSER ZWESIUSR - - NOPASSWORD - - DFLTGRP(ZWEADMIN) - - OMVS(HOME(/tmp) PROGRAM(/bin/sh) AUTOUID) - - NAME('ZOWE XMEM SERVER') - - DATA('ZOWE XMEM CROSS MEMORY SERVER') - ``` + **RACF:** + ``` + ADDUSER - + NOPASSWORD - + DFLTGRP() - + OMVS(HOME(/tmp) PROGRAM(/bin/sh) AUTOUID) - + NAME('ZOWE SERVER') - + DATA('ZOWE MAIN SERVER') + ``` + **TSS:** + ``` + TSS CREATE() TYPE(USER) PROTECTED + + NAME('ZOWE MAIN SERVER') + + DEPT() + TSS ADD() GROUP() + + DFLTGRP() + + HOME(/tmp) OMVSPGM(/bin/sh) UID() + ``` + **ACF2:** + ``` + SET LID + INSERT STC GROUP() + SET PROFILE(USER) DIV(OMVS) + INSERT AUTOUID HOME(/tmp) OMVSPGM(/bin/sh) + F ACF2,REBUILD(USR),CLASS(P),DIVISION(OMVS) + ``` +- To create the `ZWESIUSR` group for the Zowe cross memory server started task, issue the following command: + **RACF:** + ``` + ADDUSER - + NOPASSWORD - + DFLTGRP() - + OMVS(HOME(/tmp) PROGRAM(/bin/sh) AUTOUID) - + NAME('ZOWE XMEM SERVER') - + DATA('ZOWE XMEM CROSS MEMORY SERVER') + ``` + **TSS:** + ``` + TSS CREATE() TYPE(USER) PROTECTED + + NAME('ZOWE ZIS CROSS MEMORY SERVER') + + DEPT() + TSS ADD() GROUP() + + DFLTGRP() + + HOME(/tmp) OMVSPGM(/bin/sh) UID(&ZISUID.) + ``` + **ACF2:** + ``` + SET LID + INSERT STC GROUP() + SET PROFILE(USER) DIV(OMVS) + INSERT AUTOUID HOME(/tmp) OMVSPGM(/bin/sh) + F ACF2,REBUILD(USR),CLASS(P),DIVISION(OMVS) + ``` ### Configure ZWESLSTC to run Zowe high availability instances under ZWESVUSR user ID diff --git a/versioned_docs/version-v2.18.x/whats-new/zowe-compatibility-statement-v2.md b/versioned_docs/version-v2.18.x/whats-new/zowe-compatibility-statement-v2.md new file mode 100644 index 0000000000..ccbe400aac --- /dev/null +++ b/versioned_docs/version-v2.18.x/whats-new/zowe-compatibility-statement-v2.md @@ -0,0 +1,29 @@ +# Zowe conformance and release compatibility + +## Backward compatibility + +Zowe V1 conformant extensions/plug-ins are not guaranteed to be compatible with Zowe V2 and therefore may not be operable. In general, plug-ins/extensions which leverage V2 APIs that have known breaking changes are at high risk of incompatibility and unpredictable results. + +:::tip Recommendation +All V1 extenders test with Zowe V2, identify any issues, and disclose results to consumers to clearly indicate backward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Forward compatibility + +Zowe V2 conformant (planning to earn conformance) extensions/plug-ins are not guaranteed to be compatible with Zowe V1 LTS. In general, plug-ins/extensions with no known dependency on any newly introduced Zowe V1 functions are at minimum risk. + +:::tip Recommendation +All V2 extenders test with Zowe V1 LTS, identify any issues, and disclose results to consumers to clearly indicate forward compatibility status in the extension documentation. Any testing limitations should be clearly documented. +::: + +## Conformance compatibility + +Zowe V1 conformant extensions/plug-ins are likely to require changes to meet Zowe V2 conformance criteria. All extensions (regardless of V1 conformance status) must apply for V2 conformance and satisfy all required V2 testing criteria. For more information about V3 Conformance Criteria, see the [Zowe Support Provider Conformance Guide](https://github.com/openmainframeproject/foundation/files/8489757/Zowe.Conformance.Program.-.Test.Evaluation.Guide.Table.pdf). + +:::tip Recommendation +All extenders interested in earning V2 conformance should review the V2 conformance criteria, determine if technical changes are necessary, make appropriate modifications, and then prepare to apply for V2 conformance. +::: + +## Need help? + +For assistance with reviewing or completing the Zowe Conformance Zowe V2 application, reach out to members of the Zowe Onboarding Squad on Slack at https://slack.openmainframeproject.org in the **#zowe-onboarding** channel. diff --git a/versioned_sidebars/version-v2.15.x-sidebars.json b/versioned_sidebars/version-v2.15.x-sidebars.json index 6dba58eaa8..7e32875c2f 100644 --- a/versioned_sidebars/version-v2.15.x-sidebars.json +++ b/versioned_sidebars/version-v2.15.x-sidebars.json @@ -108,6 +108,7 @@ "className": "ToCitemcolor", "id": "extend/migrate-extensions" }, + "whats-new/zowe-compatibility-statement-v2", { "type": "doc", "label": "Zowe learning resources", diff --git a/versioned_sidebars/version-v2.16.x-sidebars.json b/versioned_sidebars/version-v2.16.x-sidebars.json index cdff456095..dc6ee7d552 100644 --- a/versioned_sidebars/version-v2.16.x-sidebars.json +++ b/versioned_sidebars/version-v2.16.x-sidebars.json @@ -109,6 +109,7 @@ "className": "ToCitemcolor", "id": "extend/migrate-extensions" }, + "whats-new/zowe-compatibility-statement-v2", { "type": "doc", "label": "Zowe learning resources", diff --git a/versioned_sidebars/version-v2.17.x-sidebars.json b/versioned_sidebars/version-v2.17.x-sidebars.json index 2996581ea8..9aa06a6076 100644 --- a/versioned_sidebars/version-v2.17.x-sidebars.json +++ b/versioned_sidebars/version-v2.17.x-sidebars.json @@ -112,6 +112,7 @@ "className": "ToCitemcolor", "id": "extend/migrate-extensions" }, + "whats-new/zowe-compatibility-statement-v2", { "type": "doc", "label": "Zowe learning resources", diff --git a/versioned_sidebars/version-v2.18.x-sidebars.json b/versioned_sidebars/version-v2.18.x-sidebars.json index 268a0626df..fef86e4c45 100644 --- a/versioned_sidebars/version-v2.18.x-sidebars.json +++ b/versioned_sidebars/version-v2.18.x-sidebars.json @@ -113,6 +113,7 @@ "className": "ToCitemcolor", "id": "extend/migrate-extensions" }, + "whats-new/zowe-compatibility-statement-v2", { "type": "doc", "label": "Zowe learning resources",