はじめに

今回はz/OS Connect周りの話が中心です。
このシリーズでは、バックエンドのサービスを提供するコンポーネントとしてオンプレ上(メインフレーム上)のz/OS Connectを想定しています。
バックエンドのサービスにアクセスする際に"基本認証"を行わせるケースを試してみます。

"基本認証"は、ユーザーID/パスワードで認証することになりますが、そのユーザー情報をどこに保持しておくか(ユーザーレジストリーとして何を使用するか)、というのは以下のような選択肢があります。

(1) server.xml上にユーザー情報を保持する (基本ユーザーレジストリー)
(2) RACF上のユーザー情報を使用する (SAFユーザーレジストリー)
(3) LDAP上のユーザー情報を使用する (LADPユーザーレジストリー)

ここでは、まず前段として、z/OS Connectの設定方法として(1), (2)のケースを試してみます。
その後z/OS Connectで認証されたユーザーIDをCICSへ伝播させてみます。
最終的にはそれをAPI Connectからアクセスしてみます。

※Angelプロセスの構成や、APIの登録などは実施済みの想定です。ここではセキュリティの設定のみにフォーカスしています。

関連記事

全体像

ここで取り上げているのはz/OS Connectの認証、および、バックエンド(CICS)へのID伝播についての構成です。

(1)基本ユーザーレジストリーを使用した基本認証

これはserver.xml上にユーザー情報を保持しておく方法です。主に開発環境での使用が想定される機能です。
セキュリティ要件の高くないケースや手っ取り早く認証の仕組みを使いたい場合に使えます。
(基本ユーザーレジストリーを使用する場合、後述のバックエンドへのID伝播は行えません。)

基本ユーザーレジストリーの構成

参考: 基本ユーザー・レジストリーの構成方法

ユーザーID、パスワードなどの情報をserver.xml上に定義します。

server.xml

...
    <basicRegistry id="basic" realm="customRealm">
        <user name="FRED" password="{xor}GQ0aGw=="/>
        <user name="CICS004" password="{xor}HBYcDG9vaw=="/>
        <group name="DemoAdmin">
          <member name="FRED" />
          <member name="CICS004" />
        </group>
    </basicRegistry>
...

ここではFRED, CICS004という2つのユーザーを定義しています。(グループも定義していますがここでは細かなアクセス制御は触れないのであまり意味はありません。)
z/OS Connectの導入ディレクトリのwlp/binにあるsecurityUtilityというコマンドを使うとパスワードの文字列を暗号化することができます。
例えば、パスワードに"FRED"という文字列を使いたい場合には以下のように実行します。

[CICS004@EPLEX1:/V1R11/usr/lpp/IBM/zosconnect/v3r0/wlp/bin] ./securityUtility encode FRED
{xor}GQ0aGw==

これで返された結果をserver.xml上のpasswordの値として指定します。
※暗号化せずに平文でそのままパスワードをserver.xmlに指定することも可能です。

基本認証の構成

参考: 基本ユーザー・レジストリーを使用した基本認証の構成方法

適切なレベルでrequireAuthをtrueに設定します。ここではz/OS Connect全体に有効化したいので、zosconnect_zosConnectManager要素で指定しています。
また、<webAppSecurity allowFailOverToBasicAuth="true"/>を指定します。

server.xml

...
<zosconnect_zosConnectManager 
    ...
    requireAuth="true"/>
...
<webAppSecurity allowFailOverToBasicAuth="true"/>
...

アクセス許可設定

参考: 基本ユーザー・レジストリーを使用して zosConnectAccess ロールを構成する方法

ここでは認証の仕組みの構成だけしたいのですが、最低限の認可の設定(アクセス制御)は実施しないといけないようです。認証されたユーザーがz/OS Connectにアクセスできるようにするための許可設定を行います。
(詳細なアクセス制御も行えますが、ここでは触れません。)

server.xml

...
   <authorization-roles id="zos.connect.access.roles">
    <security-role name="zosConnectAccess">
        <special-subject type="ALL_AUTHENTICATED_USERS"/>
    </security-role>
   </authorization-roles>
...

簡易テスト

上の設定でz/OS Connectを再起動後、z/OS Connectで公開されているREST APIを叩いてみます。
(単純にGETできるAPIで確認)
基本認証のユーザーID/パスワード指定方法はテストの仕方によって様々なので、以下いくつかのパターンでやってみます。

