Pass JWT payload (the claims) to a service provider of all sub-systems.

This requirement is addressed by z/OS Connect V3.0.69 / APAR PH53896:
https://www.ibm.com/support/pages/apar/PH53896

For further details refer to the "Sample JSONata expressions" topic
in the z/OS Connect V3.0 Documentation:
https://www.ibm.com/docs/en/zos-connect/zos-connect/3.0?topic=jsonata-sample-expressions

We also have a need to pass information from the payload of the JWT to the cobol program to trigger actions on based on contents of the payload. We have multiple buisness cases, and for the back end program to be able to see the JWT Payload contents would solve many of these.

With start of DSGVO on 25.5.2018 we have to be sure to deliver only data to the front end user, which he is allowed to see.

As we now baught zos connect, we want to build APIs in way so that this can be addressed in a good way.

Here the szenario - sample customer api (2 simple services):

We have a user with the userid 100 sitting on the front end client (javascript/angular). He is not allowed to see all of the customers / not all of the products of a customer.

Szenario 1: The guiuser 100 trys to receive customer information:

/customer/{customer} GET

customer 1 -> ok to get
customer 2 -> not allowed to get
cusotmer 3 -> not allowed to get

Szenario 2: The cusomer products api (/customer/{customerid}/products GET) would return the following result:

/customer/{customerid}/products GET

product1 -> ok to get
product2 -> ok to get
product3 -> not allowed to get

Both scenarios are the same -> or lets say all of our scenarios are the same, work the same way.

To solve this problem we have to pass the userid (100) to pl/1.

This can be done with the payload, but there are multiple reasons why we don't want this:

/customer/{customer}?userid=100 -> not good way

a) We currently have such a situation in a soap scenario and only have problems with it (try to get rid of it)
b) In our mind this is not a secure enough way to deal with the usecase - easy to hack
c) The api gets overloaded with information not directly related to it and so every developer has to take care of this.
d) Doing it in this way is causing an accepting problem of zos connect as hole product, because it seems like I have a product with zos connect which is not usable in a common way, so why should we use it ...... this is a realy emotional thing, but it is fact that we have this problem.

We would prefer taking the security information out of the JWT Token, as there already all the front end users data is in it now.

What we would like to have something like this:

1) The system programmer should be able to spezify the token fields in the server.xml (not changeable for a developer) - like the interceptors are working.
2) Zos connect should now map the fields into a read only cics container, where the developers can just make a GET Container to retrieve the information. The security information fields should be not connected to the request token container in any way.

I hope I described the scenarios well and why this is so important for us.

thanks Peter

I have the same requirement. Might I suggest to implement this by allowing to set a httpservlet attribute and the ability to map it to a cobol field like with the http header? I guess that this will be quite easy to implement, since it is basically the same as mapping a http header, only difference being that you add it in from a TAI. You can then add the specific field from the claimset you want as a httpservlet attribute.

Kind regards,
Erik Janssen.

I have the same requirement. Might I suggest to implement this by allowing to set a httpservlet attribute and the ability to map it to a cobol field like with the http header? I guess that this will be quite easy to implement, since it is basically the same as mapping a http header, only difference being that you add it in from a TAI. You can then add the specific field from the claimset you want as a httpservlet attribute.

Kind regards,
Erik Janssen.