This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
To start at the beginning, follow this link to the first post.
---------------
I’m going to step aside (again) from our review of messages.log to highlight some breaking news. There’s some new function in the recently GA’d (as I’m writing this) Liberty level 25.0.0.9.
The new capability is identity propagation. Technically this isn’t a new thing or even a Liberty thing. What’s new is Liberty’s ability to exploit it. The underlying capability is part of the TCP/IP implementation on z/OS and they call it Trusted Partners. The API that allows you to access it is called Partner Info. You can go search online and find the doc about that. What it allows a server to do is ask TCP/IP for the identity of the client at the other end of the connection – IF that client is located within the same sysplex as the server.
Before I go any farther, let me just point out that there’s Liberty configuration to enable this capability and SAF permissions you have to set up to allow it to happen. The details of that are all in the Liberty z/OS documentation so I’m not going to repeat it here. As I’m writing I found the doc here (https://www.ibm.com/docs/en/was-liberty/zos?topic=ezaslz-authenticating-via-zos-identity-propagation-trusted-tcp-connection-partner-security-credentials).
Alright, so if you haven’t already gotten all excited about this capability let me try to explain why you should be all excited about it.
Suppose you have a REST API hosted in your Liberty server on z/OS and you want to call that API from a client located in the sysplex somewhere. The example that jumps out to me is using the batchManager shell command to drive the REST APIs in Liberty to submit and manage Jakarta Batch jobs, but it could be anything. You could have some system automation stuff that does…whatever..living in Liberty and you’ve got automation scripting that drives that REST interface to trigger…whatever (looking at you z/OSMF…).
Now your client is going to have to authentic itself to the server to get the server to run the code that submits the Jakarta Batch job or does..whatever. Back one Liberty maintenance level that probably meant you had a userid/password buried somewhere in the client or in the script or something. And if your security guys know you’ve done that then they are probably hunting for you (hiding under your desk will not work, don’t ask how I know).
But…Ah ha! Now you can configure Liberty to ask for PartnerInfo and set up the SAF permissions so it is allowed and you can just take that userid/password out and not specify anything. Liberty will ask TCP/IP who you are and, assuming the set up is all correct, TCP/IP will look for an ACEE anchored off the client’s TCB or ASCB (task or address space level) and tell us who you are. And that’s that. TCP/IP trusts the authorized control blocks in the client and we trust TCP/IP to carry that to us.
And this works for outbound HTTP requests from Liberty also. TCP/IP will pick up the server identity unless you’ve got application syncToOSThread enabled in which case there will be a task-level ACEE and we’ll get that identity.
So, if you…have a friend with userids and passwords buried in scripts and such (because you yourself wouldn’t do that sort of thing obviously) you should let them know there’s a way for them to stop ducking around corners to avoid the security folks…at least for this.