Chrome

サービスのURLにアクセスするとユーザーID, パスワードが聞かれるのでserver.xmlに設定した情報を入力します。

結果が返されました。

REST APIテストツール

Chromeプラグインの、Talend API Testerを使ってリクエスト投げてみます。
REST APIとして投げる場合は、Basic認証のユーザーID,パスワードは、HTTPのヘッダー情報にAuthorizationという項目を追加して、そこにBasic User:Password という形で指定します。この時、User:Password部分はBase64 Encodeしたものを指定します。こんな感じになります=>Basic RlJFRDpGUkVE(FRED:FREDをエンコードしたもの)。
Base64 Encodeは以下のようなサイトでサクッとできます。
https://www.base64encode.org/

CURL

CURLコマンドだとこんな感じで確認できます。

user01@DESKTOP-U7UON7M:~$ curl -v -u FRED:FRED http://eplex1:30682/showroomdemo/v1/isecics/stock/CITR
*   Trying xx.xx.xx.xx...
* TCP_NODELAY set
* Connected to eplex1 (xx.xx.xx.xx) port 30682 (#0)
* Server auth using Basic with user 'FRED'
> GET /showroomdemo/v1/isecics/stock/CITR HTTP/1.1
> Host: eplex1:30682
> Authorization: Basic RlJFRDpGUkVE
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Servlet/3.1
< Content-Type: application/json; charset=UTF-8
< Content-Language: en-US
< Content-Length: 1253
< Set-Cookie: LtpaToken2=9BYRcpuOGH3GmBvfGjOHbnYcqSLZpY728c6UcWuVuOhVwtmTerEYRPSHX55ynC5e2ytSw3IkGca/R0a590bA9gFwH2VK4OIyGrLBbkz+2/D0DwU4dx7JSLW1FX4oHQiez1jzkwR9bYwokVUaIAhDZgtUa6uEaTsHoH9E2Yu1JX+yh4iLB/pr2OjKd7kbL/nUVr58YPfxeBS+FY4Ls5B+MAY5cmv8+OANymZBGoBhdIcmkmUPl+9Cf11ta3l5x8kBkWetxYEUM7/mOZl4/lXk5yvxwtGasfJf3lY4XNSJTZ3+Rd9kkOQXKMB4hDZFdZDB; Path=/; HttpOnly
< Date: Fri, 10 Jul 2020 09:36:41 GMT
< Expires: Thu, 01 Dec 1994 16:00:00 GMT
< Cache-Control: no-cache="set-cookie, set-cookie2"
<
* Connection #0 to host eplex1 left intact
{"stockCheck":{"returnCode":0,"itemList":[{"itemId":"CITR0001","shipFrom":"\u5317\u6d77\u9053\u672d\u5e4c\u90e8\u54c1\u30bb\u30f3\u30bf\u30fc","itemName":"\uff90\uff7c\uff6d\uff9b\uff9dPILOTSPORT4","stored":"Y","itemPrice":100000},{"itemId":"CITR0002","shipFrom":"\u9752\u68ee\u770c\u9752\u68ee\u30d1\u30fc\u30c4\u30bb\u30f3\u30bf\u30fc","itemName":"\uff90\uff7c\uff6d\uff9b\uff9dPRIMACY4","stored":"Y","itemPrice":80000},{"itemId":"CITR0003","shipFrom":"\u79cb\u7530\u770c\u79cb\u7530\u90e8\u54c1\u30bb\u30f3\u30bf\u30fc","itemName":"\uff90\uff7c\uff6d\uff9b\uff9dENERGY SAVER","stored":"Y","itemPrice":90000},{"itemId":"CITR0004","shipFrom":"\u5ca9\u624b\u770c\u76db\u5ca1\u90e8\u54c1\u30bb\u30f3\u30bf\u30fc","itemName":"\uff90\uff7c\uff6d\uff9b\uff9dCROSSCLIMATE SERIES","stored":"Y","itemPrice":70000},{"itemId":"CITR0005","shipFrom":"\u5c71\u5f62\u770c\u5c71\u5f62\u30d1\u30fc\u30c4\u30bb\u30f3\u30bf\u30fc","itemName":"\uff90\uff7c\uff6d\uff9b\uff9dX-ICE XI3","stored":"Y","itemPrice":60000},{"itemId":"CITR0006","shipFrom":"\u5bae\u57ce\u770c\u4ed9\u53f0\u6771\u5317\u30d1\u30fc\u30c4\u30bb\u30f3\u30bf\u30fc","itemName":"\uff8c\uff9e\uff98\uff7c\uff9e\uff72\uff7cREGNO GR-XII","stored":"Y","itemPrice":40000}],"responseMessage":"Items found."}}

(2)SAFユーザーレジストリーを使用した基本認証

RACFユーザーで認証させるための構成です。

SAFレジストリーの有効化

参考: SAF ユーザー・レジストリーをアクティブにして構成する方法

RACF操作

非認証ユーザーIDというのを作っておく必要があるらしい。認証が完了していない状態で使われるデフォルトのユーザーみたいなものでしょうか。

[CICS004@EPLEX1:/u/cics004/RACF/APIC] tsocmd "ADDUSER WSGUEST3 DFLTGRP(WSGUESTG) OWNER(SYS1) OMVS(HOME(/u/wsguest3) PROGRAM(/bin/sh)) NAME('Unauthenticated User') NOPASSWORD NOOIDCARD RESTRICTED"
ADDUSER WSGUEST3 DFLTGRP(WSGUESTG) OWNER(SYS1) OMVS(HOME(/u/wsguest3) PROGRAM(/bin/sh)) NAME('Unauthenticated User') NOPASSWORD NOOIDCARD RESTRICTED

[CICS004@EPLEX1:/u/cics004/RACF/APIC] tsocmd "PERMIT BBGZDFLT CLASS(APPL) ID(WSGUEST3) ACCESS(READ)"
PERMIT BBGZDFLT CLASS(APPL) ID(WSGUEST3) ACCESS(READ)

次に、実際に認証に使用するユーザーをつくってみます。"ZCON01"というユーザーを作ります。

[CICS004@EPLEX1:/u/cics004/RACF/APIC] tsocmd "ADDUSER ZCON01 DFLTGRP(WSGUESTG) OWNER(SYS1) OMVS(UID(0) SHARED HOME(/u/zcon01) PROGRAM(/bin/sh)) NAME('zcon user') PASSWORD(PSWD)"
ADDUSER ZCON01 DFLTGRP(WSGUESTG) OWNER(SYS1) OMVS(UID(0) SHARED HOME(/u/zcon01) PROGRAM(/bin/sh)) NAME('zcon user') PASSWORD(PSWD)
[CICS004@EPLEX1:/u/cics004/RACF/APIC] tsocmd "PERMIT BBGZDFLT CLASS(APPL) ID(ZCON01) ACCESS(READ)"
PERMIT BBGZDFLT CLASS(APPL) ID(ZCON01) ACCESS(READ)

USS上にHOMEディレクトリ(/u/zcon01)を作成して、パスワードを変更しておきます。

[CICS004@EPLEX1:/u] mkdir zcon01

[CICS004@EPLEX1:/u] tsocmd "ALTUSER ZCON01 PASSWORD(xxx) NOEXPIRED"
ALTUSER ZCON01 PASSWORD(xxx) NOEXPIRED

server.xml編集

RACFをユーザーレジストリとして使用するための宣言を行います。

<feature>zosSecurity-1.0</feature>を追加し、safCredentials要素を追加します。
SAFをレジストリとして使うために <safRegistry/>を追加します。
また、<safCredentials>を追加します。profilePrefixはデフォルトのBBGZDFLTをそのまま使います。非認証ユーザーIDは上で作成したWSGUEST3を使用するので、unauthenticatedUserにWSGUEST3を指定します。

server.xml

...
    <featureManager>
        <feature>zosconnect:zosConnect-2.0</feature>
        <feature>zosconnect:zosConnectCommands-1.0</feature>
        <feature>zosconnect:cicsService-1.0</feature>
        <feature>imsmobile:imsmobile-2.0</feature>
        <feature>jms-2.0</feature>
        <feature>mqzosconnect:zosConnectMQ-2.0</feature>
        <feature>wmqJmsClient-2.0</feature>
        <feature>zosTransaction-1.0</feature>
        <feature>zosSecurity-1.0</feature>
    </featureManager>
...
    <safRegistry/>
    <safCredentials
        profilePrefix="BBGZDFLT"
        unauthenticatedUser="WSGUEST3"/>
...

SAFレジストリーを使用した基本認証の構成

参考:SAF ユーザー・レジストリーを使用した基本認証の構成方法

server.xml編集

適切なレベルでrequireAuthをtrueに設定します。ここではz/OS Connect全体に有効化したいので、zosconnect_zosConnectManager要素で指定しています。
また、<webAppSecurity allowFailOverToBasicAuth="true"/>を指定します。

server.xml

...
<zosconnect_zosConnectManager 
    ...
    requireAuth="true"/>
...
<webAppSecurity allowFailOverToBasicAuth="true"/>
...

アクセス許可設定

参考: SAF ユーザー・レジストリーを使用して zosConnectAccess ロールを構成する方法

ここでは認証の仕組みの構成だけしたいのですが、最低限の認可の設定(アクセス制御)は実施しないといけないようです。認証されたユーザーがz/OS Connectにアクセスできるようにするための許可設定をRACFで行います。
(詳細なアクセス制御は"Authorization Interceptor"という機能を使って行えますが、ここでは触れません。)

EJBROLEクラスに"BBGZDFLT.zos.connect.access.roles.zosConnectAccess"プロファイルを作成します。
(既に作成されていたのでここでは割愛)

ZCON01ユーザーにこのプロファイルのREAD権限を付与します。

[CICS004@EPLEX1:/u/cics004/RACF/APIC] tsocmd "PERMIT BBGZDFLT.zos.connect.access.roles.zosConnectAccess CLASS(EJBROLE) ID(ZCON01) ACCESS(READ)"
PERMIT BBGZDFLT.zos.connect.access.roles.zosConnectAccess CLASS(EJBROLE) ID(ZCON01) ACCESS(READ)
ICH06011I RACLISTED PROFILES FOR EJBROLE  WILL NOT REFLECT THE UPDATE(S) UNTIL A SETROPTS REFRESH IS ISSUED

[CICS004@EPLEX1:/u/cics004/RACF/APIC] tsocmd "SETROPTS RACLIST(EJBROLE) REFRESH"
SETROPTS RACLIST(EJBROLE) REFRESH

簡易テスト

上の設定でz/OS Connectを再起動後、z/OS Connectで公開されているREST APIを叩いてみます。
(単純にGETできるAPIで確認)

確認方法は(1)の例と同じです。

Chromeからz/OS Connectが提供するサービスのURLにアクセスすると、ユーザーIDパスワードを聞かれるので、RACFで定義されたユーザーZCON01とパスワードを指定します。

(2)' SAF Basic認証 + TLSサーバー認証(HTTPS)

SAF Basic認証と、前回実施したAPI Connect - z/OS Connect間TLS接続とを組み合わせて構成してみます。
TLS(サーバー認証+クライアント認証) + Basic認証という構成がいけるかなと思いましたが、クライアントの認証をTLSフローの中でクライアント証明書で実施するのと、ユーザーID/パスワードでの認証を2つ行わせるのはどうやらNGのようでした。普通に2つの構成組み合わせればできるかと思ったのですが、エラーでうまく認証通りませんでした...。
なので、ここではTLSはサーバー認証のみとし、通信は暗号化した上でユーザーID/パスワードでの基本認証を行わせるという構成でやってみます。(Basic認証だけだとユーザーID/パスワードが平文で流れてしまいますがTLS(HTTPS)を併用することで暗号化されるのでセキュリティー・レベルが上がります。)

実際の構成は、上の(2)と前回のTLSサーバー認証のみの構成を組み合わせればよいだけです。

構成

詳細は、既出の記述をなぞっていただければよいですが、server.xmlとしてはこんな感じになります。

server.xml

...
    <featureManager>
        <feature>zosconnect:zosConnect-2.0</feature>
        <feature>zosconnect:zosConnectCommands-1.0</feature>
        <feature>zosconnect:cicsService-1.0</feature>
        <feature>imsmobile:imsmobile-2.0</feature>
        <feature>jms-2.0</feature>
        <feature>mqzosconnect:zosConnectMQ-2.0</feature>
        <feature>wmqJmsClient-2.0</feature>
        <feature>zosTransaction-1.0</feature>
        <feature>zosSecurity-1.0</feature>
    </featureManager>
...
    <zosconnect_zosConnectManager setUTF8ResponseEncoding="true" 
        requireSecure="true" 
        requireAuth="true"/>
...
    <safRegistry/>
    <safCredentials
        profilePrefix="BBGZDFLT"
        unauthenticatedUser="WSGUEST3"/>
    <safAuthorization id="saf-authorization"/>
    <webAppSecurity allowFailOverToBasicAuth="true"/>
    <ssl id="defaultSSLConfig"
        keyStoreRef="defaultKeyStore"
        clientAuthentication="false" />
    <keyStore id="defaultKeyStore"
      fileBased="false"
      location="safkeyring:///Keyring.ZOSCONN"
      password="password"
      readOnly="true"
      type="JCERACFKS" />
...

簡易テスト

サーバー証明書に署名しているCA証明書を登録済みの環境からテストすれば、あとはユーザーID/パスワードををRACF登録済みのものにすればOK

API Connectからのアクセス

このSAF Basic認証 + TLSサーバー認証(HTTPS) の構成で、API Connectから接続してみます。
API ConnectではアセンブリのInvokeの所で、Basic認証用のユーザーID/パスワードを指定できるので、そこにRACF登録のユーザー(ZCON01)を設定します。

アセンブルからテスト

今回、ユーザーIDとパスワードはAPI Connectのアセンブル上にベタで持たせている状態ですが、とりあえずこれでAPI Connect - z/OS Connect間を基本認証(+TLS)で接続することができました。

CICSへのID伝播

上の構成をさらに拡張して、z/OS Connectで認証されたユーザーをCICSまで伝播させてみます(接続プロトコルはIPICを使用)。
つまり、以下のような流れを実装してみます。
API Connectからバックエンドのサービスにアクセスする際に基本認証の仕組みでユーザーID
パスワードを指定します(HTTPヘッダー情報にユーザーID/パスワードを指定)。
このユーザーID,パスワードはz/OS上のRACFで管理されている想定です。
リクエストを受け取ったz/OS Connectは送られてきたユーザーID/パスワードをRACFを使って認証します。
認証がOKだったらリクエストに応じたバックエンドのCICSのサービスを呼び出すことになりますが、この時認証したユーザーをCICSにも伝播させて、そのユーザーIDの元でCICSトランザクションを実行します。

CICS接続についてID伝播を行う場合、接続の単位で固定でユーザーIDを指定する方法(リンク・レベル・セキュリティー)と、リクエスト単位でユーザーIDを伝播させる方法(ユーザー・セキュリティ)がありますが、ここでは後者のリクエスト単位でユーザーIDを伝播させる方法について記載します。ユーザーIDをCICSに伝播させる場合、SAFレジストリー(RACF)、もしくはLDAPレジストリーを使用した認証をする必要があります。server.xml内にユーザーIDを保持する基本レジストリーはID伝播には使用できません。

参考: IPIC 接続のセキュリティーの構成

構成変更

SAF Basic認証 + TLSサーバー認証(HTTPS) の構成はされている前提で、z/OS Connectで認証されたユーザーをCICSに伝播させるために必要な追加構成について記載します。

参考: 配布 ID 伝搬の構成

CICS側

SIT

SIT

...
SEC=YES
...

SEC=YESを指定する必要があります。その他必要に応じてXTRANなどを設定してください。

TCPIPSERVICE定義

OBJECT CHARACTERISTICS                                    CICS RELEASE = 0710 
 CEDA  View TCpipservice( IPICTCP  )                                          
  TCpipservice   : IPICTCP                                                    
  GROup          : DEMOGRP2                                                   
  DEScription    :                                                            
  Urm            : DFHISAIP                                                   
  POrtnumber     : 54722              1-65535                                 
  STatus         : Open               Open | Closed                           
  PROtocol       : IPic               Http | Eci | User | IPic                
  TRansaction    : CISS                                                       
  Backlog        : 00000              0-32767                                 
  TSqprefix      :                                                            
  Host           : ANY                                                        
  (Mixed Case)   :                                                            
  Ipaddress      : ANY                                                        
  SPeciftcps     :                                                            
  SOcketclose    : No                 No | 0-240000 (HHMMSS)                  
  MAXPersist     : No                 No | 0-65535                            
  MAXDatalen     :                    3-524288                                
 SECURITY                                                                     
  SSl            : No                 Yes | No | Clientauth | Attlsaware      
  CErtificate    :                                                            
  (Mixed Case)                                                                
  PRIvacy        :                    Notsupported | Required | Supported     
  CIphers        :                                                            
  (Mixed Case)                                                                
  AUthenticate   :                    No | Basic | Certificate | AUTORegister 
                                      | AUTOMatic                             
  Realm          :                                                            
  (Mixed Case)                                                                
  ATtachsec      :                    Local | Verify                          
 DNS CONNECTION BALANCING                                                     
  DNsgroup       :                                                            
  GRPcritical    : No                 No | Yes                                
 DEFINITION SIGNATURE                                                         
  DEFinetime     : 07/13/20 17:02:55                                          
...

これは特にこれまでの定義と同様です。CICSがz/OS Connectからの接続をListenするポート番号などを指定します。

IPCONN定義

OBJECT CHARACTERISTICS                                    CICS RELEASE = 0710
 CEDA  View Ipconn( IPICTCP  )                                               
  Ipconn         : IPICTCP                                                   
  Group          : DEMOGRP2                                                  
  DEScription    :                                                           
 IPIC CONNECTION IDENTIFIERS                                                 
  APplid         : ZC30DM02                                                  
  Networkid      : TSCNET1                                                   
  HOst           :                                                           
  (Mixed Case)   :                                                           
  Port           : No                 No | 1-65535                           
  Tcpipservice   : IPICTCP                                                   
  HA             : No                 No | Yes                               
 IPIC CONNECTION PROPERTIES                                                  
  Receivecount   : 001                1-999                                  
  SENdcount      : 000                0-999                                  
  Queuelimit     : No                 No | 0-9999                            
  MAxqtime       : No                 No | 0-9999                            
 OPERATIONAL PROPERTIES                                                      
  AUtoconnect    : No                 No | Yes                                
  INservice      : Yes                Yes | No                                
 SECURITY                                                                     
  SSl            : No                 No | Yes                                
  CErtificate    :                                                (Mixed Case)
  CIphers        :                                                            
  (Mixed Case)                                                                
  Linkauth       : Secuser            Secuser | Certuser                      
  SECurityname   :                                                            
  Userauth       : Identify           Local | Identify | Verify | Defaultuser 
  IDprop         : Notallowed         Notallowed | Optional | Required        
 RECOVERY                                                                     
  Xlnaction      : Keep               Keep | Force                            
 MIRROR TASK PROPERTIES                                                       
  MIrrorlife     : Request            Request | Task | Uow                    
 DEFINITION SIGNATURE                                                         
  DEFinetime     : 07/13/20 17:47:21                                          
...

ポイント

APPLID: z/OS Connectの値と合わせる(zosConnectApplid)
NETWORKID: z/OS Connectの値と合わせる(zosConnectNetworkid)
TCPIPSERVICE: 上で定義したTCPIPSERVICE名
USERAUTH: Identifyを指定

z/OS Connect (server.xml)側

server.xml

    <zosconnect_zosConnectManager setUTF8ResponseEncoding="true" requireSecure="true" requireAuth="true"/>
...
    <safCredentials
        profilePrefix="BBGZDFLT"
        unauthenticatedUser="WSGUEST3"
        mapDistributedIdentities="true" />
...
    <zosconnect_cicsIpicConnection id="CT54DMA1" host="xx.xx.xx.xx" port="54722"
                zosConnectApplid="ZC30DM02" zosConnectNetworkid="TSCNET1"/>

safCredentialsで、mapDistributedIdentities="true"を指定します。
また、zosconnect_cicsIpicConnectionで、IPCONN定義で指定したAPPLID, NETWORKIDの値に合わせて、zosConnectApplid, zosConnectNetworkidを指定します。

以上で設定変更は終了なので、CICSリージョン、z/OS Connectをそれぞれ再起動します。

API Connectからの接続確認

API Connect側は前回と特に変更はありません。アセンブルでRACFのユーザーID(ZCON01),パスワードを指定している状態です。
ユーザーIDがCICSまで伝播しているかどうかを確認するために、CICS端末に接続してCSMIトランザクションをCEDXでデバッグするようにしておきます。
その状態で、API Connectのアセンブルからテストを実施します。
EDFでCICSトランザクションが稼働した状態でフックされますので、別のCICS端末からCEMT INQ TASKを実行してみます。

CSMIトランザクションの状況を見ると、API Connect側で指定したRACFユーザー"ZCON01"の権限で実行されていることが確認できました。
すなわち、API Connectで指定したユーザーがz/OS Connectで認証され、それがCICSまで伝播されたことが確認できました。