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.
---------------
When a user authenticates with Liberty the server creates an entry in an authentication cache to speed this process up the next time the user sends in a request. Like all caches, the problem becomes when to remove the entry. You don’t want to just let the cache build up forever because it could get huge. The cache entry might also become not valid over time. In this case, it might be because the user’s identity got revoked (say the person behind the identity got fired!). With a valid entry in the cache, they could, in theory, still access the server even though their userid is revoked. That’s probably bad.
The cache has some configuration that allows entries to be purged after some amount of time where the entry isn’t used. This helps remove unused entries from the cache which keeps it from growing. It will also remove a revoked id unless the user manages to get a request in regularly before the cache entry expires (every 10 minutes by default).
Still, you might want to just force the cache to be cleared out occasionally. You could restart the server. But that’s an outage. Clearing the cache will temporarily affect performance as all those actively used entries are gone and have to be recreated. But still, you might want to do it anyway.
An MBean exists to perform this function, so you could create some mechanism to drive it and clear the cache when you want. To make this easier on z/OS we wrapped the MBean in a Modify command. This way automation or maybe some process that is part of revoking a userid could drive the console command and force the cache to clear.
Pretty much completely unrelated to this (except it is a security thing and we’ve got a modify command) is keystore changes. On most platforms keystores are kept in files in the file system and Liberty can monitor for changes to those files just like it monitors configuration files. When the file changes it knows something in the keystore has changed and it can go get the new stuff.
On z/OS we tend to keep our keystore behind the SAF interface in RACF or an equivalent product (I always feel like Johnny Carson referring to “another network” when I say that…for those of you old enough to remember that). This, of course, means that Liberty can’t monitor the file because there isn’t one. I believe RACF can issue an ENF signal for this event, but not all the security products do that.
So what to do? Well, when you change a keystore, you could just recycle all the servers using it, but, again, that’s an outage. We’ve thus provided another Modify command (part of the config-file refresh set) to allow you to tell Liberty that a keystore has changed and it should go do the same thing it does when it has detected a file based keystore has changed. We’re just tapping an existing MBean to do this, of course. And you can specify the name of the keystore or leave it blank and we’ll just refresh ‘em all.