Thanks, Scott, for this once again throughout explanation.
After giving some thought since I originally posted last week, I guess that our true (and more general) requirement is to preserve our ability of deploy ISAM solutions (new junction + new required stanza entries) without impacting the availability and compatibility of any other existing ISAM solutions.
So, let's push this a bit further (in a rather extreme way): we want to be able to deploy ISAM solution at any time during the day or night: be it ISAM junctions that require per-junction webseal configuration entries (ssl, …), tfimsso:/jct entries, spnego-virtual-hosted junctions, etc. without impacting any other ISAM solutions.
So why not consider deploying every junction in their own dedicated WRP instance (I am sure some other may already do this?). Well, I always though that this would be a perfect use case for "ISAM Docker", but this is a bit more extreme in the sense that with ISAM Docker, every junction would not only get is own dedicated WRP instance, but also its own dedicated execution runtime environment (storage, code, ram, etc). But I could still apply this Application Centricity deployment type to ISAM Virtual Appliance with some precaution: set the worker-threads of each WRP to a reasonable limit (default is 300, let's consider maybe 5 and tune as required) as to preserve resources (memory) on the Virtual Appliance.
I can see some other advantages of operating single WRP instance per junction even in the ISAM Virtual Appliance: always have the most secure WRP configuration entries that the back-end application can support, instead of falling back to the lower common denominator factor of configuration entries that satisfies all junctions deployed in a consolidated WRP.
A small downside of operating ISAM VA in "single WRP per junction" mode: more configuration steps (deploy new WRP) and pre-assign dedicated http-port, https-port, ssl-listening-port on a per junction basis. But I believe that automation (Ansible and ibm-security Python project) can help alleviate most of those pain points (One playbook to rule them all, one playbook to config them, one playbook to isolate them all and in the appliance bind them (-; ).
So, in the end, this discussion is making us realize that we may not have to wait for ISAM Docker to be ready in our environment to start experiencing a more Application Centric way of managing our solution, even with the Virtual Appliance.
Now I would be curious to know from other customers experience if this model is working out nicely, and from IBMers their comments on this mode of operation.
I'm also curious about those customers deploying solutions today with ISAM Docker what are they doing: a single docker image per junction, or more consolidated approach ?
Thanks
------------------------------
Sylvain Gilbert
------------------------------
Original Message:
Sent: Mon December 09, 2019 03:56 PM
From: Scott Exton
Subject: ISAM WRP hard restart and Serviceability
Sylvain,
Unfortunately trying to automatically determine when a WebSEAL instance needs to be restarted after a configuration change is not an exact science. In the vast majority of instances we know that we need to restart the WebSEAL instance whenever a change is made to the configuration file. I think that you have stumbled across perhaps the only scenario which involves a change to the WebSEAL configuration file but does not require a WebSEAL restart, i.e. configuring TFIMSSO before the corresponding junction is created. So, even though the appliance says that WebSEAL needs to be restarted it doesn't actually need to be restarted - the logic which is used to determine whether the restart is required is a little bit wrong in this scenario. So, you can ignore the restart request if you like - WebSEAL will function just fine with the updated settings without the restart. You can also open a support ticket for this issue - although it will be a challenging one to solve.
Unfortunately the spnego configuration entries do require a restart of WebSEAL (this is the way that it has always been). If this is important to you raise an RFE for this one - although I don't know when/if the enhancement would be made.
Thanks,
Scott.
------------------------------
Scott Exton
IBM
Gold Coast
Original Message:
Sent: Fri December 06, 2019 11:00 AM
From: Sylvain Gilbert
Subject: ISAM WRP hard restart and Serviceability
One small thing that I tend to miss from ISAM Pre-Appliance days (did I just said that?!) is when we could add some select entries to the webseal configuration file such as the below for the required tfimsso entries required by tfimsso junctions without the need to hard restart webseal.
[tfimsso:/some-jct]
always-send-tokens = true
applies-to = https://appliesTo/saml20
issuer = amwebrte-sts-client
one-time-token = false
preserve-xml-token = false
renewal-window = 15
service-name = *
token-collection-size = 1
token-transmit-name = saml20token
token-transmit-type = header
token-type = *
tfim-cluster-name = some-tfim-cluster-name
We would also like similarly to be able to add spnego service names for spnego virtual host junctions as well without incurring a hard restart (not sure however what was the behavior is V7):
[spnego]
spnego-auth = https
spnego-krb-service-name = HTTP@someserver.iad.ca.inet
spnego-krb-service-name = HTTP@someserver-vh-1.iad.ca.inet
spnego-krb-service-name = HTTP@someserver-vh-2.iad.ca.inet
spnego-krb-service-name = HTTP@someserver-vh-3.iad.ca.inet
spnego-krb-service-name = HTTP@someserver-vh-4.iad.ca.inet
In today's world (ISAM Appliance), any configuration change seems to require a hard webseal restart: One is forced to go in the LMI's "Deploy Pending Changes" message box and select to "Deploy" pending changes, and thereafter, the notification "The following reverse proxy instances need to be restarted for updates to take effect" is displayed. Status of the change ("Changes are Active") will remain "False" until the WRP is indeed restarted. Given that fact that we receive such notification (restart required), it will undoubtedly hint to the ISAM MANAGEMENT RESTAPI stack that a WRP restart is required, and thus WebSEAL will be restarted anyway, for such configuration changes.
Why does it matter ? Our change management principals allowed us to deploy new junction solutions more freely during off business hours period because it did not incur any service disruption (no webseal restart).
With us now deploying more and more virtual host junctions with SPNEGO, and more and more tfimsso junction (SAML20/JWT), our deployment windows possibilities are shrinking and becoming very limited (once a week) thus impacting the agility that is expected from our service group. Even with a load-balancer with numerous replicated WRP instances behind it, there is always a small service disruption that end- users can experience with a webseal restart (even with failover sso configured), or a risk that something goes wrong and do not restart. So, it is not truly an option for us to deploy junction solutions even during off business hours period where a webseal restart is required.
And maybe there are other per-junction settings that we could assume valid as well in the discussion.
Questions:
- Are other customers facing similar challenges ?
- What could we consider (if required) in the Product as improvement ?
- Optional webseal settings to not force a hard restart for pre-selected stanzas?
Thanks
------------------------------
Sylvain Gilbert
------------------------------