CICS SAML support - scenario 5 - resign a modified assertion

1. Channel services sends SOAP request message to CICS with SAML token in SOAP WS-Sec header
2. SSL server authentication between channel services and CICS
3. CICS provider pipeline validates SAML token and extracts the contents of the SAML token into a set of SAML assertion containers
Note: the rest of the inbound DCR processing is documented in scenario 1 (steps 6-8)
DPL to AOR to run target business logic program. The SAML assertion is propagated from the Inbound DCR to the AOR
Note: the rest of the AOR processing is documented in scenario 1 (steps 10-11)
5. The application augments the service consumer's entitlements, to add additional context information e.g account and customer information.
Note: The augmentation of the SAML assertion means that the outbound SAML assertion needs to be re-signed with the CICS private key

Note: Another scenario is that the orignal service request is stored for processing later, and the outbound SAML assertion needs to be re-signed because it's time interval has expired.

Question: Is the re-signing done in the AOR or outbound DCR? We assume that it is done in the outbound DCR for now. <MR> agreed. We see the DCRs – both inbound and outbound – being the places where we adapt with the external servers connected to CICS. Having said that, we do need to consider UOW in this too. Albeit they are small in number, we do have examples of applications that require their DB2/VSAM updates (done in the AOR) synchronising with the outbound channel. We see this mainly in MQ based applications where we need to put the message on the Q under synpoint control to guarantee the message is secured or thrown away in line with the overall disposition of the UOW – fully commit DB2+MQ or fully rollback. With separate AORs & outbound DCRs, and because we don't use SL2, normally, the app's DB2 changes will be in one UOW in the AOR and the MQ put will be in a separate UOW in the DCR. In those cases where we must fully commit or rollback both DB2 & MQ, we employ MQ in the AOR. In really severe cases (normally payments applications) we would bind the inbound channel (MQ), application and outbound channel in the 1 CICS. We have no choice given that distributed UOWs across SL2 connected CICS regions is not acceptable to us operationally. With HTTP being connection based and a synchronous protocol, there is a significant reduction in risk that transactional integrity can be compromised in the manner we see with MQ. </MR>

6. DPL to Outbound DCR for outbound service call (INVOKE SERVICE). The SAML assertion is propagated from the AOR to the Outbound DCR
7. CICS requester pipeline is configured to pickup signed SAML token and attach as WS-Sec header to SOAP request message. In this scenario it also needs to re-sign the token.
Question: How does the application request that the token should be re-signed. This cannot be a static pipeline configuration because the need to re-sign or not is dependent on application processing. <MR> is it not the case that whenever anything happens with a SAML, CICS will know about it? The only components that might refer to, use (access) or change a SAML are either CICS itself or the app through various APIs it may use. If the app changes the contents of the SAML – subject, attributes etc… - those changes will need to be put back into the relevant container(s). By the time we get to the outbound DCR ready to send a SOAP request, because we will need the SAML adding to the SOAP header, will CICS not now know that either the SAML has not changed since arrival – in which case it goes out in the same form as it came in - or the SAML has been changed in one or more ways. At that point, CICS recognises it needs to be resigned. Or am I missing something? </MR>
SSL server authentication between CICS and channel services
8. Outbound DCR receives SOAP response message