Hey Dale, I created a Stateful Junction by commandline on our WebSEAL instances, but the UUID on the junction for one instance is not what I set it to. What's up? -- Joe
a) Your WebSEAL has been hacked;
b) The Wopper has figured out your launch code;
c) IBM fixed the code as it was being shipped;
d) None of the above; or
e) All of the above.
As much fun as e) would be, I'm betting on c). I've seen an application make it through Dev and QA and into Pstage before someone from another project commented that the login page wasn't formatted properly. Really? Does anyone test without automation (which would not see the missing 'pretty' elements).
Late changes tend to be documented in the release notes or left out. This time it was left out.
There is an undocumented feature of TAMeb stateful junctions. If a stateful junction is amended through the Web Portal Manager (WPM), the UUID will change - without warning or an advisory notice - and no longer be synchronized with the matching junctions on other WebSEAL instances.
All junctions have a UUID (example: b06fb684-971f-11e0-a7e8-c0003c008803). Stateful junctions are created so the UUID is synchronized across the duplicate junctions on several WebSEAL instances. With stateful junctions, a user will be sent to the same backend server regardless of which WebSEAL instance the user is routed through.
A workaround is to paste the correct UUID into the ‘Stateful UUID’ field and click the ‘Apply’ button.
The ‘Stateful UUID’ field is also not documented. Its function is further blurred, as if undocumented was not enough, by making the field immediately below and a third shorter than the Server UUID field. This really looks like a rushed fix to a last minute discovery of a problem.
