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.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
This time we’re going to look at how use of the Angel by the Liberty server is secured. Remember from two weeks ago that as the server starts it contacts the Angel. The Angel will load an authorized module provided by the server, and then determine what authorized services are provided in that load module and which ones the server is allowed to use.
Let’s go through the authorization checks as they happen. When the server first contacts the Angel a check is made in the SERVER class for an entity called either BBG.ANGEL or BBG.ANGEL.<angel name> if you’re using a named Angel (next week’s topic). This check is done using the server’s identity and determines if the server is even allowed to talk to this Angel.
Next, the Angel is going to try to load the APF authorized load module BBGZSAFM (the last four characters of that stand for Server Authorized Function Module). Before it does that, we make sure the server is allowed to ask the Angel to load it by checking another SERVER class entity called BBG.AUTHMOD.BBGZSAFM. If the server’s identity has access the Angel is allowed to load that load module and wire it up behind those PC routines we talked about two posts ago.
But before we allow the server to access any of those services, we have to determine which ones it can use. To do that the Angel looks into the start of the loaded module for a table containing all the functions available in the module. Each one has a name that is eight characters long and that’s the name that is used for the access check. The Angel has a look at BBG.AUTHMOD.BBGZSAFM.<service name>. For example, access to the z/OS WLM services would be a check against BBG.AUTHMOD.BBGZSAFM.ZOSWLM.
The Angel does this check for each service it finds in the load module. The server is told which services it is allowed to use and messages are issued as part of startup to let you know which ones your server is allowed to use.
By default the Angel calls the SAF API to do the check so that failures aren’t logged. It could be quite normal to not have access to the Angel at all, or to selected services that a particular server doesn’t need, so the checks aren’t logged. But some people like all failed access attempts to be logged, so you can start the Angel with the SAFLOG=Y parameter and all these will get logged. If that creates a lot of noise, hang on a couple of weeks and we’ll talk about Angel Required Services.
Note that if you’re using WOLA (a topic we won’t get to for weeks) you’ll also need the server authorized to load a separate set of client authorized services in the BBGZSCFM module (Server Client Function Module) by granting the server access to BBG.AUTHMOD.BBGZSCFM. And there’s a ‘WOLA’ function inside that module you’ll need access to.
Finally, I’ll mention that you don’t want to just grant wild-card access to everything in the BBGZSAFM module (i.e. don’t grant a server access to BBG.AUTHMOD.BBGZSAFM.*). Why? Because you’ve granted that server access to all present AND FUTURE functions that show up. Someday in the future we create some new authorized service and you’ve pre-granted your server access to it without even knowing what it is yet.