(Wow, it's been a while since I played with (then) Tivoli Access Manager -- TAM, (now) IBM Security Access Manager -- ISAM and WebSEALs -- but I think I still remember how we did it then, and still do it now.)
In my opinion, no, there are no disadvantages for sharing a (series of) common WebSEAL server names disjoint from the individual server names. Best practice would be to set up shared names.
Let's theorize an extendable set of WebSEALs. Say you have hosting sites A, B, and C. For disaster recovery, you have physical (virtual?) servers 1 and 2 at each site, so the individual servers would be named A1, A2, B1, B2, C1, C2. Let's assume you need to set up 4 different WebSEAL clusters -- call them W, X, Y, and Z. On each of those 6 servers, you'd define 4 webseals, and the individual webseal server names would be something like W-A1, W-A2, ... X-B1, X-B2, ... Z-C1, Z-C2 (you can do the expansion). The idea was that the 6 instance of W-* would be behind a global load balancer for W, and so on for X-*, Y-*, and Z-*.
As you build each server, your object space automatically defines all 24 of those names. You could continue using them individually -- but every time you define something for W, you have to do it 6 times, and that's very hard to keep in synch manually.
What you do is manually define new object space entries for W, X, Y, and Z. (In practice, I made those names similar to the URLs those WebSEALs shared behind the global load balancers. Something like object names XSeal-company-com for url XSeal.company.com) Then you change the server names for all of the W-* servers to be the W object name, and so on for X, Y, and Z. At that point, then you're managing just 4 different object spaces. As I recall -- you still have to define junctions 6 times, once for each server for any given WebSEAL cluster -- but all of the object space mappings for junctions, the pages under them, and permissions were shared.
In concept, you can extend this as much as you need, across number of sites, numbers of servers per site, and however many WebSEAL clusters you need to define. It's somewhat easy to manage it all using the TAM/ISAM console this way, although you might want to figure out some automation that would build command scripts to help you build the various Junctions in a uniform way across each cluster, so you define it once.
Your mileage may vary, but a layout like this worked well for us -- a key point to remember is to Plan Your Naming Conventions up front -- it's all in the names you use for each thing. It's much harder to retrofit a naming structure later (as we had to do). Good luck.
------------------------------
Scott Tietjen CISSP
------------------------------
Original Message:
Sent: Tue February 25, 2020 04:13 PM
From: rajkumargodi F253
Subject: best practices with replicated webseal servers
Hi All, In order to have a unified object space management in a replicated webseal environment, I have seen people using same name for "server-name" for each webseal server. However, some still continue to use unique server-name for each webseal. Are there any disadvantages if we update the "server-name" to be same name on all webseal servers ? What is the best practice? Thank you!
------------------------------
Rajkumar
------------------------------