IBM Z Software
This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hello,
All The documents which you send me about how it is difficult to reach the key and How it is difficult create a data breach with this way. I understand this part , it is difficult but not impossible if the keys not keep secure enough in company. But my real concern is not a data breach, my concern is system breach. Secret key is changing monthly in Halkbank system and coding/ keeping / should not be the responsibility of CTG admins. . This keys has two part one part ( in distributed platform ) manage / coded by security team ( in my customer, Halkbank ) but second part coded by CTG admins. This is exactly security teams responsibiliry and coding and protecting secret key should be the Security teams responsiblity as a Seperation of DUTYAnd the key :
SECTION JWTTOKENPROVIDER = MYJWT
SECRETKEY=5266556A586E3272357538782F4125442A472D4B6150645367566B5970337336
ALGORITHM=HS256
USERIDCLAIM=sub
is very long ( 64 digit ) and coding the secretket should not be responsibility of CTG admins. CTG admins access this CTG ini file to change any any CTG parm also. If acedently any letter changing happen in key ( ex: while ctg admin try to to m( max ) F8 , accidently type m any part of secret key. JWT token will not work and this will be a system breach. You always try to explain me DATA breach. My concern is system breach. What I offer :
In CTG start up addition to CSCLI could you add one more line LIKE JWT CLI routed a different File which just SECURTY TEAM have a access authority. Like :
CSCLI=/u/ctg/ctgv92/ctg.ini
JWTCLI=/u/ctg/ctgv92/jwt.ini
Depends on Seperation of Duty and to protecting the system from any wrong key typing which could be the system breach , secret key should keep in a different CLI lib and member which has just security team has access and update authority .
The HMAC algorithm secret key present in the CICS TG configuration file is secret key to decrypt the JWT tokens passed as part of ECI requests. The secret key is not the actual JWT token. Its standard practice to store the secret key in the product configuration files.
The following are the example products storing HMAC algorithm secret key as part of their configuration files for IBM and non IBM products:
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_sec_config_oidc_jwt.html
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_config_oidc_rp.html
https://www.ibm.com/support/knowledgecenter/SS4SVW_3.0.0/securing/config_jwt_auth.html#task_alternative_jwk
https://docs.jboss.org/author/display/teiid812final/Data+Source+Security?_sscc=t
https://www.nginx.com/blog/authenticating-api-clients-jwt-nginx-plus/
CICS TG also supports public/private key pair in the form of an X.509 certificate for signing the JWT tokens. In this case the certificates needs to be stored in the CICS TG RACF/JKS Keyring/Keystore in gateway.